La encuesta de 2026 sobre interoperabilidad entre Prometheus y OpenTelemetry ya está publicada en el blog de OpenTelemetry. Recoge 186 respuestas (81 tras filtrar a usuarios finales de métricas con OTel y un backend cercano a Prometheus) y la comparan con la de 2024. La conclusión corta: la experiencia ha mejorado, pero las fricciones de fondo siguen ahí.
Qué cambia
Los datos que me parecen más útiles, tal como los publica el proyecto:
- Facilidad de uso: la valoración media pasa de 3,1 a 3,6 sobre cinco entre 2024 y 2026. Quienes la ven difícil bajan del 29 % al 10 %, y nadie eligió "muy difícil" (en 2024 fue el 7 %). Ojo: la muestra no es idéntica, porque en 2024 no se preguntó por el empleador.
- Infraestructura: exportadores de Prometheus (72 %), receptores de OTel (57 %),
/metricsintegrado (43 %) y OTLP push integrado (26 %). El 49 % mezcla ambos estilos. - Aplicaciones: SDK de OTel (65 %) y SDK de Prometheus (52 %). El 41 % usa solo OTel y el 31 % combina.
- Procesamiento: relabeling de Prometheus (54 %) y Collector de OTel de código abierto (53 %). El 65 % funciona con un "stack vanilla", sin herramientas comerciales ni modificaciones.
Las respuestas abiertas agrupan los problemas en tres bloques: modelos de datos distintos (atributos frente a etiquetas), huecos en recursos y metadatos, y fricción en nombres y formatos de métricas. También piden reglas de grabación nativas de Prometheus dentro del Collector.
Los mantenedores de Prometheus responden con un plan: llevar la unificación de atributos y etiquetas a la cumbre de desarrolladores de octubre, avanzar el diseño de metadatos nativos (que depende de cerrar la especificación de Entities de OTel) y trabajar para que OpenMetrics 2.0, PromQL con nombres UTF-8 y las estrategias de traducción del receptor OTLP sean el comportamiento por defecto. Hay además una propuesta con prueba de concepto para reglas de grabación en tiempo de scrape, y el proyecto Prometheus MCP se ha incorporado al repositorio de Prometheus.
Por qué importa en producción
Casi la mitad de los encuestados vive en un modelo híbrido, y es exactamente donde se concentran los problemas operativos: el mismo servicio emite métricas por dos caminos, con convenciones de nombres distintas, y los dashboards y alertas acaban con consultas que dependen de cómo se tradujo cada métrica por el camino.
Tres consecuencias prácticas:
- Los nombres no son estables por defecto. Mientras las estrategias de traducción del receptor OTLP no sean el valor por defecto, un cambio de configuración puede renombrar series y romper alertas sin que nada falle en el despliegue.
- Los metadatos de recurso se pierden o se aplanan. Si dependes de atributos de recurso (cluster, namespace, versión del servicio) para agregar, comprueba cómo llegan como etiquetas en tu backend.
- No hay una única forma "correcta". Los equipos de Plataforma y SRE tienden a preferir backends compatibles de código abierto y los de desarrollo prefieren Prometheus, pero la propia encuesta presenta esto como una observación con muestra pequeña, no como una conclusión firme.
Conviene leer los números con cautela: la muestra es pequeña, está filtrada y mezcla organizaciones muy distintas. Aun así, es de los pocos datos de uso real que hay sobre este tema.
Qué haría yo
- Inventariar por qué camino llega cada métrica clave (exportador, receptor OTel, SDK) y documentar la convención de nombres que sigue.
- Probar en un entorno de pruebas la traducción de nombres con UTF-8 antes de activarla en producción, y revisar las alertas que dependan de nombres con puntos o sufijos de unidad:
# comprueba qué series expone realmente tu backend para un servicio
curl -sG "$PROM_URL/api/v1/series" --data-urlencode 'match[]={job="mi-servicio"}' | jq '.data | length'- Fijar la estrategia de traducción del receptor OTLP de forma explícita en la configuración, en lugar de depender del valor por defecto, que puede cambiar.
- Si necesitas reglas de grabación sobre datos que pasan por el Collector, seguir la propuesta de reglas en tiempo de scrape antes de montar un TSDB intermedio.
- Participar o leer el canal #otel-prometheus de CNCF Slack si tu caso encaja en los problemas descritos.