OTel não está indo bem
OpenTelemetry (OTel) está emergindo como o padrão de fato de observabilidade, mas muitos engenheiros o consideram excessivamente arquitetado, lento e complexo em comparação com ferramentas mais simples e focadas, como Prometheus, Jaeger ou soluções específicas de fornecedor, como Datadog e AWS X-Ray. Os críticos apontam SDKs pesados, documentação confusa, custos de desempenho e de cold start (especialmente em ambientes serverless) e padrões de integração desajeitados, enquanto os defensores argumentam que um padrão aberto comum para traces, métricas e logs ainda é a melhor forma de evitar lock-in de fornecedor e permitir interoperabilidade. A discussão destaca uma tensão mais ampla entre padrões flexíveis e ambiciosos e ferramentas leves e construídas para um propósito específico, além do desejo por uma melhor experiência do desenvolvedor e abstrações mais coerentes entre os pilares da observabilidade.
Sentimento geral sobre OTel
- Muitos veem o OTel como excessivamente arquitetado, complexo e imaturo, especialmente em comparação com ferramentas mais simples e focadas.
- Outros argumentam que ele é “bom o suficiente” ou “importante” como um padrão comum; não é perfeito, mas é o melhor caminho disponível para interoperabilidade.
- Uma tensão recorrente: metas ambiciosas e design pesado vs. usabilidade prática, desempenho e clareza.
Complexidade, APIs e experiência do desenvolvedor
- SDKs e instrumentação são descritos como “assustadoramente complexos”, “maximalistas no estilo Java/XML” e “design por comitê”.
- A auto-instrumentação frequentemente quebra aplicativos não triviais; pacotes contrib são vistos como frágeis e difíceis de personalizar.
- Estado global, métodos estáticos, lógica oculta de “inject” e uniformidade entre linguagens são criticados; muitos querem clientes simples, explícitos, no estilo DI.
- A documentação é amplamente considerada ruim, inconsistente e às vezes incorreta; alguns usuários preferem ler o código-fonte, inspecionar o tráfego e usar exporters de debug em vez disso.
Desempenho, custo e serverless
- Vários usuários relatam sobrecarga substancial de CPU/memória, especialmente em Python/Ruby e Lambda; penalidades de cold start podem ser severas.
- Para Lambda, layers do OTel e a distribuição OTel da AWS são vistos como pesados em comparação com ferramentas antigas do X-Ray ou agentes de fornecedores.
- Há preocupação de que o monitoramento possa custar mais do que executar o app; o trade-off entre “imposto do OTel” e lock-in de fornecedor.
Modelo de tracing, métricas e logs
- Debate sobre se tracing, métricas e logs devem ser unificados ou são fundamentalmente distintos.
- Alguns sugerem instrumentar uma vez com “events/spans” genéricos e derivar logs/métricas/traces dinamicamente; outros dizem que isso é conceitualmente elegante, mas na prática frágil, caro ou difícil de escalar.
- Sampling adaptativo e agregação no lado da ingestão são citados como estratégias do mundo real; o custo geralmente é dominado pelo armazenamento.
Alternativas e ecossistemas
- Muitos elogiam Prometheus (com exporters, node/blackbox exporters, Mimir/VictoriaMetrics) e Jaeger/Tempo por modelos mentais mais simples e confiabilidade.
- Alguns preferem stacks auto-hospedadas (Grafana + Loki/Tempo/Mimir, VictoriaMetrics, stacks baseadas em ClickHouse, SigNoz), mas observam fragmentação e múltiplas linguagens de consulta como pontos problemáticos.
- Para configurações de baixo atrito, que “simplesmente funcionam”, fornecedores proprietários (Datadog, AWS CloudWatch/X-Ray, etc.) são vistos como mais fáceis, porém com forte lock-in.
Padrões vs. realidade
- O valor do OTel como uma especificação OTLP neutra em relação a fornecedores e um esquema comum é reconhecido.
- Há frustração de que, apesar do padrão, exporters ainda precisem de particularidades por fornecedor e muitos vendors ofereçam apenas suporte parcial, bugado ou de segunda classe ao OTel.