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.