Идентификатор запроса генерируется на границе сети — балансировщиком нагрузки, шлюзом или первой службой — и возвращается в заголовке ответа, например, X-Request-Id. Каждая строка лога, записанная во время обработки этого запроса, содержит его, и когда запрос распространяется на другие службы, идентификатор передается вместе с ним, так что весь путь можно восстановить позже.
Клиенты должны регистрировать идентификатор каждой сообщенной ошибки и включать его в отчеты об ошибках; тогда служба поддержки сможет за считанные секунды найти точные журналы на стороне сервера. Стандарты распределенной трассировки, такие как W3C Trace Context (заголовок traceparent), формализуют ту же идею, добавляя родительские и дочерние сегменты для измерения времени.
Для обнаружения запроса в логах достаточно метки времени и конечной точки. В загруженной системе обрабатываются тысячи идентичных вызовов в секунду. Без идентификатора запрос "it failed around 10:42" — это поиск, а не сравнение.
В бэкэнде в режиме реального времени устанавливается заголовок X-Request-Id в каждом ответе, и тот же requestId включается в тела JSON-файлов — в том числе и в сообщениях об ошибках 500, где это единственная предоставляемая информация.
Все термины · Приёмы тестирования · Все 39 mock REST API
Последнее обновление