Contadores de Prometheus: por qué confunden tras Datadog

Ciertas frustraciones solo dan la cara después de una migración.

Cambias de una solución como Datadog a Prometheus, reconstruyes los paneles, reescribes las alertas y todo parece más ágil, más abierto y bajo tu control. Entonces los contadores empiezan a engañarte, o al menos esa es la impresión.

Los contadores de baja frecuencia pierden incrementos. Las series efímeras desaparecen de los totales. Las tasas de éxito no terminan de cuadrar al cabo de 30 días. Las alertas no saltan cuando deberían o, peor aún, se disparan tarde.

Un equipo lo describió sin rodeos: los contadores han sido el mayor dolor de cabeza desde la migración. Cosas que antes funcionaban solas ahora exigen un análisis exhaustivo y, aun creyendo haberlo resuelto bien, la inquietud persiste. ¿Es Prometheus poco fiable o le estamos pidiendo que actúe como algo que nunca pretendió ser?

La queja principal: contadores lentos más etiquetas dinámicas igual a inquietud

El problema se manifiesta en varios escenarios predecibles:

• Alertar sobre el incremento de un contador cuando este no comienza en cero.
• Calcular los incrementos totales durante un intervalo temporal, sobre todo cuando existen series efímeras.
• Observar la frecuencia de los incrementos como una serie temporal sin artefactos extraños.
• Calcular tasas de éxito a largo plazo mediante sum(rate(success_total[30d])) / sum(rate(overall_total[30d])) y descubrir que las series efímeras distorsionan los resultados.

Existe además una frustración añadida: los datos brutos están ahí. Si miras la gráfica con atención, a menudo ves con claridad lo que debería contarse, pero rate() o increase() parecen subestimar las cifras.

Ese comportamiento es intencionado. Prometheus prefiere subestimar antes que sobrestimar cuando detecta situaciones límite como reinicios o scrapes fallidos. Para los SRE, este sesgo de seguridad puede parecer contradictorio, ya que en muchos entornos reales un falso negativo en una alerta resulta peor que un falso positivo. Cuando tu sistema de monitorización antepone la cautela a la sensibilidad, puedes sentir que te está fallando.

La primera realidad: los contadores muy lentos resultan incómodos

Un profesional con experiencia fue directo al grano: los contadores de movimiento muy lento son un asunto peliagudo en Prometheus.

Si realizas el scrape cada 30 segundos y un contador solo se incrementa una vez cada 20 minutos, trabajas con datos dispersos. Añade ahora etiquetas dinámicas, pods efímeros, reinicios por despliegues y eventos de autoescalado. Ya no estás midiendo una serie monotónica limpia. Estás midiendo fragmentos de contadores repartidos entre instancias.

Prometheus gestiona los reinicios de contadores, pero no puede reconstruir el historial ausente de pods que ya desaparecieron. Nadie está haciendo las cosas mal; es pura física del sistema.

La trampa de la cardinalidad

Una de las recomendaciones más recurrentes consiste en reducir la cardinalidad en las métricas esenciales de SLO.

Demasiados equipos añaden etiquetas pensadas para depuración directamente en los contadores de errores:

• user_id
• request_id
• feature_flag
• shard
• deployment hash

Da sensación de control, pero es la receta perfecta para la dispersión. Las series dispersas reducen la fiabilidad de rate() porque la ventana temporal puede abarcar series que solo existieron durante una pequeña fracción de ese periodo. Tu consulta de tasa de éxito a 30 días pasa a incluir decenas de microseries que aparecieron y desaparecieron en un instante.

Las métricas están concebidas para responder a "¿hay algún problema en un momento determinado?". No están pensadas para reemplazar a los logs. Cuando sobrecargas los contadores con etiquetas de nivel forense, estás forzando a Prometheus más allá del diseño para el que fue creado.

Procesos efímeros: el saboteador invisible

Otro comentario incisivo calificó las métricas de corta duración como un antipatrón.

Si utilizas workers efímeros despachados por cola o computación de tipo FaaS, tus contadores pueden:

1. Arrancan.
2. Incrementan una vez.
3. Desaparecen.

El cálculo de increase() tiene entonces que reconciliar series que solo existieron durante unos pocos scrapes, y ahí es donde surge esa extraña infravaloración de datos.

Una solución mencionada fue recurrir a exportadores acumuladores. En vez de que cada worker efímero exponga su propio contador, envías los incrementos a un acumulador central (al estilo StatsD) y dejas que Prometheus haga el scrape sobre esa fuente estable. En arquitecturas modernas, puedes utilizar deltas acumulativos de OpenTelemetry que alimenten un único recolector de agregación.

La conclusión es siempre la misma: estabiliza el contador antes de que Prometheus lo lea. A Prometheus le gustan las series temporales duraderas y no se lleva bien con las métricas intermitentes.

La inyección de marcas de tiempo de creación no es mágica

Para contadores que no arrancan en cero, Prometheus admite ahora la inyección de marcas de tiempo de creación en cero mediante OpenMetrics. Eso mitiga ciertas ambigüedades en el arranque, pero no elimina todos los casos límite.

Si un pod se reinicia y tu intervalo de scrape se pierde parte de su ciclo de vida, seguirás viendo datos incompletos. Prometheus intenta gestionar los reinicios de forma inteligente, pero por diseño peca por defecto de subestimar. Si esperabas una "reconstrucción perfecta de deltas", estás esperando algo que Prometheus no promete.

Reglas de registro: aburridas, potentes y subestimadas

El enfoque de SLO de Grafana emplea reglas de registro por capas como esta:

Codesum(sum_over_time((grafana_slo_success_rate_5m{})[28d:5m])) / sum(sum_over_time((grafana_slo_total_rate_5m{})[28d:5m]))

Parece enrevesado, pero hay un motivo claro para semejante estructura. Preagregar en deltas estables de 5 minutos mediante reglas de registro hace que el cálculo de SLO a largo plazo sea inmensamente más fiable.

Una sugerencia fundamental fue probar las reglas de registro. Emplea promtool test rules y añade alertas por si las reglas de registro dejan de evaluarse. Si no las pruebas, estás confiando en una fontanería invisible; si las pruebas, resultan sorprendentemente sólidas.

La paradoja es que muchos equipos confían más en consultas PromQL directas que en las reglas de registro, a pesar de que las reglas de registro bien verificadas suelen ser mucho más seguras.

El problema de los números de coma flotante (sí, es real)

Prometheus utiliza números de coma flotante, lo que significa que los contadores pierden la precisión de +1 en magnitudes muy elevadas (alrededor de 2^53). La mayoría de las cargas de trabajo web nunca alcanzarán esa cota, pero las interfaces de red de alta velocidad o las agregaciones masivas sí pueden hacerlo.

Una solución ingeniosa planteada fue envolver los contadores uint64 mediante módulo 2^53 antes de exportarlos. Es un caso muy específico, pero recuerda que Prometheus tomó compromisos de diseño en sus inicios que todavía tienen repercusiones en la actualidad.

Métricas frente a logs: la crisis de confianza

Bajo las quejas técnicas subyace un dilema de mayor calado. Cuando los equipos empiezan a sugerir "quizá deberíamos usar logs para esto", están hablando de confianza más que de matemáticas.

Las métricas pierden credibilidad cuando fallan en los casos límite. Cuando una consulta de tasa de éxito a 30 días arroja resultados dispares según el tamaño de la ventana, la confianza se deteriora.

La parte incómoda es que las métricas nunca se diseñaron para ser sistemas de contabilidad forense impecables. Son señales aproximadas y agregadas. Los logs aportan precisión, mientras que las métricas aportan escalabilidad. Si exiges a los contadores la exactitud de los logs, la decepción está garantizada.

La propuesta más interesante: "métricas materializadas"

Una propuesta a largo plazo planteada en el debate fue incorporar un nuevo pipeline dentro de Prometheus que convierta los scrapes de vuelta a deltas para rematerializarlos después en contadores proyectados tras reducir etiquetas. Eliminarías instance y otras dimensiones efímeras, agregarías los deltas en primer término y reconstruirías contadores estables a continuación.

Es una idea ambiciosa que reconoce un problema central: muchos usuarios razonan en deltas y no en contadores acumulativos. Buscan semántica orientada a eventos con el rendimiento escalable de las métricas. Si algo así llega a publicarse, podría transformar por completo la percepción de los contadores.

¿Son entonces los contadores "muy poco fiables"?

No, pero son implacables.

Los contadores de Prometheus son extremadamente fiables cuando:

• Las series son duraderas.
• La cardinalidad está controlada.
• Los intervalos de scrape coinciden con la frecuencia de los eventos.
• Se utilizan reglas de registro para cálculos a largo plazo.
• Mides el estado de salud del sistema y no auditas transacciones.

Empiezan a dar problemas cuando:

• Mezclas etiquetas de depuración en métricas de SLO.
• Dependes de procesos efímeros.
• Esperas una reconstrucción perfecta tras los reinicios.
• Extiendes rate() a lo largo de 30 días con series fragmentadas.

El título que los tachaba de "muy poco fiables" era una exageración admitida, pero la frustración existe. Prometheus no está roto; sencillamente, los modelos mentales heredados de Datadog no encajan de forma directa.

Prometheus te obliga a reflexionar sobre intervalos de scrape, ciclos de vida de las series, impacto de las etiquetas y estrategias de agregación. Esa carga mental parece un retroceso al principio, hasta que comprendes que responde a un contrato distinto y, como en casi todos los contratos de sistemas distribuidos, la letra pequeña es lo que cuenta.