Как на практике коррелировать логи, метрики и трейсы при расследовании конкретного инцидента?

Короткий ответ

Типичный порядок: алерт/дашборд с метрикой показывает "что и когда" (например, рост error rate в 10:02), дальше по этому времени и сервису ищут логи с ошибками за тот же период, из логов достают trace_id конкретных неудачных запросов и смотрят полный трейс, чтобы увидеть, какой именно вызов внутри цепочки стал причиной.

Как это работает подробнее

для связи сигналов нужен общий ключ — чаще всего trace_id, который логируется приложением в каждой строке лога и присутствует в спанах трассировки. Grafana поддерживает это через "exemplars" (ссылки из точки на графике latency непосредственно на конкретный трейс) и через correlated data sources (клик по метрике открывает логи за тот же период и с теми же labels).

Пример кода

example.txtКопировать

1. Grafana-дашборд: error_rate{service="checkout"} вырос в 10:02–10:07
2. Loki-запрос: {service="checkout", level="error"} | json | ts > "10:02"
   -> находим 50 строк с одинаковым msg="payment gateway timeout" и разными trace_id
3. Jaeger: открываем 3 случайных trace_id из найденных логов
   -> во всех трёх видим одинаковый паттерн: span "payment-service -> gateway" занимает 4+ секунды

Что использовать на практике

• Практика. эффективный workflow — сначала сузить окно времени и набор затронутых инстансов/сервисов по графику метрики, затем в системе логов отфильтровать по service, временному диапазону и уровню error, найти представительные trace_id, и только затем открыть 2–3 конкретных трейса, а не пытаться просмотреть все логи подряд. Такой подход экономит время по сравнению с линейным чтением логов.
• Практика. Совпадение паттерна в нескольких независимых трейсах подтверждает системную причину (деградация payment gateway), а не случайность одного запроса — это и есть цель корреляции сигналов.

Подводные камни

• Частые ошибки. начинать расследование с чтения логов без ограничения по времени и сервису, что даёт слишком большой объём нерелевантных данных; не настраивать проставление trace_id в логи на уровне middleware/framework, из-за чего корреляция становится невозможной технически; смотреть только один трейс и делать вывод "вот причина", не проверив, типичен ли этот трейс для всех затронутых запросов или это единичный случай.