Práctica: escribir, probar y medir recording rules

De las consultas costosas a las series registradas #

Contexto. Tu panel recalcula los mismos agregados en cada actualización. Vas a registrarlos en series dedicadas, con las métricas del propio Prometheus y sin ninguna otra dependencia.

Requisitos: Docker Compose, curl y jq  ·  Duración estimada: 40 min

Crea una carpeta de trabajo para esta práctica.

1. 1. Iniciar Prometheus

   ¿Por qué? Prometheus se recopila a sí mismo: dispones de inmediato de métricas HTTP reales.

   Escribe docker-compose.yml y prometheus.yml. Activa la recarga en caliente y referencia un archivo rules.yml.

2. 2. Registrar un primer agregado

   ¿Por qué? Agregar por etapas evita volver a leer las series en bruto en cada nivel.

   Crea rules.yml con la tasa por job y handler y después la tasa por job, reutilizando la regla anterior. Crea también un tests.yml vacío (touch tests.yml), comprueba, inicia y consulta la nueva serie al cabo de un minuto.

3. 3. Añadir un ratio de errores robusto y un percentil

   ¿Por qué? Sin precaución, el ratio queda vacío mientras no exista ningún error.

   Añade la tasa de errores 5xx, el ratio de errores (que debe valer 0 sin errores) y el percentil 95 de la duración. Recarga y comprueba el estado de las reglas.

4. 4. Escribir las pruebas unitarias

   ¿Por qué? Una regla errónea da un panel creíble pero falso: solo una prueba lo revela.

   En tests.yml, cubre dos casos: 10 % de errores (ratio 0,1) y ningún error (ratio 0). Lanza las pruebas, quita la parte or ... * 0 del ratio, observa cómo falla la segunda prueba y vuelve a ponerla.

5. 5. Medir la ganancia

   ¿Por qué? Una optimización se mide.

   Compara las muestras leídas por la consulta original y por la serie registrada, y localiza el tiempo de evaluación de tus reglas con prometheus_rule_group_last_duration_seconds. Debes ver una sola muestra para la serie registrada y varios centenares para la consulta original (el valor depende de tu instancia).

Nivel de dificultad : ●●●○○ (3/5)