..

SLOs en la práctica con Prometheus

De la Teoría a la Práctica

En el capítulo anterior, introdujimos los conceptos de SLI (Indicador de Nivel de Servicio) y SLO (Objetivo de Nivel de Servicio) como las herramientas fundamentales para medir la fiabilidad. Ahora, vamos a ver cómo podemos implementar estas ideas utilizando herramientas estándar en la industria: Prometheus para la recolección de métricas y su lenguaje de consulta PromQL.

Asumiremos que estamos monitorizando un servicio web que expone métricas de Prometheus, incluyendo:

  • http_requests_total: Un contador con etiquetas (labels) como code (ej. “200”, “500”) y method (ej. “GET”, “POST”).
  • http_request_duration_seconds: Un histograma que mide la latencia de las peticiones.

SLI de Disponibilidad: Peticiones Exitosas

Nuestro primer SLI medirá la disponibilidad, definida como el porcentaje de peticiones que no devuelven un error del servidor (códigos 5xx).

SLI: El ratio de peticiones HTTP que se completan con éxito (código < 500). SLO: 99.9% en los últimos 28 días.

Para calcular este SLI con PromQL, necesitamos dos cosas: el total de peticiones que consideramos “malas” y el total de peticiones.

# SLI de Disponibilidad en PromQL

# Peticiones "malas" (errores de servidor) en los últimos 28 días
sum(rate(http_requests_total{code=~"5.."}[28d]))

# Total de peticiones en los últimos 28 días
sum(rate(http_requests_total[28d]))

Podemos combinar esto en una única consulta para obtener nuestro nivel de disponibilidad actual:

# Ratio de disponibilidad
1 - (sum(rate(http_requests_total{code=~"5.."}[28d])) / sum(rate(http_requests_total[28d])))

Esta consulta nos dará un valor entre 0 y 1. Multiplicado por 100, es el porcentaje de disponibilidad que podemos comparar directamente con nuestro SLO del 99.9%.

SLI de Latencia: Peticiones Rápidas

No basta con que el servicio responda; debe hacerlo rápido.

SLI: El porcentaje de peticiones a la home (/) que se completan en menos de 300ms. SLO: 95% en los últimos 28 días.

Aquí es donde los histogramas de Prometheus brillan. Un histograma agrupa las observaciones (en este caso, la duración de las peticiones) en cubos (buckets) configurables. Por ejemplo, podríamos tener buckets para < 0.1s, < 0.3s, < 1s, etc.

La función histogram_quantile es útil para saber la latencia del percentil 95 o 99, pero para un SLO, es más robusto usar la función rate() sobre los buckets del histograma.

# SLI de Latencia en PromQL

# Peticiones rápidas (menos de 300ms) a la home en los últimos 28 días
sum(rate(http_request_duration_seconds_bucket{path="/", le="0.3"}[28d]))

# Total de peticiones a la home en los últimos 28 días
sum(rate(http_request_duration_seconds_count{path="/"}[28d]))

La etiqueta le="0.3" en el bucket del histograma nos da el número de peticiones que tardaron menos o igual a 0.3 segundos.

La consulta completa para el SLI de latencia sería:

# Ratio de latencia
sum(rate(http_request_duration_seconds_bucket{path="/", le="0.3"}[28d]))
/
sum(rate(http_request_duration_seconds_count{path="/"}[28d]))

Conclusión

Hemos traducido los conceptos teóricos de SLI y SLO a consultas prácticas de PromQL. Estas consultas son la base para crear dashboards en Grafana que muestren el estado de nuestros SLOs y, como veremos en el próximo capítulo, para calcular nuestro Error Budget y generar alertas cuando este se consume demasiado rápido.