OpenTelemetry y Prometheus se entienden mejor, aunque siguen faltando piezas
Una encuesta eleva la facilidad de uso conjunta de ambos sistemas y Atlassian cuenta cómo movió las métricas de 100.000 hosts a OpenTelemetry.
OpenTelemetry y Prometheus llevan años compartiendo stack de observabilidad sin entenderse del todo, y los números empiezan a moverse. Una encuesta publicada esta semana sitúa la facilidad de uso conjunta en 3,6 sobre 5, frente al 3,1 de la edición anterior, y baja del 29% al 10% la proporción de quienes consideran complicado usar los dos a la vez. En paralelo, Atlassian ha contado cómo trasladó la recogida de métricas de 100.000 hosts desde gostatsd hasta OpenTelemetry.
Lo que dice la encuesta
El estudio sobre interoperabilidad entre Prometheus y OpenTelemetry señala que casi la mitad de los encuestados mezcla instrumentación de estilo Prometheus y de estilo OTel para métricas de infraestructura. En métricas de aplicación, el porcentaje que combina ambas es del 30,7%.
Los responsables del proyecto lo atribuyen al trabajo acumulado. "Dos años de trabajo en interoperabilidad están dando resultado", resumen los contribuidores de OpenTelemetry Dhruv Ahuja (SigNoz), Andrej Kiripolsky y Arthur Sens (Grafana Labs) y Ana Muenz. Queda tarea pendiente, y las peticiones que más se repiten son concretas: mejor alineación entre los modelos de datos de los dos proyectos, un tratamiento más limpio de los atributos de recurso y los metadatos, y menos problemas de nombres y formatos.
Atlassian y los 100.000 hosts
El caso de Atlassian viene de lejos. Su canal de métricas se apoyaba en gostatsd, su implementación en Go del StatsD de Etsy, y funcionaba con unos 100.000 hosts repartidos por 14 regiones. El problema no era el rendimiento, sino el desfase: cada vez más piezas del sistema emitían datos en formato OTel que el canal no sabía leer.
La migración se hizo manteniendo la interfaz que veían los servicios y cambiando solo la maquinaria por debajo, de modo que un cambio de toda la organización se convirtió, en palabras de sus autores, en una migración de equipo de plataforma. Los resultados que reportan: la agregación consume ahora cerca de la mitad de CPU para el mismo tráfico, la carga se reparte mejor entre los fragmentos de ingesta, el OTel Collector unifica la operación y el coste de los sidecars cae alrededor del 30% a escala de flota.
El coste de no ver
New Relic publicó su Observability Forecast 2026, con 2.575 responsables y profesionales de TI encuestados. El 73% ya se ha estandarizado en OTel, está migrando o lo está probando. El 83% considera la observabilidad imprescindible para el código generado por IA, y quienes monitorizan agentes de IA tienen el doble de probabilidad de declarar un retorno triple de su inversión en observabilidad que quienes los ejecutan a ciegas.
El dato incómodo está en la operación diaria: los ingenieros dedican el 37% de su tiempo a atender interrupciones y el 42% de las organizaciones se entera de ellas por canales poco eficientes, como comprobaciones manuales o quejas de clientes. La firma cifra las pérdidas medias por caídas de alto impacto en 74 millones de dólares al año.
Lo que falta no es adopción, sino encaje fino. Los modelos de datos siguen sin coincidir del todo, la monitorización de cargas de inferencia está por resolver y los atributos de recurso son el punto donde más se tropieza. Para quien tiene que operar esto, la conclusión práctica es que la combinación ya no es un experimento, pero tampoco es enchufar y listo: conviene revisar cómo se traducen etiquetas y metadatos antes de dar por buena una migración.
