Привет, киты 🐋! Как поддерживать наблюдаемость при изменении конвенций OpenTelemetry

Большая часть конвенций в OTEL все еще не помечена stable, а это значит что от версии к версии могут меняться названия метрик, лейблов, спанов, атрибутов логов (вот посмотрите https://t.me/letitkit/223). И как с этим жить? Ведь на это завязаны доски Grafana, алерты, расчет SLO.

Вариант 1. Закрепить версию библиотеки и просто на ней сидеть например год. Возможно? Да. Риски: CVE уязвимости, которые нужно закрыть в середине года.

Вариант 2. Обертки библиотек OTEL и свой "золотой набор" метрик, которые в требуете с приложений, а если их нет - не пускаете в прод. Т.к. вам нужна сквозная наблюдаемость и предсказуемость, чтобы не знать 10 вариантов одной и той же метрики.

Вариант 3. Гибридный. Принимать метрики от разных версий OTEL, но складывать это в одно представление.
Такой вариант предлагает HoneyComb https://www.honeycomb.io/blog/managing-opentelemetry-semantic-convention-migrations-collector
Для этого даже в OTEL Collector есть специальный schemaprocessor (правда только в alfa-версии). Непонятно, как он будет решать случаи, когда метрик просто не стало (удалили, например, метрик rpc было 10 в 1.37, а в 1.39 оставили 2).

Вариант 4. Skyscanner https://opentelemetry.io/blog/2026/devex-skyscanner/
Дропают большинство SDK-generated HTTP и RPC метрик по умолчанию. Генерируют свои метрики из Istio service mesh spans через spanmetrics connector
Используют transform processor для приведения к semantic conventions. Обновляются раз в 6 месяцев с постепенным rollout (Dev → Alpha → Beta → Production)

Как вы решаете эту проблему?