Join-ключи и exemplar''''ы: как три сигнала становятся компонуемыми

Метрика показывает скачок p99 на checkout. Открываешь поиск логов — но метрика использует route="/checkout", лог использует http_path="/checkout", а трейс использует http.route="/checkout". Три разных имени поля, три разрозненных поиска. Переход, который должен занять 10 секунд, занимает 20 минут.

Проблема join-ключей

Три сигнала на трёх разных backend’ах бесполезны, если между ними нельзя навигировать. Мост — небольшой набор общих ключей атрибутов, появляющихся идентично в метриках, логах и трейсах. Когда они расходятся — даже незначительно — каждый дашборд требует ad-hoc перевода запросов, а каждый on-call runbook хрупок.

Стандартный набор, формализованный в OpenTelemetry Semantic Conventions:

• service.name — какой сервис эмитит эти данные
• trace_id + span_id — какой запрос, какой шаг
• http.route — шаблон маршрута (например, /orders/{id}, не полный URL /orders/42)
• http.request.method, http.response.status_code
• db.system, db.operation, db.namespace
• messaging.system, messaging.destination.name

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

Exemplar’ы: мост метрика → трейс

Exemplar — это сэмплированный trace_id, прикреплённый к наблюдению bucket’а histogram. Когда http_request_duration_seconds записывает наблюдение 1,5 с в bucket выше 1 с, клиент histogram опционально прикрепляет один trace_id, создавший это наблюдение. Grafana отображает их как точки на тепловой карте histogram; клик по точке открывает соответствующий трейс.

Exemplar’ы (стандартизированы в Prometheus 2.32, начало 2022, теперь стандартны в OTel exporters) устраняют разрыв: «метрики говорят, что что-то медленно, но нет конкретного примера запроса для анализа.» Цепочка перехода:

1. Всплеск histogram метрики → клик по точке exemplar
2. Exemplar открывает трейс конкретного медленного запроса
3. Span трейса показывает db.query занял 1,3 с
4. Лог отфильтрован по trace_id=<тот же> показывает полный текст запроса

Никакой ручной корреляции по временным меткам. Никакого поиска по дашбордам. Одна цепочка кликов.

OpenTelemetry: интеграционный слой

Проект OpenTelemetry (CNCF, рождён в 2019 из слияния OpenCensus и OpenTracing) стандартизирует три вещи:

• API — поверхность, против которой пишут код инженеры: tracer.start_span(), meter.create_counter().
• SDK — per-language реализация, строящая OTLP-сообщения.
• OTLP — OpenTelemetry Protocol: binary protobuf через gRPC или HTTP, примерно на 50–70% меньше JSON через HTTP.

Суть: инструментировать один раз, маршрутизировать куда угодно. Код приложения вызывает OTel API, SDK строит OTLP-сообщения, OTel Collector пересылает их в любой backend — Honeycomb, Datadog, Jaeger, ClickHouse, Loki, Prometheus — всё, что говорит OTLP или имеет contrib exporter.