Siete años de OpenTelemetry: de dos proyectos rivales al estándar de observabilidad
Por Hector Hernandez Guzman
OpenTelemetry fue anunciado en mayo de 2019. Siete años después, se graduó de CNCF como el estándar de facto para recolectar telemetría:
- Más de 12,000 colaboradores de más de 2,800 empresas
- Más de 1,360 millones de descargas de la API de JavaScript y 1,300 millones de la API de Python durante el año anterior a la graduación
- Implementaciones estables de trazas y métricas en los principales ecosistemas de lenguajes
- Un protocolo neutral y un Collector utilizados por plataformas comerciales y de código abierto
El cambio práctico importa más que las cifras. Las bibliotecas pueden emitir telemetría una sola vez, las aplicaciones pueden decidir a dónde enviarla y las organizaciones pueden cambiar de backend sin reemplazar la instrumentación en todo su código.
Esa portabilidad no era inevitable. Requirió que comunidades competidoras acordaran APIs, modelos de datos y protocolos comunes, y que después probaran esas decisiones en lenguajes con convenciones muy distintas.
Me uní al SIG de Python en septiembre de 2019. Mi trabajo después se extendió a JavaScript, Node.js, observabilidad en navegadores y productos de Azure Monitor. Esta es la historia de cómo evolucionó el proyecto y cómo cambió mi rol junto con él.
2019: la fusión
OpenTelemetry fue anunciado el 21 de mayo de 2019 como la fusión de OpenTracing y OpenCensus.
OpenTracing ofrecía una API neutral para trazas. OpenCensus, originado en Google, proporcionaba bibliotecas para trazas y métricas. Ambos tenían adopción real, pero desarrolladores, autores de frameworks y proveedores todavía tenían que escoger entre ellos.
La fusión reemplazó esa competencia con una meta compartida: la telemetría debía integrarse al software mediante estándares abiertos, no agregarse después mediante soluciones propietarias. El nuevo proyecto entró al Sandbox de CNCF con un alcance amplio que incluía APIs comunes, SDKs para cada lenguaje, convenciones semánticas, un protocolo, un Collector y rutas de migración desde ambos proyectos.
Me uní cuatro meses después del anuncio. Mi primera contribución agregó tiempos explícitos de inicio y fin a los spans. Después trabajé en instrumentaciones tempranas de bases de datos para PyMongo, MySQL y psycopg2.
En esa etapa, la implementación ayudaba a definir el estándar. Las decisiones sobre nombres de spans, atributos y manejo de errores tenían que funcionar entre distintas bibliotecas y, con el tiempo, en todos los lenguajes de OpenTelemetry.
La conexión entre especificación e implementación era inmediata: el código revelaba dónde una idea era ambigua, mientras la especificación evitaba que cada lenguaje inventara una respuesta incompatible.
2020: construyendo las bases
Durante 2020, los SIGs de cada lenguaje construyeron APIs y SDKs de trazas, bibliotecas de instrumentación, exportadores, propagación de contexto y modelos de recursos. OTLP y el Collector evolucionaron al mismo tiempo.
La arquitectura separó la generación de telemetría de su procesamiento y almacenamiento. Las aplicaciones usan las APIs y SDKs de OpenTelemetry. OTLP proporciona una representación y un transporte estándar. El Collector puede recibir, enriquecer, muestrear, enrutar y exportar los datos a uno o varios backends.
Mi trabajo se extendió desde la API hasta uno de los primeros exportadores de métricas para Prometheus, además de exportadores de trazas y métricas para el Collector. Algunos usaron inicialmente componentes compatibles con OpenCensus mientras maduraba el soporte nativo de OpenTelemetry.
Esa experiencia influyó en mi trabajo posterior con los SDKs de Microsoft. Las capas de compatibilidad pueden resolver un problema inmediato de migración, pero sólo si sus límites permiten reemplazarlas cuando la implementación nativa está lista.
Fui agregado como Approver de Python en enero de 2020. Revisar contribuciones de otras personas me dio una perspectiva más amplia sobre cómo las decisiones de API, SDK y compatibilidad afectaban a todo el ecosistema.
2021: las trazas llegan a 1.0
El 10 de febrero de 2021, la especificación de OpenTelemetry llegó a la versión 1.0, estabilizando la API y el SDK de trazas, Context y Baggage. La implementación de trazas de Python llegó a 1.0 junto con otros lenguajes importantes.
Esto cambió la conversación sobre adopción. Los equipos podían depender de las interfaces principales de trazas sin esperar que cambiaran debajo de sus aplicaciones en producción.
OpenTelemetry se convirtió en un proyecto de incubación de CNCF en agosto. Ya contaba con APIs y SDKs en 11 lenguajes, más de 3,000 colaboradores, más de 20,000 pull requests y uso en producción por proveedores y organizaciones usuarias.
Mi trabajo diario estaba cambiando hacia los productos de OpenTelemetry para Azure Monitor. El contrato estable de trazas nos dio una base confiable, mientras el trabajo de producto exponía preguntas prácticas sobre migración, compatibilidad entre versiones y componentes experimentales dentro de distribuciones con soporte.
La versión 1.0 no terminó el proyecto. Estableció el contrato que permitió evolucionar las demás señales y los productos de producción sin desestabilizar las trazas.
2022: las métricas completan el modelo original
En 2022, OpenTelemetry anunció versiones candidatas de su especificación, APIs y SDKs de métricas. Java, .NET y Python salieron primero, seguidos poco después por JavaScript.
Las métricas reunieron APIs de lenguaje, agregación y vistas en los SDKs, soporte para OTLP, componentes del Collector e interoperabilidad con Prometheus dentro de un mismo modelo. Las trazas y las métricas podían describir un servicio usando la misma identidad de recurso y las mismas convenciones semánticas, aunque cada señal siguiera optimizada para necesidades distintas.
OpenTracing fue archivado formalmente por CNCF. Su misión había pasado a OpenTelemetry.
Este hito también me llevó al SIG de JavaScript. Mi primera contribución en JavaScript agregó métricas de duración para clientes y servidores HTTP a la instrumentación de Node.js. Al mismo tiempo, yo dirigía el Azure Monitor OpenTelemetry Distro para Node.js. En lugar de mantener una implementación específica de Microsoft, mejoramos la instrumentación de la comunidad que cualquier proveedor podía utilizar.
Trabajar entre Python y JavaScript hizo concreto el valor de la especificación. Cada implementación debe sentirse natural para su ecosistema, pero la telemetría que produce tiene que seguir siendo interoperable.
2023: se retiran los proyectos anteriores
La mayoría de los repositorios de OpenCensus fueron archivados en julio de 2023. Cuatro años después de la fusión, la etapa de los proyectos anteriores estaba casi cerrada.
Logs era una historia diferente. Cada lenguaje ya tenía un ecosistema de logging establecido, así que OpenTelemetry no podía simplemente reemplazarlo. El proyecto necesitaba conectar los frameworks existentes con un modelo de datos común, preservando el contexto de las trazas y la identidad de los recursos. La madurez siguió variando entre lenguajes.
Esa diferencia continúa siendo visible. En octubre de 2026, Logs sigue en desarrollo en JavaScript y Python, es una versión candidata en Go y es estable en otros lenguajes.
Trabajé en la integración de la API de Logs y en instrumentaciones para bibliotecas como Winston y Bunyan. El reto no era sólo exportar registros: también había que evitar telemetría duplicada, preservar contexto y respetar el comportamiento establecido de las aplicaciones.
Me convertí en Approver de OpenTelemetry JavaScript en mayo de 2023. Mi rol había cambiado de implementar funcionalidades aisladas a revisar compatibilidad, riesgo de versiones y consistencia en una superficie de APIs cada vez mayor.
2024: madurez operativa
Para 2024, la supervivencia de OpenTelemetry ya no estaba en duda. La seguridad y la confiabilidad se convirtieron en preocupaciones más importantes.
Una auditoría de seguridad independiente cubrió el Collector y los SDKs de Go, Java, C# y Python. Identificó un CVE, corregido antes de la publicación, y cinco recomendaciones de fortalecimiento. La auditoría también cumplió uno de los requisitos para la graduación de CNCF.
El Collector ilustró otro reto de madurez: sus componentes evolucionan de forma independiente. Algunos son estables y otros siguen en etapa experimental o de desarrollo, por lo que adoptar el Collector todavía requiere evaluar los componentes exactos de cada implementación.
En Azure Monitor, el OpenTelemetry Distro se estaba convirtiendo en la dirección estratégica para observabilidad en Node.js. Los clientes necesitaban más que trazas: métricas en vivo y estándar, logs, autoinstrumentación, diagnósticos y una ruta de migración desde Application Insights. Ese trabajo reveló huecos que las especificaciones y los ejemplos aislados no mostraban.
2025: aprender de la producción
Para 2025, la comunidad estaba resolviendo problemas visibles sólo después de años de uso en producción: evolucionar convenciones semánticas sin romper dashboards, mejorar el muestreo en sistemas distribuidos, simplificar el despliegue y aclarar por separado la madurez de SDKs, instrumentaciones y componentes del Collector.
Un ejemplo fue el muestreo probabilístico consistente. OpenTelemetry avanzó usando W3C Trace Context Level 2 y un umbral estándar de muestreo en tracestate, permitiendo decisiones más consistentes y estimaciones confiables entre servicios.
Volví a contribuir directamente en Python mediante métricas para clientes HTTP y la limpieza de las APIs y SDKs de Logs, y en diciembre regresé al grupo de Approvers de Python.
Trabajar en código upstream y productos downstream me hizo más sensible a cambios que se veían limpios dentro de un paquete, pero causaban problemas de migración o soporte para distribuciones y clientes.
También empecé a participar en el SIG de Web y Browser. La observabilidad en navegadores sigue menos madura que las trazas del lado del servidor, con preguntas abiertas sobre estandarización, rendimiento y privacidad.
2026: graduación de CNCF
OpenTelemetry se graduó de CNCF el 21 de mayo de 2026.
La graduación reconoce adopción en producción, gobierno neutral, salud de la comunidad, seguridad, estabilidad de APIs, documentación y madurez técnica. Para entonces, OpenTelemetry tenía más de 12,000 colaboradores de más de 2,800 empresas y la segunda mayor actividad de desarrollo dentro del ecosistema CNCF.
Mi propio alcance había crecido desde paquetes individuales de Python hasta responsabilidad técnica sobre SDKs de observabilidad para JavaScript, Web, Node.js y Python. También me convertí en component owner de las instrumentaciones de LangChain y OpenAI en OpenTelemetry JavaScript.
La observabilidad de GenAI ahora enfrenta un problema conocido: frameworks y proveedores producen telemetría distinta para operaciones similares. OpenTelemetry comenzó resolviendo exactamente ese tipo de fragmentación. La misma preferencia por converger debe guiar su siguiente etapa.
Por qué funcionó OpenTelemetry
OpenTelemetry tuvo éxito porque varias decisiones de diseño se reforzaron entre sí:
- Se enfocó en infraestructura compartida. Los proveedores pueden competir en almacenamiento, análisis y visualización en lugar de mantener bibliotecas de instrumentación incompatibles.
- La migración formó parte del diseño. Los puentes y las rutas de compatibilidad permitieron que los usuarios de OpenTracing y OpenCensus migraran gradualmente.
- Las especificaciones se probaron con código. Las implementaciones exponen debilidades en la especificación, mientras la especificación mantiene interoperables a las implementaciones.
- Cada lenguaje conservó su estilo. OpenTelemetry estandariza conceptos y resultados sin obligar a todos los ecosistemas a usar el mismo modelo de programación.
- El gobierno se mantuvo neutral. Plataformas de nube, proveedores de observabilidad, usuarios finales y colaboradores independientes mejoran el mismo estándar.
Estas decisiones crearon más que un conjunto de APIs y SDKs. Crearon infraestructura de coordinación para la industria de observabilidad.
Lo que sigue
El trabajo rara vez se queda dentro de un solo repositorio. Una decisión de especificación afecta a todos los lenguajes. Una convención semántica afecta consultas, dashboards, alertas y backends. Una decisión de migración puede determinar si los clientes adoptan el estándar.
Siete años entre proyectos upstream, distribuciones de Microsoft y migraciones de clientes me enseñaron a buscar esas conexiones desde el inicio. En 2019, la instrumentación abierta y portátil era una aspiración. Hoy, muchos desarrolladores la consideran la opción predeterminada.
Los siguientes retos incluyen observabilidad en navegadores y dispositivos móviles, convenciones para GenAI y aplicaciones con agentes, gobierno de esquemas, despliegues sin cambios de código y estabilización continua de lenguajes y componentes del Collector.
OpenTelemetry resolvió la división original entre OpenTracing y OpenCensus. La siguiente etapa es menos dramática y probablemente más difícil: hacer que el estándar sea más fácil de operar, gobernar y extender para cargas de trabajo que apenas existían en 2019.
Referencias
- A Brief History of OpenTelemetry
- OpenTelemetry Specification 1.0
- OpenTelemetry Python 1.0
- OpenTelemetry Becomes a CNCF Incubating Project
- OpenTelemetry Metrics Release Candidates
- CNCF Archives the OpenTracing Project
- Sunsetting OpenCensus
- OpenTelemetry Security Audit
- OpenTelemetry Sampling Update
- OpenTelemetry CNCF Graduation
- OpenTelemetry Component Status