Как спаны физически покидают процесс? Ответ на 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 SDK | legacy, принимать можно, писать новым — нет |
| Zipkin JSON (9411) | Zipkin-клиенты, ecосистемы совместимости | поддерживается приёмом |
| OTLP | все OTel SDK/Collector | стандарт |
Кому адресуем экспорт: типовые схемы
- SDK → Jaeger напрямую (дев):
OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4317; - SDK → OTel Collector → Jaeger (прод, стандарт): endpoint — Collector;
- SDK → Collector → Kafka → Jaeger-ingester (прод больших масштабов, урок 3.4);
- SDK → managed бэкенд (Grafana Cloud и др.): endpoint + заголовки авторизации.
Практика
- Переключите свой стенд с grpc на
http/protobuf(endpoint :4318) и убедитесь, что трейсы идут. - Поднимите простой OTel Collector (образ
otel/opentelemetry-collector-contrib) с pipeline traces: otlp → debug, отправьте трейсы в него и увидите спаны в его логах — это лучший способ понять OTLP. - Остановите приём (docker stop jaeger) на минуту под нагрузкой и убедитесь, что приложение не блокируется, а после старта — возобновляет экспорт.
Мини-квиз
1. Зачем два транспорта OTLP? — gRPC — эффективность; HTTP — совместимость с прокси/LB и средами, где gRPC неудобен.
2. Почему SimpleSpanProcessor только для отладки? — Сетевой вызов на каждый спан: латентность и нагрузка недопустимы в проде.
3. Приложение шлёт в Zipkin-формат. Что делать? — Jaeger принимает Zipkin на 9411; в перспективе — перейти на OTel SDK.