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 и связать его с трейсами, рассказано в следующей главе. Когда базовая трассировка заработает и команда привыкнет к новому инструменту, вы получите фундамент для быстрых петель обратной связи при отладке.