OTel под огнём критики: сложность SDK и дизайна¶
7.0/10
В статье Мэта Даггана «OTel isn’t going well» представлен критический разбор OpenTelemetry: автор утверждает, что SDK стали чрезмерно сложными, а дизайн сигналов — трейсов, метрик и логов — фрагментирован. Отмечаются проблемы с автоматической инструментацией, «ява-центричностью», избыточной абстракцией и хранением состояния, а также опасения по поводу производительности и лишнего сетевого трафика. Материал сопровождается таблицей (spreadsheet) с деталями, хотя сам исходный текст в задании отсутствует. Обсуждение на Hacker News подтверждает практические боли: SDK плохо подходят для длительных функций, durable execution и Cloudflare Workflows, хотя конечный результат трейсинга в таких сервисах, как Axiom, пользователи хвалят.
Контекст¶
OpenTelemetry (OTel) — это открытый проект CNCF, который стал стандартом де-факто для observability в облачных приложениях: он предоставляет единый набор API, SDK и Collector (прокси-конвейер для приёма, обработки и экспорта телеметрии), позволяющий собирать распределённые трассы, метрики и логи. Ключевая идея OTel — вендор-нейтральность: код инструментируется один раз, а данные затем можно отправлять в любую совместимую систему мониторинга. При этом SDK OTel включают возможности семплирования спанов, агрегации метрик и обогащения данных, что на практике, как отмечают критики, приводит к значительной сложности и избыточному проектированию.
Влияние¶
Для инженеров, внедряющих OpenTelemetry, главное практическое следствие — заметные затраты на освоение и настройку SDK, а также риск деградации производительности и избыточного трафика в высоконагруженных или serverless-сценариях. Особенно уязвимы распределённые durable execution и длительные функции, где текущая модель автоматической инструментации даёт сбои.
Обсуждение¶
В комментариях пользователи согласны, что конечные результаты трейсинга могут быть хорошими, но SDK вызывают разочарование из-за переусложнённости, автоматической инструментации и «ява-измов»; osener отмечает сбои в durable execution, Cloudflare Workflows и функциях, живущих часами или днями. EdSchouten хотел бы единую аннотацию кода с динамическим выбором метрики, лога или трейса в рантайме, а Havoc и greatgib жалуются на неудобство self-hosted решений и опасения по поводу производительности; brikym возражает, что инструментация не главная проблема, если понимаешь бизнес-события.