Как определить, где произошла ошибка в цепочке сервисов

Что проверяют

Умеете ли вы локализовать дефект в микросервисной системе, а не заводить баг на тот сервис, который первым показал ошибку. Интервьюеру важно, какими инструментами вы пользуетесь и что попадает в баг-репорт. Следом часто спрашивают, как быть, если трассировки в проекте нет.

Как отвечать

Опишите путь от симптома к источнику:

• идентификатор запроса: найдите в ответе или в DevTools на вкладке Network correlation id (X-Request-ID) или trace id из заголовка traceparent. Это ключ ко всем дальнейшим поискам;
• трассировка: по trace id в Jaeger, Grafana Tempo или Zipkin видно дерево вызовов, собранное через OpenTelemetry: какой span упал и сколько длился каждый шаг;
• логи: в Kibana или Grafana Loki фильтр по тому же id по всем сервисам. Ищите первую ошибку по времени, а не самую громкую;
• коды ответа: 502 и 504 на шлюзе обычно значат, что сервис за ним упал, вернул мусор или не ответил в срок. 500 указывает на сервис, который его вернул, но и он мог получить плохие данные от соседа;
• обход по звеньям: вызовите следующий сервис напрямую через curl или Postman в обход шлюза. Бинарный поиск по цепочке быстро сужает круг;
• асинхронная часть: проверьте очереди: сообщения в DLQ, отставание потребителей в Kafka;
• что менялось: недавние деплои, фичефлаги, различия конфигов между стендами.

Без трассировки остаются логи с временем и id сущности (номер заказа), но сопоставлять их дольше. Это повод предложить команде сквозной correlation id.

В баг-репорте: окружение, время в UTC, trace id, запрос и ответ, сервис-источник и доказательство, почему именно он.

Где спотыкаются

Заводят баг на шлюз или фронтенд, потому что ошибку показали они, хотя причина двумя звеньями дальше.

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

Не учитывают асинхронность: API вернул 202 Accepted, а обработка упала позже в потребителе очереди, и в логах шлюза всё чисто.