OTel no va bien
OpenTelemetry (OTel) está emergiendo como el estándar de facto de observabilidad, pero muchos ingenieros lo consideran sobrediseñado, lento y complejo en comparación con herramientas más simples y centradas como Prometheus, Jaeger o soluciones específicas de proveedores como Datadog y AWS X-Ray. Los críticos señalan SDK pesados, documentación confusa, costes de rendimiento y de cold start (especialmente en entornos serverless) y patrones de integración incómodos, mientras que los defensores argumentan que un estándar abierto común para trazas, métricas y logs sigue siendo la mejor forma de evitar el bloqueo con proveedor y facilitar la interoperabilidad. El intercambio pone de relieve una tensión más amplia entre estándares flexibles y ambiciosos frente a herramientas ligeras y específicas, así como el deseo de una mejor experiencia de desarrollo y abstracciones más coherentes entre los pilares de la observabilidad.
Sentimiento general sobre OTel
- Muchos consideran que OTel está sobrediseñado, es complejo e inmaduro, especialmente en comparación con herramientas más simples y centradas.
- Otros sostienen que está “bien” o es “importante” como estándar común; no es perfecto, pero es la mejor vía disponible hacia la interoperabilidad.
- Una tensión recurrente: objetivos ambiciosos y diseño pesado frente a usabilidad práctica, rendimiento y claridad.
Complejidad, APIs y experiencia de desarrollo
- Los SDK y la instrumentación se describen como “desconcertantemente complejos”, “maximalistas al estilo Java/XML” y “diseño por comité”.
- La auto-instrumentación a menudo rompe aplicaciones no triviales; los paquetes contrib se perciben como frágiles y difíciles de personalizar.
- Se critican el estado global, los métodos estáticos, la lógica oculta de “inject” y la uniformidad entre lenguajes; muchos quieren clientes simples, explícitos y al estilo DI.
- La documentación se considera ampliamente deficiente, inconsistente y a veces incorrecta; algunos usuarios terminan leyendo el código fuente, inspeccionando el tráfico y usando exportadores de depuración.
Rendimiento, coste y serverless
- Varios usuarios informan de una sobrecarga sustancial de CPU/memoria, especialmente en Python/Ruby y Lambda; las penalizaciones en cold start pueden ser severas.
- Para Lambda, las capas de OTel y la distribución de OTel de AWS se ven pesadas en comparación con herramientas antiguas de X-Ray o agentes de proveedores.
- Preocupa que la monitorización pueda costar más que ejecutar la aplicación; la disyuntiva entre el “impuesto de OTel” y el bloqueo con proveedor.
Modelo de trazas, métricas y logs
- Hay debate sobre si trazas, métricas y logs deben unificarse o si son fundamentalmente distintos.
- Algunos sugieren instrumentar una sola vez con “eventos/spans” genéricos y derivar logs/métricas/trazas dinámicamente; otros dicen que eso es conceptualmente elegante pero en la práctica frágil, caro o poco escalable.
- El muestreo adaptativo y la agregación en el lado de ingesta se citan como estrategias reales; el coste suele estar dominado por el almacenamiento.
Alternativas y ecosistemas
- Muchos elogian Prometheus (con exporters, node/blackbox exporters, Mimir/VictoriaMetrics) y Jaeger/Tempo por modelos mentales más simples y fiabilidad.
- Algunos prefieren pilas autoalojadas (Grafana + Loki/Tempo/Mimir, VictoriaMetrics, pilas basadas en ClickHouse, SigNoz), pero señalan la fragmentación y los múltiples lenguajes de consulta como puntos dolorosos.
- Para configuraciones de baja fricción, de “simplemente funciona”, los proveedores propietarios (Datadog, AWS CloudWatch/X-Ray, etc.) se ven como más fáciles, pero con fuerte bloqueo.
Estándares frente a realidad
- Se reconoce el valor de OTel como especificación OTLP agnóstica del proveedor y esquema común.
- Frustra que, a pesar del estándar, los exporters sigan necesitando particularidades por proveedor y que muchos solo ofrezcan soporte parcial, defectuoso o de segunda categoría para OTel.