В цепочке из пяти сервисов у пользователей выросло время ответа. Как вы будете искать причину и что для этого должно быть построено заранее?

1. Локализовать по метрикам. Смотрим p95/p99 по каждому сервису и эндпоинту: где выросло и с какого времени. Сопоставляем с событиями — выкатка, всплеск трафика, изменение конфигурации. Смотрим насыщение: длину очередей, занятость пулов соединений и потоков, паузы GC — они выдают причину раньше утилизации CPU.

2. Найти шаг по трейсам. Берём трейсы медленных запросов: видно, какой спан занял время — запрос в базу, внешний вызов, ожидание соединения из пула, повторы. Важно сравнить с трейсами нормальных запросов.

3. Объяснить по логам. По trace_id находим структурированные логи всех сервисов этого запроса: ошибки, таймауты, план медленного запроса.

Что должно быть построено заранее:

• сквозной идентификатор трассы через все сервисы и брокеры — заголовок traceparent (W3C Trace Context), автоматическая инструментация OpenTelemetry;
• структурированные логи (JSON) с trace_id и span_id;
• метрики в виде гистограмм с разрезом по версии и экземпляру;
• tail-based семплирование — решение о сохранении трейса после его завершения: медленные и ошибочные сохраняются всегда. При head-based (решение в начале, например 1%) редкие медленные запросы до вас не доедут;
• связь метрик с трейсами (exemplars).