OpenTelemetry — это открытый набор стандартов, API, SDK и инструментов для создания, сбора и передачи телеметрических данных из приложений и инфраструктуры. К таким данным относятся метрики, логи и распределенные трассировки.
Главная задача OpenTelemetry — унифицировать Observability. Вместо того чтобы разработчики внедряли отдельный способ сбора данных для каждой системы мониторинга, приложение может формировать телеметрию в стандартном виде, а затем передавать ее в выбранную платформу хранения и анализа.
OpenTelemetry не является системой мониторинга или готовым хранилищем данных. Он не заменяет Prometheus, Grafana или системы распределенной трассировки. Его роль находится ближе к приложению: OpenTelemetry помогает получить телеметрию, обработать ее и передать дальше.
Что такое OpenTelemetry простыми словами
Представим интернет-магазин, состоящий из двадцати микросервисов. Одни написаны на Java, другие на Python, третьи на Go. Инженерам нужно собирать информацию о времени ответа, ошибках, HTTP-запросах и взаимодействии сервисов.
Без общего стандарта каждая команда может использовать собственные библиотеки и форматы. В результате телеметрия становится несовместимой, а переход на другую систему мониторинга требует изменения приложений.
OpenTelemetry предоставляет единый подход. Приложения формируют данные по общим правилам, а затем телеметрия может отправляться в различные backend-системы.
OpenTelemetry создает стандартный слой между приложением и платформами Observability, чтобы телеметрия не была жестко привязана к одному поставщику.
Для чего нужен OpenTelemetry
OpenTelemetry особенно полезен в распределенных системах, где один пользовательский запрос может проходить через множество приложений и инфраструктурных компонентов.
- сбор метрик приложений;
- создание распределенных трассировок;
- передача логов;
- единое инструментирование разных сервисов;
- корреляция телеметрических данных;
- интеграция с Observability-платформами;
- снижение зависимости от одного поставщика мониторинга;
- наблюдение за микросервисами;
- контроль облачных и контейнерных приложений;
- автоматизация сбора технических данных.
Что входит в OpenTelemetry
OpenTelemetry представляет собой экосистему из нескольких компонентов. Они позволяют создавать телеметрию внутри приложения, обрабатывать ее и передавать в системы хранения.
| Компонент | Назначение |
|---|---|
| API | Определяет интерфейсы для создания телеметрии |
| SDK | Реализует обработку и экспорт данных |
| Instrumentation | Добавляет телеметрию в приложения и библиотеки |
| Collector | Принимает, обрабатывает и передает телеметрию |
| OTLP | Протокол передачи телеметрических данных |
Какие данные собирает OpenTelemetry
OpenTelemetry используется прежде всего для трех основных типов телеметрии: traces, metrics и logs.
| Тип | Что показывает |
|---|---|
| Traces | Путь отдельного запроса через распределенную систему |
| Metrics | Числовые показатели работы системы во времени |
| Logs | События и сообщения приложений и инфраструктуры |
Большую ценность дает возможность связывать эти типы данных между собой. Например, по Trace ID инженер может найти относящиеся к конкретному запросу записи логов.
Что такое Trace
Trace — полный путь одной операции через распределенную систему.
Например, пользователь нажимает кнопку Оформить заказ. Запрос проходит через Reverse Proxy, сервис авторизации, сервис заказов, базу данных и платежный сервис.
OpenTelemetry может сформировать единую трассировку, которая покажет все эти этапы и время выполнения каждого из них.
Благодаря trace инженер видит не просто общую задержку, а конкретный участок системы, на котором возникла проблема.
Что такое Span
Span — отдельный этап внутри trace. Он описывает конкретную операцию и содержит информацию о ее начале, продолжительности и контексте.
Например, trace оформления заказа может состоять из span обработки HTTP-запроса, span обращения к базе данных и span запроса к платежному API.
| Понятие | Описание |
|---|---|
| Trace | Вся пользовательская или системная операция |
| Span | Отдельный этап внутри операции |
| Trace ID | Идентификатор полной трассировки |
| Span ID | Идентификатор отдельного этапа |
Что содержится в Span
Span может содержать название операции, время начала и завершения, статус, атрибуты и события.
Например, для HTTP-запроса можно сохранить метод, адрес сервиса, код ответа и другую техническую информацию.
Для запроса к базе данных полезно знать тип операции и имя используемой системы хранения.
Важно не помещать в телеметрию секреты, пароли и лишние персональные данные.
Что такое Context Propagation
Чтобы связать операции нескольких сервисов в один trace, идентификатор трассировки необходимо передавать между ними.
Этот механизм называется Context Propagation.
Например, сервис A получает запрос пользователя и создает trace. Когда он обращается к сервису B, вместе с запросом передается контекст трассировки. Сервис B продолжает тот же trace вместо создания полностью независимой операции.
Так строится сквозной путь запроса через всю распределенную систему.
Метрики в OpenTelemetry
Метрики представляют числовые показатели работы приложения или инфраструктуры.
Например, приложение может измерять количество запросов, продолжительность обработки операций, объем переданных данных и число ошибок.
Эти показатели затем могут отправляться в систему хранения метрик и использоваться для графиков, SLI, SLO и алертов.
OpenTelemetry позволяет унифицировать создание таких показателей в приложениях на разных языках программирования.
Логи в OpenTelemetry
Логи содержат отдельные события и сообщения приложений.
Одно из преимуществ интеграции логов с OpenTelemetry заключается в возможности добавлять к ним контекст трассировки.
Например, приложение записывает ошибку обработки платежа и одновременно добавляет Trace ID. Инженер может найти лог и сразу перейти к полной трассировке проблемного запроса.
Такой подход ускоряет диагностику распределенных приложений.
Что такое OpenTelemetry Collector
OpenTelemetry Collector — отдельный компонент, который принимает телеметрию, обрабатывает ее и отправляет в одну или несколько backend-систем.
Вместо того чтобы каждое приложение напрямую подключалось к Prometheus, системе логов и платформе трассировки, оно может отправлять данные Collector.
Collector становится промежуточным слоем Observability.
- Приложение создает телеметрию.
- Данные отправляются в Collector.
- Collector принимает их через receiver.
- Processors при необходимости изменяют или фильтруют данные.
- Exporters отправляют информацию в выбранные backend-системы.
Зачем нужен Collector
Использование Collector уменьшает количество интеграций непосредственно внутри приложений.
Если компания решит заменить систему хранения трассировок, необязательно переписывать все микросервисы. Можно изменить конфигурацию Collector.
Также Collector может выполнять batching, фильтрацию, sampling, удаление ненужных атрибутов и другие операции перед отправкой данных.
Collector помогает отделить приложения от конкретных систем хранения и обработки телеметрии.
Receivers, Processors и Exporters
| Компонент Collector | Функция |
|---|---|
| Receiver | Принимает данные |
| Processor | Обрабатывает, фильтрует или изменяет данные |
| Exporter | Отправляет данные во внешнюю систему |
Например, Collector получает traces через OTLP, удаляет ненужные атрибуты, объединяет данные в пакеты и отправляет их в систему распределенной трассировки.
Что такое OTLP
OTLP, или OpenTelemetry Protocol, — протокол передачи телеметрии между компонентами OpenTelemetry и совместимыми системами.
Он используется для передачи traces, metrics и logs.
Наличие общего протокола упрощает интеграцию приложений, Collector и backend-систем Observability.
Вместо разработки отдельного формата для каждого продукта можно использовать стандартный способ передачи данных.
Что такое Instrumentation
Instrumentation — добавление в приложение механизмов создания телеметрии.
Например, для HTTP-сервера инструментирование может автоматически измерять количество запросов и их продолжительность, а для клиента базы данных — создавать span для SQL-операций.
Часть телеметрии можно получать автоматически, а часть необходимо добавлять вручную, особенно если требуется наблюдать за бизнес-операциями.
Автоматическое инструментирование
Automatic Instrumentation позволяет получать телеметрию из некоторых популярных библиотек и фреймворков без существенных изменений прикладного кода.
Например, инструментирование может автоматически создавать spans для входящих HTTP-запросов или обращений к базе данных.
Это ускоряет внедрение Observability, особенно в большом количестве сервисов.
Однако автоматическая телеметрия обычно показывает технические операции. Для понимания бизнес-процессов часто требуется ручное инструментирование.
Ручное инструментирование
Manual Instrumentation означает, что разработчик сам добавляет создание метрик или span в важные участки программы.
Например, интернет-магазин может создавать отдельный span для операции проверки наличия товара или измерять количество успешно оформленных заказов.
Такие данные позволяют связать техническую работу приложения с реальными пользовательскими действиями.
Что такое Semantic Conventions
Semantic Conventions определяют единые правила именования и описания телеметрических данных.
Например, если разные приложения сохраняют информацию об HTTP-запросах в разных атрибутах, анализ данных усложняется.
Единые соглашения помогают разным языкам, библиотекам и сервисам создавать совместимую телеметрию.
Это особенно важно в крупных организациях с большим количеством команд разработки.
Resource в OpenTelemetry
Resource описывает источник телеметрии.
Например, к данным можно добавить имя сервиса, версию приложения, окружение или другую информацию, которая помогает понять происхождение показателя.
Если одна система получает traces от сотни микросервисов, такие атрибуты позволяют быстро фильтровать данные по конкретному приложению.
OpenTelemetry и Observability
OpenTelemetry является одним из инфраструктурных компонентов Observability.
Observability отвечает на более широкий вопрос: насколько хорошо инженеры могут понять внутреннее состояние системы по ее внешним данным.
OpenTelemetry предоставляет стандартизированный способ эти данные создать и передать.
| Понятие | Роль |
|---|---|
| Observability | Общий подход к наблюдаемости систем |
| OpenTelemetry | Стандарт формирования и передачи телеметрии |
| Backend | Хранит, анализирует и визуализирует данные |
OpenTelemetry и Prometheus
Prometheus ориентирован прежде всего на сбор и хранение метрик временных рядов. OpenTelemetry охватывает более широкий набор телеметрии и не является основным хранилищем.
Эти технологии могут использоваться совместно.
Например, приложение формирует метрики через OpenTelemetry, а инфраструктура затем передает их в систему, совместимую с Prometheus.
При этом Prometheus продолжает отвечать за хранение и запросы к метрикам, а OpenTelemetry — за их формирование и транспорт.
OpenTelemetry и Grafana
Grafana используется преимущественно для анализа и визуализации данных, а OpenTelemetry — для формирования и передачи телеметрии.
Например, приложение создает traces и metrics через OpenTelemetry, Collector передает их в соответствующие хранилища, а Grafana используется инженерами для просмотра графиков и диагностики.
Таким образом, Grafana и OpenTelemetry располагаются на разных уровнях одной Observability-архитектуры.
OpenTelemetry и Zabbix
Zabbix традиционно используется для мониторинга серверов, сетевого оборудования и инфраструктурных показателей.
OpenTelemetry больше ориентирован на стандартизированную телеметрию приложений и распределенных систем.
Эти подходы могут дополнять друг друга. Например, Zabbix контролирует физический сервер и сетевую доступность, а OpenTelemetry показывает путь запроса внутри микросервисного приложения.
OpenTelemetry и SRE
SRE-команде необходимо объективно измерять состояние сервисов и быстро диагностировать инциденты.
OpenTelemetry предоставляет данные, из которых можно получать SLI и анализировать причины нарушений SLO.
Например, метрики показывают рост доли ошибок, а traces помогают определить, какой зависимый сервис стал причиной проблемы.
Это делает OpenTelemetry важным инструментом в современных SRE-практиках.
OpenTelemetry в микросервисах
Микросервисная архитектура является одним из наиболее подходящих сценариев для OpenTelemetry.
Представим приложение из сервисов авторизации, каталога, заказов, доставки и платежей. Ошибка в одном пользовательском запросе может возникнуть на любом из этих уровней.
Благодаря Context Propagation все сервисы добавляют свои spans в общий trace.
Инженер открывает трассировку и видит, что большая часть времени ушла на вызов сервиса доставки или что платежный сервис вернул ошибку.
OpenTelemetry и Kubernetes
Kubernetes создает динамичную инфраструктуру, в которой контейнеры регулярно появляются, перезапускаются и перемещаются между узлами.
В таких условиях трудно привязывать диагностику к конкретному физическому серверу.
OpenTelemetry позволяет связывать телеметрию с именем сервиса, pod, namespace, кластером и другими атрибутами.
Collector также может развертываться внутри Kubernetes и централизованно принимать телеметрию приложений.
OpenTelemetry в облаке
В облачной среде приложения могут одновременно использовать виртуальные машины, контейнеры, управляемые базы данных и сторонние API.
OpenTelemetry помогает создать общий слой наблюдаемости над разными компонентами.
Особенно полезна распределенная трассировка, которая показывает переход запроса между внутренними и внешними сервисами.
Что такое Sampling
В высоконагруженной системе может создаваться огромное количество traces. Хранить каждый запрос подробно бывает дорого.
Sampling позволяет сохранять только часть трассировок.
Например, можно сохранять небольшую долю обычных успешных запросов, но оставлять больше данных для медленных или ошибочных операций.
Так компания снижает объем телеметрии и стоимость хранения.
Head Sampling
При Head Sampling решение о сохранении trace принимается в начале обработки запроса.
Такой подход относительно прост и позволяет заранее ограничивать поток данных.
Недостаток заключается в том, что в начале запроса еще неизвестно, завершится ли он ошибкой. Поэтому потенциально важная трассировка может не попасть в выборку.
Tail Sampling
При Tail Sampling решение принимается после получения информации о всей или значительной части трассировки.
Это позволяет применять более интеллектуальные правила: например, сохранять все запросы с ошибками или высокой задержкой.
Однако такой подход требует больше ресурсов, поскольку данные необходимо временно удерживать до принятия решения.
OpenTelemetry и производительность приложения
Сбор телеметрии создает дополнительную нагрузку. Приложение должно создавать spans, метрики и передавать данные.
При правильной конфигурации эта нагрузка обычно контролируема, но чрезмерное инструментирование может влиять на производительность.
Поэтому необходимо выбирать действительно полезные данные, использовать batching и при необходимости sampling.
Cardinality в метриках
При создании метрик важно контролировать количество уникальных комбинаций атрибутов.
Например, добавлять к метрике HTTP-запросов метод и код ответа обычно допустимо, потому что возможных значений относительно немного.
Если добавить уникальный идентификатор пользователя, количество временных рядов может резко вырасти.
Высокая cardinality увеличивает стоимость хранения и нагрузку на backend мониторинга.
Безопасность OpenTelemetry
Телеметрия может содержать техническую и чувствительную информацию, поэтому ее необходимо защищать так же внимательно, как другие внутренние данные.
Особенно опасно автоматически записывать в spans или logs содержимое HTTP-заголовков, токены авторизации, пароли и персональные данные.
Перед отправкой телеметрии можно использовать processors в Collector для удаления или преобразования нежелательных атрибутов.
Доступ к Collector и backend-системам также следует ограничивать.
Преимущества OpenTelemetry
- единый стандарт телеметрии;
- поддержка метрик, логов и трассировок;
- снижение зависимости от конкретного поставщика Observability;
- поддержка разных языков программирования;
- автоматическое инструментирование популярных технологий;
- корреляция запросов между микросервисами;
- Collector для централизованной обработки данных;
- возможность фильтровать и маршрутизировать телеметрию;
- удобная интеграция с cloud-native инфраструктурой;
- поддержка современных SRE-практик.
Ограничения OpenTelemetry
OpenTelemetry не является готовой платформой Observability. После внедрения все равно необходимо выбрать системы хранения, визуализации и алертинга.
- не хранит всю телеметрию как самостоятельный универсальный backend;
- требует инструментирования приложений;
- распределенная трассировка повышает сложность инфраструктуры;
- неправильные атрибуты могут создать высокую cardinality;
- необходимо контролировать объем данных;
- автоматическое инструментирование не всегда показывает бизнес-контекст;
- требуется настройка Collector и экспортов.
Типичные ошибки при внедрении OpenTelemetry
- Собирать максимальное количество телеметрии без понятной цели.
- Записывать пароли и токены в атрибуты.
- Использовать уникальные идентификаторы пользователей как метки метрик.
- Не передавать Trace Context между сервисами.
- Внедрять только автоматическое инструментирование и игнорировать бизнес-операции.
- Отправлять каждый сервис напрямую во множество backend-систем.
- Не использовать sampling при очень большом количестве traces.
- Не контролировать стоимость хранения данных.
- Не стандартизировать имена сервисов и окружений.
- Считать OpenTelemetry готовой системой мониторинга.
Как внедрить OpenTelemetry
Шаг 1. Определить задачи Observability
Необходимо понять, какие проблемы нужно решать: анализ задержек, контроль ошибок, диагностика микросервисов или расчет SLI.
Шаг 2. Выбрать критичные сервисы
Начинать проще с нескольких наиболее важных приложений, а не инструментировать всю инфраструктуру одновременно.
Шаг 3. Добавить базовое инструментирование
Можно начать с входящих HTTP-запросов, вызовов баз данных и внешних API.
Шаг 4. Настроить Context Propagation
Все сервисы должны корректно передавать контекст трассировки друг другу.
Шаг 5. Развернуть Collector
Collector позволяет централизовать прием, фильтрацию и экспорт телеметрии.
Шаг 6. Подключить backend-системы
Метрики можно направить в систему временных рядов, traces — в систему трассировки, а logs — в хранилище журналов.
Шаг 7. Контролировать объем данных
Следует измерять поток телеметрии, управлять sampling и сроками хранения.
Шаг 8. Добавить бизнес-контекст
После базовой технической телеметрии полезно инструментировать ключевые пользовательские операции.
Практический пример
Компания использует интернет-магазин из десяти микросервисов. Пользователи периодически жалуются, что оформление заказа занимает несколько секунд, но обычные графики CPU и памяти не показывают проблемы.
Разработчики внедряют OpenTelemetry. Входящий запрос получает Trace ID, который затем передается между сервисом заказов, каталогом, системой доставки и платежным компонентом.
После очередной жалобы инженер открывает trace медленной операции. Оказывается, почти все время запрос проводит в сервисе доставки.
Внутри него отдельный span показывает медленное обращение к внешнему API. Логи с тем же Trace ID подтверждают несколько повторных попыток соединения.
После изменения таймаутов и логики повторных запросов задержка сокращается. Дополнительно команда создает метрику времени оформления заказа и использует ее как пользовательский показатель качества.
OpenTelemetry в этом сценарии не устраняет проблему самостоятельно, но создает данные, которые позволяют быстро найти ее реальную причину.
Когда бизнесу нужен OpenTelemetry
OpenTelemetry особенно полезен в инфраструктурах, где обычного мониторинга серверов уже недостаточно.
- приложение состоит из множества микросервисов;
- используется Kubernetes;
- сервисы написаны на разных языках программирования;
- нужна распределенная трассировка;
- компания использует SRE;
- важно контролировать SLI и SLO;
- необходимо уменьшить зависимость от одного Observability-поставщика;
- требуется связывать метрики, логи и traces;
- часто возникают сложные распределенные инциденты.
Когда OpenTelemetry может быть избыточным
Для небольшого сайта на одном сервере с простым приложением полноценное внедрение OpenTelemetry может дать меньше пользы, чем обычные метрики и централизованные логи.
Если проблема легко диагностируется по состоянию одного сервера и журналу приложения, распределенная трассировка только увеличит сложность.
OpenTelemetry особенно ценен тогда, когда количество компонентов и связей между ними делает обычную диагностику слишком медленной.
OpenTelemetry и vendor lock-in
Одно из преимуществ стандартизированной телеметрии — снижение зависимости от конкретной Observability-платформы.
Если приложение использует специализированный SDK одного поставщика, переход на другую систему может потребовать изменения кода.
При использовании OpenTelemetry приложение формирует данные через более универсальный слой, а маршрутизацию можно менять в Collector.
Это не исключает зависимость полностью, поскольку разные backend-системы имеют собственные функции, но снижает связанность на уровне сбора телеметрии.
OpenTelemetry и MTTR
MTTR характеризует скорость восстановления после проблем. Значительная часть времени инцидента может уходить не на исправление, а на поиск источника сбоя.
Распределенные traces и связанные логи позволяют быстрее переходить от пользовательского симптома к конкретному сервису и операции.
Благодаря этому OpenTelemetry может помогать уменьшать время диагностики и восстановления, если телеметрия правильно спроектирована и доступна инженерам.
Связанные термины
| Термин | Связь с OpenTelemetry |
|---|---|
| Observability | Подход к наблюдаемости, для которого OpenTelemetry формирует телеметрию |
| Telemetry | Метрики, логи, traces и другие данные о работе системы |
| Trace | Полный путь операции через распределенную систему |
| Span | Отдельный этап внутри trace |
| OpenTelemetry Collector | Компонент приема, обработки и экспорта телеметрии |
| OTLP | Протокол передачи телеметрических данных |
| Prometheus | Система метрик, которая может использоваться совместно с OpenTelemetry |
| Grafana | Платформа визуализации данных Observability |
| SRE | Инженерный подход к надежности, использующий телеметрию для анализа сервисов |
| SLI | Измеряемый показатель качества, который можно рассчитывать по телеметрии |
| SLO | Целевой уровень надежности сервиса |
| Distributed Tracing | Отслеживание запроса между несколькими компонентами системы |
Краткий итог
OpenTelemetry — открытый стандарт и набор инструментов для формирования, сбора и передачи телеметрии. Он работает с метриками, логами и распределенными трассировками и особенно полезен в микросервисной, облачной и Kubernetes-инфраструктуре.
OpenTelemetry не заменяет Prometheus, Grafana или другие системы хранения и анализа. Он создает стандартизированный слой между приложением и Observability-платформами. Ключевыми элементами являются API, SDK, инструментирование, Collector и протокол OTLP.
Основная практическая ценность OpenTelemetry заключается в возможности проследить пользовательскую операцию через несколько сервисов, связать traces с логами и метриками и уменьшить зависимость приложений от конкретного поставщика мониторинга. Эффективность подхода зависит от правильного инструментирования, контроля объема телеметрии и выбора действительно полезных данных.
