Мониторинг сайтов · 5 мин · обновлено 2026-09-08

Как найти запрос в логах сервера по request ID

Практическая схема сквозного request ID: какие поля писать, как искать сбой и какие данные нельзя оставлять в логах.

Если в цепочке есть CDN, reverse proxy и приложение, искать один сбой только по времени и IP ненадёжно. Практичнее присвоить запросу случайный идентификатор — request ID, записать его на каждом этапе и передавать дальше в отдельном HTTP-заголовке.

Так можно восстановить маршрут запроса без email, Cookie, тела формы и других данных пользователя. Идентификатор должен быть техническим: он связывает события, но ничего не сообщает о человеке или операции.

Почему поиск только по времени не работает

Один запрос часто порождает несколько записей. Прокси фиксирует HTTP-ответ, приложение — начало обработки и ошибку, а отдельный сервис или очередь — фоновую задачу. Записи могут прийти с задержкой, а рядом проходят сотни похожих обращений.

IP-адрес не даёт надёжной связи: несколько посетителей могут выходить через один адрес, а один посетитель — менять сеть. Полный URL тоже рискован: в параметрах бывают поисковые фразы, email и токены.

Request ID не объясняет причину ошибки, но позволяет собрать события одного запроса в правильном порядке.

Какие поля нужны в каждой записи

Для первичной диагностики обычно достаточно:

времени в едином формате и с часовой зоной;
request ID;
имени сервиса и окружения;
HTTP-метода и шаблона маршрута, например POST /orders/{id};
кода ответа и длительности обработки;
стабильного кода события: upstream_timeout, db_unavailable или другого утверждённого значения.

Шаблон маршрута безопаснее полного URL: он сохраняет смысл, но не записывает значения параметров. Краткий код события удобнее меняющегося текста ошибки и упрощает поиск одинаковых сбоев.

Как провести request ID через прокси и приложение

1. Создавайте ID на доверенной границе

Входной прокси должен сгенерировать случайное значение, если доверенного идентификатора ещё нет. Не включайте в него дату, IP, email, номер заказа или ID пользователя.

Заголовок от внешнего клиента нельзя без проверки считать внутренним. Ограничьте его формат и длину либо заменяйте собственным значением на границе системы. Это защищает поиск от поддельных совпадений и управляющих символов.

В nginx доступна переменная $request_id. Упрощённый фрагмент выглядит так:

log_format request_json escape=json
  '{"time":"$time_iso8601","request_id":"$request_id",'
  '"method":"$request_method","path":"$uri",'
  '"status":$status,"duration":$request_time}';

access_log /var/log/nginx/access.log request_json;
proxy_set_header X-Request-ID $request_id;

Перед применением проверьте конфигурацию в тестовом окружении. Если перед nginx стоит CDN или балансировщик, определите одну доверенную точку, которая создаёт идентификатор, и правила его замены.

2. Добавляйте ID в контекст приложения

Приложение принимает проверенный X-Request-ID и добавляет его во все записи текущей обработки. Лучше настроить это один раз в middleware или общем обработчике, чем вручную передавать значение в каждый вызов логгера.

{
  "time": "2026-09-08T14:20:00+03:00",
  "request_id": "случайный_идентификатор",
  "service": "checkout",
  "route": "POST /orders/{id}",
  "event": "upstream_timeout",
  "status": 504
}

Значения в примере условные. В рабочем журнале формат и допустимые поля должны быть едиными для всех компонентов.

3. Передавайте контекст дальше

При HTTP-вызове следующий сервис получает тот же request ID и пишет его в свой журнал. Для очереди идентификатор можно положить в служебные metadata сообщения, не смешивая с бизнес-данными.

Если уже используется распределённая трассировка, стоит опереться на traceparent из W3C Trace Context. Простой request ID подходит для поиска одного запроса; трассировка дополнительно показывает отдельные участки выполнения. В обоих случаях идентификаторы не должны содержать персональные сведения, а границы доверия нужно определить заранее.

Как найти запрос во время инцидента

Зафиксируйте адрес страницы, код ответа, точное время и часовую зону. Для повторяющегося сбоя полезна история инцидентов.
В журнале входного прокси ограничьте поиск коротким интервалом, маршрутом и кодом ответа.
Скопируйте request ID найденной записи.
Ищите точное значение в логах приложения, следующих сервисов и очередей.
Соберите временную линию: приём запроса, вызовы зависимостей, первая ошибка, сформированный ответ.
Сравните с успешным запросом того же маршрута.

Начинайте с края системы. Если в прокси запись есть, а в приложении нет, проверяйте маршрутизацию, соединение и передачу заголовка. Если приложение начало работу, но не завершило её, переходите к зависимостям и их тайм-аутам.

Что нельзя записывать ради удобства поиска

Не включайте в обычные логи:

пароли, ключи API и токены доступа;
заголовки Authorization, Cookie и Set-Cookie;
тела форм и запросов целиком;
значения URL-параметров без строгого разрешённого списка;
email, телефоны, платёжные и другие персональные данные;
строки подключения и секреты инфраструктуры.

Маскирование не должно оправдывать сбор всего подряд. Сначала исключите ненужное поле, затем решайте, требуется ли ограниченное обезличенное значение. Расширенные дампы и stack trace, если без них нельзя, храните отдельно, с коротким сроком хранения и более узкими правами.

Все значения из запроса считайте недоверенными: ограничивайте длину, удаляйте переводы строк и экранируйте формат. Иначе злоумышленник сможет подделать строку журнала или сломать его разбор.

Если идентификатор теряется

Проверьте цепочку по порядку:

ID появляется в access log, включая ответы 4xx и 5xx;
прокси передаёт заголовок в upstream;
middleware добавляет ID и в обычные, и в аварийные записи;
следующий сервис не создаёт новый несвязанный ID;
очередь сохраняет служебный контекст;
часы серверов синхронизированы;
ротация не удаляет одну часть цепочки раньше другой.

После настройки выполните безопасный тестовый запрос и найдите одно значение во всех ожидаемых журналах. Затем убедитесь, что рядом нет Cookie, токенов, тела запроса и персональных полей.

Что делать дальше

Request ID сокращает путь от симптома до нужных записей, но не заменяет контроль доступности. План эскалации при падении сайта поможет заранее определить ответственных и порядок действий.

Web-Puls помогает зафиксировать время недоступности и внешний HTTP-результат. Если повторяющийся сбой нужно связать с логами прокси и приложения, отправьте заявку через форму поддержки: укажите публичный URL, время с часовой зоной, request ID и очищенный от секретов фрагмент журнала.