OpenTelemetry как стандарт

Проблема двух стандартов

До 2019 года в observability для облачных приложений сосуществовали два конкурирующих проекта — OpenTracing и OpenCensus. Оба пытались решить одну задачу: дать стандартный способ собирать телеметрию из приложений без привязки к конкретному вендору. OpenTracing, запущенный в 2016 году под крылом CNCF, предлагал API для распределённых трейсов и имел широкую поддержку среди вендоров мониторинга — Jaeger, Zipkin, Datadog, LightStep. OpenCensus, начатый Google в 2018 году как открытая версия их внутренней библиотеки Census, шёл дальше и давал не только API, но и готовую реализацию SDK плюс коллектор для сбора и маршрутизации телеметрии.

Положение разработчиков было неприятным: два стандарта — отсутствие стандарта. Один сервис инструментировали через OpenTracing, соседняя команда выбирала OpenCensus, и приходилось жить с двумя форматами данных, двумя библиотеками в одном приложении и двумя наборами плагинов, ни один из которых не покрывал всё нужное. Фрагментация тормозила adoption обоих проектов и создавала неопределённость — стратегическую ставку на стандарт, который может проиграть, никто делать не хотел.

Слияние и рождение OpenTelemetry

В мае 2019 года CNCF объявил о слиянии OpenTracing и OpenCensus в единый проект — OpenTelemetry. Решение приняли совместно Google, Microsoft, участники CNCF и мейнтейнеры обоих проектов. Архитектурно OpenTelemetry взял лучшее от предшественников: span API унаследовал от OpenTracing, модель SDK и архитектуру коллектора — от OpenCensus.

31 января 2024 года OpenTelemetry получил статус graduated project в CNCF — высший уровень зрелости, который до этого получали Kubernetes, Prometheus, Envoy и ещё около десятка проектов. Сигнал понятный: проект стабилен, API не будет ломаться между версиями, крупнейшие компании индустрии вкладываются в его развитие.

Что даёт OpenTelemetry

OpenTelemetry покрывает три типа телеметрии — так называемые три столпа observability:

Traces (трейсы) — распределённые трассировки, показывающие путь запроса через все сервисы системы. Пользователь нажимает кнопку, запрос проходит через API gateway, два микросервиса, очередь сообщений и базу данных — трейс показывает всю цепочку, время каждого шага и место ошибки или задержки.

Metrics (метрики) — числовые показатели, агрегированные по времени: количество запросов, латентность, использование ресурсов, размер очередей. Метрики дают общую картину состояния системы и позволяют строить алерты.

Logs (логи) — текстовые записи о событиях внутри приложения. OpenTelemetry добавляет к логированию корреляцию с трейсами. Каждая запись лога может содержать trace_id и span_id, и от конкретной ошибки в логе одним кликом открывается полный трейс запроса.

В 2025 году OpenTelemetry добавил четвёртый сигнал — Profiling, сбор данных о производительности на уровне функций и стека вызовов.

Архитектура коллектора

Центральный элемент архитектуры OpenTelemetry — коллектор (OTel Collector). Отдельный процесс, через который проходит вся телеметрия между приложением и бэкендом для анализа. Коллектор состоит из трёх слоёв:

Receivers принимают данные в разных форматах — OTLP (нативный протокол OpenTelemetry), Jaeger, Prometheus, Zipkin. Легаси-сервис, отдающий метрики в формате Prometheus, коллектор примет без модификации кода.

Processors трансформируют данные на лету: фильтрация, семплирование, добавление атрибутов, батчирование. К трейсам добавляется имя окружения (staging/production), отфильтровываются health-check запросы, засоряющие трейсы.

Exporters отправляют обработанные данные в бэкенд — Jaeger, Grafana Tempo, Datadog, New Relic, Elastic или любой другой сервис с поддержкой OTLP. Вендор-нейтральность здесь критична: код инструментируется один раз, бэкенд меняется без переписывания инструментации.

Коллектор разворачивается в двух режимах: как agent (DaemonSet в Kubernetes, по одному на ноду) или как gateway (отдельный сервис, принимающий телеметрию от нескольких агентов). Большинство команд используют комбинацию обоих — агенты собирают данные локально и отправляют в gateway для финальной обработки и маршрутизации.

Почему OTel победил

Три фактора сделали OpenTelemetry доминирующим стандартом.

Первый — поддержка вендоров. AWS, Google Cloud, Microsoft Azure, Datadog, Dynatrace, New Relic, Splunk — все крупные облачные провайдеры и вендоры мониторинга поддерживают OTLP. Когда основные игроки рынка договорились о формате данных, выбор стандарта перестал быть рискованным решением.

Второй — масштаб сообщества. OpenTelemetry — второй по активности проект в CNCF после Kubernetes: более 1100 уникальных контрибьюторов в месяц, более 150 компаний, вносящих вклад каждый месяц. Adopters вроде GitHub, Shopify и Robinhood гоняют OTel в больших Kubernetes-кластерах и спонсируют мейнтейнеров.

Третий — auto-instrumentation. Для Java, Python, .NET, Node.js и Go OpenTelemetry предоставляет агенты, инструментирующие популярные фреймворки и библиотеки без изменения кода. Java-агент добавляется к JVM при запуске — HTTP-запросы, вызовы баз данных, gRPC и messaging начинают генерировать трейсы. Порог входа минимальный: базовая observability за минуты, потом точечно добавляются кастомные спаны для бизнес-логики.

Рекомендации

При старте с нуля — OpenTelemetry SDK и коллектор, данные в OTLP. Это даёт свободу выбора бэкенда и защищает от vendor lock-in. При существующей инструментации через Prometheus или Jaeger коллектор примет эти форматы, миграция идёт постепенно, сервис за сервисом, без большого переключения.

Стартовать стоит с трейсов: они дают максимальную отдачу в микросервисных архитектурах, где главная боль — понять, что происходит с запросом, проходящим через десяток сервисов. Логи и метрики добавляются вторым шагом — про structured logging и его связку с трейсами есть отдельная глава. Когда базовая трассировка заработает и команда привыкнет к инструменту, появится фундамент для быстрых петель обратной связи при отладке.