OpenTelemetry
Тема дорожной карты · Observability
OpenTelemetry — это отраслевой стандартный фреймворк, независимый от поставщика, для инструментирования программного обеспечения с целью генерации метрик, логов и распределённых трассировок согласованным и переносимым способом. Он заменяет разрозненную экосистему проприетарных агентов и библиотек инструментирования единым набором API, SDK и соглашений, поддерживаемых организацией CNCF. Приложения, инструментированные с помощью OpenTelemetry, генерируют телеметрию в формате OTLP (OpenTelemetry Protocol), который может напрямую принять любой совместимый бэкенд: Prometheus, Grafana Tempo, Jaeger, Datadog и другие. Семантические соглашения OpenTelemetry определяют стандартные имена атрибутов для распространённых операций (например, http.method, db.system, rpc.service), обеспечивая последовательную маркировку и возможность запроса данных наблюдаемости во всей системе. Поскольку OpenTelemetry разделяет инструментирование и экспорт данных, организации могут менять бэкенды наблюдаемости без изменения кода приложений, что делает его фундаментальной инвестицией для долгосрочной стратегии наблюдаемости.
Как это работает
OpenTelemetry (OTel) — vendor-neutral стандарт инструментирования. Спеки покрывают API + SDK + протокол (OTLP — gRPC или HTTP). Auto-instrumentation библиотеки — для популярных фреймворков. OTel Collector — sidecar/daemon, принимающий OTLP + роутящий в backends (Prometheus, Loki, Tempo, Jaeger, vendor API). Один API + SDK для метрик, логов, traces. Поддерживается CNCF, принят AWS, Google, Microsoft, Datadog, Splunk, Yandex.
Когда применять
OpenTelemetry — для любого нового проекта; нет причин запираться в vendor SDK. Auto-instrumentation сначала (покрывает 80% без изменения кода). Collector — для централизации роутинга; смена backend без переинструментирования приложений. Для метрик OTel может заменить Prometheus client libs или кормить Prometheus через OTLP-receiver; оба работают.
Типичные ошибки
Ловушки OpenTelemetry: ручное инструментирование, когда сработала бы auto-instrumentation (DRY + баги); запуск Collector с дефолт-конфигом во внутренний API production (нет auth + TLS — защитите); pre-OTel и post-OTel SDK в одном проекте (путано, хрупко); не выставлены resources service.name + service.version (traces без provenance).