ИИтог

OpenTelemetry буксует: мало мейнтейнеров и жёсткий гейт стабильности

инфраструктураРедакция ИИтогHacker News🔥56Рейтинг ИИтог56Влияние60Новизна48Релевантность70Неожиданность38Участники52Достоверность78

Автор блога matduggan.com, который по работе переводит команды с проприетарных SDK наблюдаемости (observability) на OpenTelemetry, годами слышал один и тот же вопрос от клиентов: почему проект до сих пор выглядит недоделанным. Чтобы проверить, реальна ли эта проблема или это просто ощущение сообщества, он решил не гадать, а собрать данные, сравнить активность мейнтейнеров OpenTelemetry с активностью в других проектах CNCF (Cloud Native Computing Foundation).

Самодельным Python-скриптом (автор сам называет его не самым надёжным инструментом и выкладывает сырые данные для проверки) он оценил распределение авторов, ревьюеров и людей, закрывающих задачи, за 24 месяца в проекте Envoy, и увидел здоровую картину: вклад распределён между многими участниками, а не держится на одном человеке (заметно выделяется контрибьютор phlax, но без него проект не рассыплется). SDK OpenTelemetry для PHP за тот же период выглядит иначе: работа сконцентрирована на 2 людях, по словам автора, это «нездоровый» для опенсорса расклад, и проект просто не может позволить себе такой штат для задачи подобного масштаба. С Ruby, по его наблюдению, «та же история» (точных цифр для Ruby, Go, Python и Dotnet автор не приводит, ограничиваясь качественными сравнениями). Go и Dotnet он называет самыми крепкими SDK в экосистеме OpenTelemetry.

Главный вывод автора, не просто нехватка мейнтейнеров, а «столкновение сразу трёх факторов»: жёсткий гейт стабильности (фичу, однажды помеченную стабильной, менять уже нельзя), маленький штат реальных мейнтейнеров и огромный охват, десятки языков, сотни библиотек. Вместе это создаёт стимул до бесконечности спорить о потенциальных рисках любой новой фичи ещё до того, как её зафиксируют как стабильную.

Автор описывает, как устроен путь фичи от идеи до релиза. Работа делится на Core (небольшая, стабильная, вендоронезависимая часть, которую ведёт сама команда OpenTelemetry) и Contrib (широкий, быстро меняющийся слой интеграций от сообщества и вендоров); похожее деление действует и для коллектора, компонента, который собирает и пересылает логи, метрики и трейсы: под свои нужды его обычно приходится собирать через OpenTelemetry Collector Builder, что для многих команд само по себе ощутимый объём работы. Путь фичи: предложение (OTEP) → раздел спецификации → semantic-conventions (репозиторий, где обсуждения тянутся дольше всего и где дизайн фактически фиксируется навсегда) → реализация в SDK каждого языка (некоторые SDK уже пошли на breaking-изменения версии 2.0) → пакеты contrib (версионируются независимо, поэтому гибче) → коллектор и протокол OTLP (у каждого компонента, по словам автора, свой «разбросанный» жизненный цикл стабильности). Сколько именно занимает переход от OTEP к спецификации, автор выяснить не смог, предсказуемого цикла в истории репозитория он не нашёл.

Проверяя, где именно застревают фичи, автор ожидал, что виноват репозиторий semantic-conventions, и частично оказался прав: часть его PR-ов (запросов на изменение) действительно тянется подолгу. Но эта медлительность, вопреки ожиданиям, не переходит в код самих SDK, эти обсуждения остаются изолированными. Для Python самые медленные PR вообще не связаны с semantic-conventions: их тормозит отдельная обязательная проверка Approve Public API, требующая подтверждения ещё одного мейнтейнера, и это снова упирается в нехватку людей.

В качестве решения автор предлагает добавить временный уровень «бета» между текущими статусами «Experimental» (экспериментальный) и «Stable» (стабильный): фича проходит путь Experimental → Beta → через 12 месяцев либо становится Stable, либо удаляется. Логика в том, что сейчас, по оценке автора, 99% пользователей вообще не знают, когда в проекте появляется очередная экспериментальная фича, для них она как будто не существует. Гарантия, что фича не исчезнет как минимум 12 месяцев, и большая видимость для конечных пользователей, по мнению автора, дали бы проекту куда больше реальной обратной связи. Он отмечает, что статус «бета» в OpenTelemetry уже существует, но применяется непоследовательно: похоже, он касается только SDK целиком (например, SDK для Rust помечен как Beta), а не отдельных компонентов (Profiles, судя по всему, бетой быть не может), и, как признаёт сам автор, до конца разобраться в системе маркировки ему не удалось.

При этом автор отдаёт OpenTelemetry должное: в отличие от вендорских SDK, проект действительно не отдаёт предпочтение ни одному конкретному поставщику наблюдаемости, редкий случай для настолько прибыльной и конкурентной ниши, притом что большинство мейнтейнеров работают именно в компаниях-вендорах. Он также отмечает, что мейнтейнеры стараются вести обсуждения публично: протоколы встреч разных рабочих групп ему было легко найти и прочитать.

Ключевые факты

  • Автор блога matduggan.com сравнил активность мейнтейнеров пяти SDK OpenTelemetry (Go, Dotnet, Python, PHP, Ruby) с CNCF-проектами Envoy и Prometheus за 24 месяца, используя собственный (по его словам, не идеальный) Python-скрипт.
  • PHP-SDK OpenTelemetry держится на 2 разработчиках, это, по словам автора, нездоровая для опенсорса модель; с Ruby «та же история», а Go и Dotnet выглядят крепче.
  • Причина медленных релизов, «столкновение трёх факторов»: жёсткий гейт стабильности (стабильную фичу нельзя менять), маленький штат мейнтейнеров и огромный охват языков и фреймворков.
  • Путь фичи идёт через OTEP → спецификацию → semantic-conventions (где обсуждения длятся дольше всего) → SDK → contrib → коллектор/OTLP; задержки в semantic-conventions не переходят в SDK, там тормозит отдельная проверка Approve Public API, требующая ещё одного мейнтейнера.
  • Автор предлагает добавить между статусами Experimental и Stable временный уровень Beta с гарантией 12 месяцев без удаления, по его оценке, сейчас 99% пользователей не замечают, когда появляется экспериментальная фича.

Почему это важно

OpenTelemetry, фактический стандарт вендоронезависимой телеметрии (логи, метрики, трейсы), и именно к нему подталкивают команды, уходящие от проприетарных SDK наблюдаемости. Если, как показывает разбор автора, ключевые части экосистемы держатся на 1-2 мейнтейнерах, а любая новая фича проходит через долгий процесс из-за жёсткого гейта стабильности, это прямо влияет на то, сколько ждать нужных возможностей и насколько вообще можно полагаться на официальную дорожную карту проекта.

Кому это важно

Инженерным и SRE-командам, которые выбирают между вендорским SDK и OpenTelemetry, особенно небольшим командам без ресурсов разбираться в шероховатостях. Тем, кто уже опирается на конкретные языковые SDK: по данным автора, зрелость сильно разнится, Go и Dotnet выглядят крепче, PHP и Ruby держатся на очень малом числе людей. И самим мейнтейнерам и governance-структуре CNCF/OpenTelemetry, к которым обращено предложение о промежуточном статусе Beta.

Как это применить

Перед тем как переводить команду на OpenTelemetry, стоит отдельно проверять здоровье SDK именно для нужного языка, а не полагаться на репутацию проекта в целом, по наблюдениям автора, разрыв между языками велик. Для функций со статусом Experimental стоит закладывать риск, что они могут не стать стабильными ещё долго, и требовать от команды явного решения, готова ли она на них полагаться. Само предложение автора (переходный статус Beta с гарантией 12 месяцев) пока не принято проектом, это только идея для обсуждения, а не факт из дорожной карты OpenTelemetry.

Можно ли доверять

Это независимый разбор одного инженера-практика, а не официальный отчёт OpenTelemetry или CNCF. Метод, самодельный Python-скрипт для оценки активности контрибьюторов, который сам автор называет не идеальным инструментом; он публикует сырые данные, чтобы читатели могли проверить и раскритиковать выводы. Часть находок, качественные сравнения без точных цифр (для Go, Python, Dotnet и Ruby конкретные числа контрибьюторов не приводятся, кроме «2 человек» на PHP-SDK), так что к выводам стоит относиться как к обоснованной гипотезе практика, а не к точному измерению.

Риски и подводные камни

Оценка «99% пользователей не замечают экспериментальные фичи», субъективное мнение автора, не результат опроса. Путаница со статусами уже существует и внутри самого OpenTelemetry: Beta сейчас применяется непоследовательно (к SDK, но не к компонентам), и даже автор признаёт, что не смог до конца разобраться в системе маркировки. Команде, которая полагается на конкретный языковой SDK OpenTelemetry (особенно PHP или Ruby, по словам автора держащиеся на очень малом числе людей), стоит учитывать риск: уход даже одного-двух мейнтейнеров может ощутимо замедлить или остановить развитие именно этого SDK.

«Реальная проблема внутри OpenTelemetry, это столкновение сразу трёх факторов.»

— автор блога matduggan.com