Программа курса

Модуль 03 / Урок 10 из 27

OTLP и экспортёры

Теория и практика

Как спаны физически покидают процесс? Ответ на 2024+ год один: OTLP — OpenTelemetry Protocol. Остальные протоколы — легаси или совместимость.

OTLP: что это

OTLP — протокол телеметрии OTel: трейсы, метрики и логи в одной модели данных. Два транспорта:

  • OTLP/gRPC (порт 4317) — эффективный, мультиплексированный; выбор по умолчанию;
  • OTLP/HTTP (порт 4318, path /v1/traces) — проще для прокси/балансировщиков, для окружений, где gRPC-трафик неудобен; есть вариант с protobuf или JSON.
# Стандартные переменные SDK:
OTEL_EXPORTER_OTLP_ENDPOINT=http://otel-collector:4317
OTEL_EXPORTER_OTLP_HEADERS=authorization=Bearer <token>   # для managed/защищённых приёмов
OTEL_EXPORTER_OTLP_PROTOCOL=grpc                          # или http/protobuf

Экспортёр в SDK

Экспортёр — компонент SDK, отправляющий готовые батчи спанов:

  • BatchSpanProcessor (дефолт) — копит спаны и шлёт батчами (размер, интервал настраиваются): важно для производительности приложения;
  • SimpleSpanProcessor — шлёт каждый спан сразу; только для отладки;
  • OTLP-экспортёр — сам сетевой клиент; при недоступности бэкенда держит очередь (bounded) и отбрасывает старое, не блокируя приложение.
💡 Правило: телеметрия никогда не должна вредить бизнес-запросам. Всё асинхронно, с лимитами очередей и таймаутами. Если видите, что «экспорт трейсов тормозит API» — это баг конфигурации.

Другие протоколы, которые встретите

ПротоколОткудаСтатус
Jaeger thrift/gRPC (14268, 14250)старые Jaeger SDKlegacy, принимать можно, писать новым — нет
Zipkin JSON (9411)Zipkin-клиенты, ecосистемы совместимостиподдерживается приёмом
OTLPвсе OTel SDK/Collectorстандарт

Кому адресуем экспорт: типовые схемы

  1. SDK → Jaeger напрямую (дев): OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4317;
  2. SDK → OTel Collector → Jaeger (прод, стандарт): endpoint — Collector;
  3. SDK → Collector → Kafka → Jaeger-ingester (прод больших масштабов, урок 3.4);
  4. SDK → managed бэкенд (Grafana Cloud и др.): endpoint + заголовки авторизации.

Практика

  1. Переключите свой стенд с grpc на http/protobuf (endpoint :4318) и убедитесь, что трейсы идут.
  2. Поднимите простой OTel Collector (образ otel/opentelemetry-collector-contrib) с pipeline traces: otlp → debug, отправьте трейсы в него и увидите спаны в его логах — это лучший способ понять OTLP.
  3. Остановите приём (docker stop jaeger) на минуту под нагрузкой и убедитесь, что приложение не блокируется, а после старта — возобновляет экспорт.
Мини-квиз

1. Зачем два транспорта OTLP? — gRPC — эффективность; HTTP — совместимость с прокси/LB и средами, где gRPC неудобен.

2. Почему SimpleSpanProcessor только для отладки? — Сетевой вызов на каждый спан: латентность и нагрузка недопустимы в проде.

3. Приложение шлёт в Zipkin-формат. Что делать? — Jaeger принимает Zipkin на 9411; в перспективе — перейти на OTel SDK.