Instrumentación nativa de Prometheus vs OpenTelemetry para métricas
Pocos debates en la observabilidad moderna están tan cargados de emociones como el de la instrumentación nativa de Prometheus frente a OpenTelemetry. Una publicación reciente titulada "Why I recommend native Prometheus instrumentation over OpenTelemetry" entusiasmó a la comunidad de Prometheus por esa misma razón. El artículo presentaba una recomendación clara y fundamentada sin atacar directamente a OpenTelemetry, en un momento en que gran parte del sector busca un único estándar universal.
Casi de inmediato, alguien señaló el matiz que faltaba:
This should probably say “for metrics.”
Esa pequeña aclaración resume casi toda la tensión de fondo en este debate.
El título encendió el debate
La primera gran objeción tuvo que ver con el alcance, y la precisión técnica apenas se discutió. Un comentarista sugirió que la publicación debió titularse:
Why I recommend native Prometheus instrumentation over OpenTelemetry for metrics
La instrumentación actual abarca métricas, trazas, registros, perfiles y eventos, y OpenTelemetry existe precisamente para unificarlos. El autor respondió que sí, pero que el título ya era largo y que, dentro del contexto de Prometheus, resultaba obvio que la discusión se centraba en las métricas.
Ese intercambio sitúa el argumento en su lugar correcto. El artículo compara ambos proyectos específicamente para la instrumentación de métricas y no evalúa a OpenTelemetry en su totalidad.
Prometheus se diseñó para métricas
Prometheus hace una sola cosa, métricas, y ese límite es una ventaja. Las librerías de cliente nativas de Prometheus están diseñadas en torno a contadores, indicadores de nivel, histogramas, resúmenes y un modelo de recolección pull, por lo que encajan a la perfección con el modelo de almacenamiento, el lenguaje de consulta y la filosofía de recolección. Al instrumentar de forma nativa no hay capas de traducción, conversiones semánticas, adaptadores ni exportadores intermedios. El camino es directo, y lo directo suele ser más simple.
La promesa de OpenTelemetry
OpenTelemetry promete algo más amplio: un SDK neutral frente a proveedores que gestiona métricas, trazas y registros. Para sistemas distribuidos con arquitecturas de múltiples niveles, esa propuesta resulta atractiva. Como señaló un comentarista, una vez que tienes aplicaciones de varios niveles necesitas trazas y registros para reducir el tiempo de análisis de causa raíz.
Tiene sentido. Las métricas indican que algo va mal y las trazas ayudan a comprender el motivo. Nadie en el hilo dudaba de la utilidad de las trazas. La duda pendiente es si las métricas de OpenTelemetry son la mejor vía cuando tu backend es Prometheus.
Dónde surge la fricción real
La fricción suele manifestarse en la arquitectura. Un usuario comentó que gestiona numerosos proyectos públicos y dispersos en Internet y prefiere la recopilación de estadísticas mediante push, ya que evita abrir reglas de firewall para un recolector central. Es una limitación técnica muy real. Prometheus se basa en pull, OpenTelemetry suele operar con flujos push y, si tu topología favorece el modelo push, los recolectores de OpenTelemetry pueden parecer el camino más accesible.
El precio que pagas es añadir más componentes: recolectores, pipelines, procesadores y posiblemente Alloy u otros agentes. Otro participante describió Alloy como básicamente Prometheus más exportadores y destinos de datos en un solo paquete, mostrando preocupación por que acabe convirtiéndose en software sobrecargado. También criticó la configuración con HCL calificándola de excesiva frente a archivos de configuración estructurados.
Esas quejas apuntan a una preocupación legítima. Los agentes universales añaden complejidad, y la complejidad rara vez se mantiene contenida.
La instrumentación nativa es aburrida, y esa es la clave
La instrumentación nativa de Prometheus es específica de cada lenguaje, estable, directa y se enfoca exclusivamente en métricas. No pretende resolver el trazado, exportar registros ni construir canalizaciones de señales cruzadas. Expone /metrics, Prometheus realiza el raspado y el trabajo queda listo.
Cuando operas una pila centrada en métricas con Prometheus como fuente de verdad, esa simplicidad aporta un gran valor. Evitas desajustes semánticos, vacíos de funcionalidad, casos límite en las traducciones y sorpresas en el comportamiento de agregación. Y, por encima de todo, tienes menos piezas móviles.
El riesgo oculto de la instrumentación universal
Los entornos de instrumentación universal envejecen de manera distinta a los diseñados para un solo propósito. Crecen incorporando capas, controles de configuración y modos de compatibilidad hasta que empiezan a resolver problemas que en realidad no tienes. Ahí es donde encaja la preocupación por el software inflado. OpenTelemetry no es pesado por definición, pero los agentes universales tienden a acumular responsabilidades, y cuando solo necesitas métricas, las librerías nativas de Prometheus resultan más ligeras.
Las métricas no lo son todo
El contraargumento resulta evidente. En sistemas complejos las métricas por sí solas no bastan: las trazas reducen el tiempo de análisis de causa raíz, los registros aportan contexto y correlacionar señales es muy útil. Si ya despliegas OpenTelemetry para el trazado, mantener una instrumentación separada para las métricas puede parecer redundante.
Esa es la bifurcación arquitectónica. Puedes optimizar cada señal para su ecosistema nativo o unificarlo todo bajo un único entorno de instrumentación, y ninguna de las dos opciones es idónea para todo el mundo.
La audiencia importa
El autor aclaró que el artículo fue escrito para un público de Prometheus, y ese contexto resulta fundamental. Si tu backend es Prometheus, tus consultas están en PromQL y tus alertas dependen de la semántica nativa de Prometheus, la instrumentación nativa encaja por defecto. No tienes que lidiar con capas de traducción ni depender de que los componentes de puente funcionen a la perfección, porque estás utilizando el sistema tal como fue concebido.
La arquitectura responde a restricciones
Observa de nuevo el dilema entre push y pull. Si las reglas de firewall impiden la recolección pull, tu diseño te llevará hacia recolectores. Si tu infraestructura está muy repartida por redes públicas, tal vez aceptes una sobrecarga adicional a cambio de una ingesta centralizada. Las limitaciones técnicas marcan el diseño, y la estrategia de instrumentación debe responder a tus restricciones antes que a una ideología.
Conclusión
El debate trata más sobre compatibilidad que sobre cuál proyecto es superior. La instrumentación nativa de Prometheus encaja con Prometheus, OpenTelemetry se adapta a estrategias de observabilidad de múltiples señales, y la fricción aparece cuando ambos objetivos se cruzan.
El artículo abrió la conversación porque tomó una postura clara, y las opiniones definidas son poco comunes en la observabilidad. La mayoría de los contenidos evita definirse y la mayoría de las herramientas prometen resolverlo todo, por lo que resulta agradable escuchar: "Si usas Prometheus para métricas, instrumenta directamente para Prometheus". Ese consejo deja espacio para trazas y registros y no ataca a OpenTelemetry. Apuesta por eliminar capas de abstracción innecesarias una vez que decides tu pila, y en infraestructura menos capas suele traducirse en menos sorpresas, lo que a las 3 AM suele ser lo que más importa.