Короткий ответ Типичный порядок: алерт/дашборд с метрикой показывает "что и когда" (например, рост error rate в 10:02), дальше по этому времени и сервису ищут логи с ошибками за тот же период, из логов достают trace_id конкретных неудачных запросов и смотрят полный трейс, чтобы увидеть, какой именно вызов внутри цепочки стал причиной. Как это работает подробнее для связи сигналов нужен общий ключ — чаще всего trace_id, который логируется приложением в каждой строке лога и присутствует в спанах трассировки. Grafana поддерживает это через "exemplars" (ссылки из точки на графике latency непосредственно на конкретный трейс) и через correlated data sources (клик по метрике открывает логи за тот же период и с теми же labels). Пример кода Что использовать на практике Практика. эффективный workflow — сначала сузить окно времени и набор затронутых инстансов/сервисов по графику метрики, затем в системе логов отфильтровать по service, временному диапазону и уровню error, найти представительные trace_id, и только затем о