OpenTelemetry преодолел важный порог. Почти половина организаций сообщает, что использует его в продакшене, и ещё больше активно оценивают — по данным свежего ежегодного опроса CNCF. Такой уровень принятия меняет роль OpenTelemetry в экосистеме.
Это уже не просто очередная точка интеграции — он становится де-факто механизмом производства и сбора коррелированной телеметрии. А если OpenTelemetry становится этим слоем, мы вправе ожидать предсказуемого поведения на границах систем — особенно на ingress, где каждый запрос впервые попадает в кластер.
Платформенный взгляд
Цель платформенного инженера — сделать наблюдаемость self-service возможностью. Разработчикам не нужно думать о пайплайнах, форматах и корреляции — они должны получать полезные данные «из коробки». На практике же трассы начинаются с середины истории, логи не коррелируют, метрики живут в отдельной системе.
Многое начинается на уровне ingress. Контроллеры ingress и шлюзы — первый наблюдаемый узел для каждого внешнего запроса. Они терминируют TLS, применяют правила маршрутизации и политики, добавляют задержку ещё до того, как запрос дойдёт до приложения. Если не наблюдать этот слой правильно, ваши трассы буквально начинаются с середины.
Трассировка в основном стабилизировалась
Если включить трассировку на современном ingress-контроллере, она обычно работает как ожидается. Спаны экспортируются по OTLP, соблюдается W3C Trace Context: если запрос приходит с заголовком traceparent — ingress продолжает трассу, если нет — начинает новую на границе.
Эта конвергенция не случайна. Большинство ingress-контроллеров построены на Envoy, у которого нативная поддержка трассировки OpenTelemetry уже несколько лет. А трассировка первой достигла статуса stable в спецификации. Различия остаются (явные client-спаны, наборы атрибутов), но базовая возможность — ingress как полноценный участник распределённой трассы — в целом сошлась.
Метрики всё ещё в гравитации Prometheus
С метриками тоньше. Во многих реализациях они по-прежнему отдаются в формате Prometheus и собираются скрейпингом, даже когда трассы и логи идут по OTLP. Получается гибрид: трассы — push, логи — возможно push, метрики — scrape. Разницу часто закрывает OpenTelemetry Collector, собирая метрики с Prometheus-эндпойнтов. Операционно это работает прекрасно, но означает, что сигналы не всегда смоделированы по одним и тем же конвенциям.
Collector становится слоем согласования
Даже когда ingress отдаёт чистые OTLP-спаны, Collector обычно делает значительную работу: обогащает телеметрию атрибутами Kubernetes, нормализует поля, связывает метрики с идентичностью ресурса и маршрутизирует сигналы по бэкендам. На практике это конфигурация с процессорами k8sattributes, transform, batch и отдельными экспортёрами. Это работает, но именно такая конфигурация и есть интеграция, и настроить её правильно нетривиально. Чем больше согласования происходит в пайплайне, тем меньше намерения выражено в источнике.
Семантика улучшается, но неоднородна
Большая часть телеметрии ingress понятна: метод HTTP, код статуса, длительность. Но соответствие свежим семантическим конвенциям OpenTelemetry разнится. Некоторые проекты по-прежнему отдают http.method и http.status_code, вытесненные на http.request.method и http.response.status_code. Ничего не ломается, но по мере того как на консистентную телеметрию опирается всё больше инструментов (включая AI-аналитику), различия становятся заметнее.
Идентичность ресурса часто выводится
Компоненты ingress обычно отдают стабильный service.name, но детальный контекст Kubernetes (идентификаторы подов, имена нагрузок, информация о кластере) часто добавляется ниже по потоку Collector-ом. Последствия тонкие, но реальные: дашборды молча разбивают одну нагрузку на несколько записей после перепланирования пода, алерты срабатывают по несуществующим сервисам, корреляционные запросы возвращают частичный результат.
Итог
«Поддерживает OpenTelemetry» — обычно правда, но этот бинарный ярлык скрывает значимые различия в том, как именно работает интеграция: где-то OpenTelemetry — основная поверхность, где-то сосуществует с легаси; где-то семантика согласована в источнике, где-то — через нормализацию в пайплайне.
По мере того как OpenTelemetry становится фундаментальной инфраструктурой, а не опциональной инструментовкой, вопрос смещается. Уже не «поддерживает ли проект OpenTelemetry», а как он участвует в общей модели телеметрии — и где на самом деле происходит согласование.
Оригинал: dash0.com.