Что такое три сигнала: метрики, логи, трейсы

p99 checkout вырос с 80 мс до 1,2 с. Нужно понять что, почему и где — за 5 минут, а не за 5 часов. Три сигнала дают три разных ответа на три разных вопроса. Выбрать не тот — потратить 20 минут на бесполезные поиски.

Три сигнала и что каждый сохраняет

Три сигнала отличаются тем, что сохраняют и что выбрасывают.

Какой сигнал отвечает на какой вопрос

Метрики отвечают на вопрос «что происходит сейчас?» — Rate, Errors, Duration по route и region за 2 года. Данные возвращаются за миллисекунды: предагрегация происходит при записи, а не при чтении. Слепые ко всему, что не попало в label.

Логи отвечают на вопрос «что именно произошло?» — конкретная трассировка стека, тело ошибки, значение поля order_id. Хранят каждое поле; высокая cardinality бесплатна при записи, но стоит байт ingestion.

Трейсы отвечают на вопрос «где внутри одного запроса было потрачено время?» — дерево span’ов из 7 сервисов с длительностью каждого. Требуют сэмплирования — хранить 100% запросов при 1000 запросах/с = миллиарды span’ов в день.

Join-ключи: мост между сигналами

Три сигнала на трёх разных backend’ах бесполезны, если между ними нельзя перейти за один клик. Общие атрибуты — join-ключи — делают три разрозненных инструмента единой навигационной поверхностью.

Обязательные join-ключи:

• service.name — какой сервис эмитит данные
• trace_id — какой конкретный запрос
• http.route — шаблон маршрута (например, /orders/{id}, не /orders/42)

Когда метрики содержат service.name и http.route как label’ы, лог-строки содержат trace_id запроса, а трейсы содержат те же service.name и http.route — именно тогда работает «клик от всплеска метрики → лог-строка → трейс» за 30 секунд.