OpenTelemetry застряло: почему проект буксует и что с этим делать
OTel isn't going well (and I made a spreadsheet about it)
Автор, инженер с многолетним опытом внедрения OpenTelemetry, анализирует причины, по которым проект кажется «недоделанным». Он собрал данные о активности в репозиториях OTel и сравнил их с другими проектами CNCF, такими как Envoy и Prometheus. Выяснилось, что проблема не в обсуждениях семантических конвенций, как многие думают, а в нехватке мейнтейнеров и концентрации работы в руках нескольких человек. Это приводит к медленному продвижению фич и стагнации. Автор приводит конкретные цифры и графики, показывающие дисбаланс, и объясняет, почему проект не может полагаться только на энтузиастов.
Проблема в том, что ожидания стабильности, по сути, заморозили проект на месте.
- EdSchouten
Меня всегда ставит в тупик в OpenTelemetry то, что трейсинг, метрики и логи проектируются независимо друг от друга. Хотелось бы, чтобы можно было один раз аннотировать свою кодовую базу, а окончательное решение о том, выставлять ли что-то как метрику, лог или трейс, принималось динамически во время выполнения.
Например, если я смотрю на график на дашборде мониторинга и вижу что-то подозрительное, я хочу сказать: «В следующий раз, когда что-то подобное произойдет, пожалуйста, сохрани мне трейс». Я должен иметь возможность сделать это одним щелчком мыши.
Помню, как они выпустили спецификацию/SDK для трейсинга и сказали: «теперь давайте перейдем к метрикам и логам». Это никогда не казалось мне правильным.
- bilalq
OTel — это так бесит. Если бы он не был явным победителем в этой области, я бы не жаловался на него так сильно. Но сегодня:
1. Каждый крупный вендор до сих пор находится в каком-то странном альфа/бета-статусе поддержки OTel, даже спустя столько времени.
2. Удар по производительности существенный, и начинаешь сомневаться, в чем смысл инструментирования производительности, если теперь для выполнения той же рабочей нагрузки нужно вдвое больше вычислительных мощностей/ОЗУ.
3. Серверные рантаймы платят высокую цену за холодные старты с OTel.
4. По сути, вы вынуждены запускать и шлюзовые коллекторы, и пограничные коллекторы для любого реального использования.
5. Вам все равно нужно настраивать экспортеры назначения уникальными способами. Это оставляет вас в недоумении, в чем же была ценность OTel.
6. Вендоры, которые выходят за рамки того, что покрывает OTel, все равно нуждаются в собственной специальной инструментации. Какой тогда был смысл во всем этом?
- cyberax
Я не согласен. Я фанат наблюдаемости, и OTel... нормальный.
В нем не хватает нескольких вещей, которые мне хотелось бы, но я смог реализовать их сам. Думаю, основная проблема дизайна в том, что решение о сэмплировании принимается в _начале_ сегмента. Поэтому я добавил несколько улучшений:
1. Возможность помечать сегменты как «скучные», чтобы они отбрасывались перед экспортом. Например, для проверок здоровья, пустых запросов «получить ожидающие задания» и т.п.
2. Возможность понижать уровень ошибок для сегментов, которые, как ожидается, вернут ошибку (например, HEAD на несуществующий объект в S3, чтобы проверить, есть ли кэшированный блоб).