OpenTelemetry no va bien, y lo demuestro con una hoja de cálculo
OTel isn't going well (and I made a spreadsheet about it)
Un ingeniero analiza la salud de OpenTelemetry comparando la actividad de sus repositorios con la de otros proyectos de CNCF como Envoy y Prometheus. Los datos revelan una concentración extrema del trabajo en pocos mantenedores, especialmente en SDKs como PHP y Ruby, y un proceso de estandarización lento debido a la tensión entre la promesa de estabilidad binaria y el enorme alcance del proyecto. El autor argumenta que la falta de financiación y la complejidad hacen insostenible el modelo de contribución voluntaria, y que el proyecto necesita un cambio estructural para no quedarse congelado.
El problema real dentro de OpenTelemetry es una colisión triple: una puerta de estabilidad binaria que, combinada con un banco muy reducido de mantenedores reales, crea un incentivo para discutir interminablemente sobre posibles problemas de cada característica, porque una vez marcada como estable, ya no se puede cambiar.
- EdSchouten
Lo que siempre me desconcierta de OpenTelemetry es que el tracing, las métricas y los logs están diseñados de forma independiente. Desearía que hubiera una forma de anotar mi base de código una sola vez, y dejar que la decisión final de exponer algo como métrica/log/trace sea dinámica en tiempo de ejecución.
Por ejemplo, si miro un gráfico en el panel de monitoreo y veo algo sospechoso, me gustaría decir: "La próxima vez que algo así vuelva a ocurrir, por favor guárdame un trace". Debería poder hacerlo con un solo clic del ratón.
Recuerdo que lanzaron la especificación/SDKs de tracing y dijeron "ahora pasemos a métricas/logs". Eso nunca me pareció bien.
- bilalq
OTel es tan frustrante. Si no fuera el claro ganador en este espacio, no me quejaría tanto. Pero hoy:
1. Cada gran proveedor sigue teniendo un soporte extraño en alpha/beta para OTel incluso después de todo este tiempo.
2. El impacto en el rendimiento es sustancial y te hace preguntarte cuál es el punto de la instrumentación de rendimiento si necesitas el doble de cómputo/RAM para ejecutar la misma carga de trabajo ahora.
3. Los runtimes serverless pagan una gran penalización en los arranques en frío con OTel.
4. Básicamente estás obligado a ejecutar tanto collectors de gateway como collectors de edge para cualquier uso realista.
5. Aún tienes que configurar los exporters de destino de formas únicas. Esto te deja preguntándote cuál era el valor de OTel.
6. Los proveedores que van más allá del alcance de OTel aún necesitan su propia instrumentación a medida. ¿Cuál era el punto de todo esto entonces?