Архитектура OTel: один SDK, четыре сигнала, один wire-формат

До OpenTelemetry подключение нового сервиса к observability-стеку означало четыре отдельных SDK, четыре конфига collector’а и четыре языка запросов. Смена вендора требовала повторной инструментации всего кода. OTel свернул все четыре типа сигналов в один SDK и один wire-протокол. Теперь переключение бэкенда — это изменение конфига, а не отдельный проект.

Полная стековая архитектура

OpenTelemetry-based production-стек выглядит одинаково в 2026 году вне зависимости от вендора.

Слой приложения. Каждый сервис запускает один OTel SDK (или OTel auto-instrumentation), который эмитирует четыре сигнала:

• Логи — высококардинальные записи событий с полем trace-id.
• Метрики — низкокардинальные счётчики и гистограммы; exemplar’ы гистограмм несут trace-id репрезентативного запроса.
• Трейсы — причинно-следственные графы на запрос в виде OTLP span-батчей.
• Профили — функциональные CPU- и allocation-сэмплы; каждый сэмпл несёт trace-id активного запроса.

Каждый сигнал несёт один и тот же trace-id (когда применимо), поэтому cross-signal join’ы возможны во время запроса.

Слой Collector’а. Локальный агент OTel Collector (DaemonSet на каждом узле или sidecar в каждом pod’е) принимает все четыре типа сигналов через OTLP gRPC (localhost:4317). Он батчует и отправляет в gateway-ярус. Gateway выполняет:

• Tail sampling для трейсов — буферизирует spans до закрытия трейса, затем сохраняет 100% ошибок и медленных трейсов плюс небольшой случайный baseline.
• Агрегацию метрик.
• Опциональную PII-зачистку в полях логов и фильтрацию символов профилей.
• Маршрутизацию сигналов в один или несколько бэкендов.

Слой бэкенда. Любая комбинация: Tempo (трейсы), Prometheus / Mimir (метрики), Loki (логи), Pyroscope (профили) для self-hosted Grafana-стека; или Datadog, Honeycomb, New Relic — для vendor-managed. OTLP принимается всеми крупными бэкендами начиная с 2024–2026. Переключение бэкенда — изменение конфига exporter’а; код приложения не меняется.

Конкретный конфиг OTel Collector’а

Сервис checkout (Node) отправляет все четыре сигнала через единый Collector:

# otel-collector.yaml (DaemonSet на каждом узле)
receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
processors:
  batch:
    send_batch_size: 512
    timeout: 10s
  tail_sampling:
    policies:
      - { name: errors, type: status_code, status_code: { status_codes: [ERROR] } }
      - { name: slow,   type: latency,     latency: { threshold_ms: 2000 } }
      - { name: rest,   type: probabilistic, probabilistic: { sampling_percentage: 5 } }
exporters:
  otlphttp/tempo:         { endpoint: http://tempo:4318 }
  prometheusremotewrite:  { endpoint: http://prometheus:9090/api/v1/write }
  loki:                   { endpoint: http://loki:3100/loki/api/v1/push }
  otlphttp/pyroscope:     { endpoint: http://pyroscope:4040/ingest }
service:
  pipelines:
    traces:   { receivers: [otlp], processors: [tail_sampling, batch], exporters: [otlphttp/tempo] }
    metrics:  { receivers: [otlp], processors: [batch], exporters: [prometheusremotewrite] }
    logs:     { receivers: [otlp], processors: [batch], exporters: [loki] }
    profiles: { receivers: [otlp], processors: [batch], exporters: [otlphttp/pyroscope] }

Переключение с этого self-hosted Grafana-стека на Datadog означает изменение четырёх endpoint-URL’ов exporter’ов. Код сервиса не меняется.

Почему tail sampling требует отдельного процессора

Head sampling принимает решение в начале трейса — сохранить или нет. Если он сохраняет только 5% случайно, то 95% ошибочных и медленных трейсов отбрасываются — именно тогда, когда они нужны.

Tail sampling буферизирует все spans в памяти до закрытия трейса (или до истечения decision window ~10 секунд), а затем принимает решение. Канонический production-policy:

• Сохранять 100% трейсов с любым ERROR-span’ом.
• Сохранять 100% трейсов с суммарной длительностью выше порога медленного трейса (например, 2 с).
• Сохранять случайные 5% baseline всего остального.

Это сокращает объём трейсов на 90%+ при сохранении каждого интересного трейса.

Trace-id как несущий join-ключ

Trace-id — идентификатор, который делает четырёхсигнальный стек единым инструментом, а не четырьмя разрозненными системами.

• Логи эмитируют его как структурированное поле (trace_id: "abc123").
• Метрики эмитируют его как exemplar’ы гистограмм (конкретный trace-id, прикреплённый к сэмплу бакета).
• Трейсы нативно индексируются по нему.
• Профили прикрепляют его к каждому стеку-сэмплу.

При последовательной propagation trace-id (W3C traceparent через каждый вызов сервиса) запрос «всё, что связано с этим конкретным запросом» возвращает записи логов, exemplar’ы метрик, полное дерево трейса и сэмплы профилей — все объединены одной hex-строкой. Без этого четыре сигнала — четыре изолированных хранилища, и инженер вручную коррелирует по временной метке + имени сервиса + догадкам.

Случайность 128 бит обеспечивает глобальную уникальность. Стандартизация W3C гарантирует выживание при смене вендора и языка. OTel SDK’и обрабатывают propagation автоматически через HTTP, gRPC, очереди и асинхронные вызовы.