OpenTelemetry, возможно, оправдывает свою шумиху. Проект с открытым исходным кодом для наблюдения за последние несколько лет развился и стал де-факто стандартом выбора для быстро растущего числа организаций, нуждающихся в инструментировании приложений и стандартизации телеметрических данных. Он разработан таким образом, чтобы данные могли быть поняты различными платформами наблюдения, а также системами визуализации и хранения по вашему выбору.
Участники этого ведущего проекта CNCF, лежащего в основе Kubernetes, продолжают активно работать над повышением простоты использования и реализации OpenTelemetry, а также добавлением новых функций. Однако работа над OpenTelemetry все еще находится в стадии разработки, и она еще не принята повсеместно для нужд всех организаций.
Поддержка @opentelemetry для @rustlang остается на стадии бета-тестирования для трассировок, метрик и журналов, как показал Том Донохью из @grafana на семинаре OpenTelemetry Workshop на ObservabilityCon в Лондоне на этой неделе. pic.twitter.com/etrU0BuipC
— BC Gain (@bcamerongain), 9 октября 2025 г.
Целевыми областями для улучшения по-прежнему остаются поддержка OpenTelemetry для всех языков программирования для метрик, журналов и трассировок. Согласно документации проекта OpenTelemetry, Rust остается языком, который в меньшей степени поддерживается OpenTelemetry. Трассировки, метрики и журналы для приложений Rust все еще находятся в стадии разработки. Все остальные основные языки программирования, перечисленные в документации OpenTelemetry, поддерживают как минимум метрики. Во многом это связано с несколькими факторами, в том числе с его относительно недавним масштабным внедрением по сравнению с другими широко используемыми языками, а также с тем, насколько хорошо метрики работали вместо OpenTelemetry для инструментов.
Сложность
Между тем, OpenTelemetry часто считают сложной в реализации и управлении, что представляет собой серьезное препятствие для массового внедрения. Действительно, реализация OpenTelemetry может быть сложной и сложной, например, в очень больших и масштабных мультикластерных и облачных средах. (Хотя после завершения работы по реализации OpenTelemetry как единый используемый инструмент может значительно снизить сложность.)
«OpenTelemetry сложна и сложна в установке», — сказал мне Тед Янг, директор программ разработчиков Grafana Labs, во время ObservabilityCon в Лондоне. Тем не менее, по словам Янга, основное обещание по стандартизации сигналов наблюдения — трассировок, метрик и журналов — безусловно, отвечает реальным задачам, особенно в области метрик и устаревших систем. Но хотя проект считается необходимым «для выживания в будущем», по словам Янга, несколько ключевых областей вызывают разногласия.
Что касается трассировки, обеспечение правильных семантических соглашений для меток и атрибутов создает проблемы для разработчиков при рисовании входных данных через OpenTelemetry. Крупные организации с сотнями разработчиков должны обеспечивать единообразие семантических соглашений. Такой подход к инструментарию, ориентированный на разработчиков, приводит к «самому низкому качеству данных» при отслеживании, поскольку по своей сути «сложнее сделать все правильно», — сказал Янг.
Отсутствие устоявшихся и всеобъемлющих общих конвенций усугубляет эту проблему. По словам Янга, хотя работа над стандартными протоколами, такими как маркировка HTTP, существует, многим «нестандартным протоколам» — таким как «обмен сообщениями» или более старые «вещи для удаленных вызовов процедур» — не хватает необходимых соглашений. Эти общие соглашения необходимы для того, чтобы позволить бэкэнду наблюдения «автоматически понимать то, что он видел», обеспечивая расширенные функции, такие как корреляции «графика знаний».
Прометей освобожденный
Организации, которые уже полагаются на Prometheus для своих телеметрических сигналов, часто видят необходимость добавить OpenTelemetry для своих метрик. Это часто считается риском сломать что-то, что не сломано, и потенциально усложнить среду за счет внедрения Prometheus для метрик. Проблемы совместимости между OpenTelemetry и Prometheus остаются проблемой.
Prometheus теперь хорошо интегрируется с OpenTelemetry и остается основной частью экосистемы. Это соревнование было лишь поверхностным. Тем не менее, Prometheus 2.0 создал проблемы при использовании в качестве серверной части метрик через OpenTelemetry, что усложнило внедрение на ранних этапах.
Проблемы совместимости возникли задолго до выпуска Prometheus 3.0. На самом базовом уровне существует разница в философии дизайна. Проблемы совместимости, связанные с форматами данных в Prometheus, в частности с гистограммами и протоколом пересылки данных, остаются проблемой OpenTelemetry.
С выпуском Prometheus 3.0 уже есть ряд улучшений, которые делают сбор метрик через OpenTelemetry значительно лучше и менее болезненным, чем раньше. Проблемы остаются, как описано выше, но работа продолжается, и при поддержке сообщества открытого исходного кода я могу из первых рук подтвердить, что существует большой импульс для преодоления этих проблем, которые будут решены в следующих выпусках Prometheus.
Это одна из областей, где Прометей играет роль. Текущие усилия включают активный «рефакторинг этих меток», чтобы они лучше соответствовали соглашениям, определенным Прометеем и Мимиром, для улучшения структуры и возможности сопоставления данных.
Ржавчина спит
Rust — новый язык программирования, и работать с ним сложнее, чем с такими популярными языками, как JavaScript или даже Python. Но задержка OpenTelemetry с совместимостью с Rust во многом объясняется тем, что трассировка с открытым исходным кодом Tokio уже работает хорошо.
«Хорошо, что у Rust уже есть широко распространенная система», — сказал Янг. Однако это также создает «неловкую ситуацию», когда сообщество OTel обсуждает, следует ли «просто принять трассировку Tokio в качестве официального» решения для сообщества Rust, чтобы получить широкое признание, сказал Янг. И все это несмотря на его ограничения и отсутствие инициативы со стороны первоначальных разработчиков.
Сообщество OpenTelemetry сталкивается с уникальными проблемами интеграции с экосистемой Rust, возникающими из-за широко распространенного встроенного инструментария языка. «Хорошая вещь в Rust — это то, что в ней есть функция, называемая трассировкой Токио», — сказал Янг. «Но особенность трассировки Tokio в том, что это не распределенная трассировка. Это больше похоже на трассировку стека… Проблема в том, что они работают немного по-другому. Трассировка Tokio не осуществляет распределенную трассировку».
Этот технический разрыв — между требованием OTel к распределенной трассировке и вниманием Tokio к трассировке стека — усугубляется проблемами обслуживания и динамики. «Tokio, как и компания Tokio, не занимается наблюдением, и отслеживание Tokio начинает выглядеть довольно неуправляемым», — сказал Янг. «Это просто неловкая ситуация, когда мы подумали, может быть, мы просто примем трассировку Токио в качестве официальной».
Ситуация с будущей интеграцией остается медленной и неопределенной. «На этой стороне никого нет дома, верно? Потому что кажется, что там не так уж много импульса», — сказал Янг. «Теперь, когда Токио отслеживает, я вижу: эй, что нам делать? Но это сообщество работает над этим. Просто медленно выясняется, что на самом деле является правильным предложением».
ТЕНДЕНЦИОННЫЕ ИСТОРИИ YOUTUBE.COM/THENEWSTACK Технологии развиваются быстро, не пропустите ни одной серии. Подпишитесь на наш канал YouTube, чтобы смотреть все наши подкасты, интервью, демонстрации и многое другое. ПОДПИСАТЬСЯ Группа, созданная в Sketch. BC Gain — основатель и главный аналитик ReveCom Media. Его одержимость компьютерами началась, когда в начале 1980-х он взломал консоль Space Invaders, чтобы играть весь день за 25 центов в местном игровом зале. Затем он… Подробнее от Б. Кэмерона Гейна.
