Error budgets y alertas por burn rate: avisar por los motivos correctos
Cómo convertir un SLO en alertas que saltan rápido ante caídas reales, callan ante el ruido y dejan de avisar cuando el problema se resuelve.
Los ejemplos son genéricos e ilustrativos. No provienen del entorno de ningún cliente: adapte umbrales y configuraciones a su propio sistema.
Empiece por lo que vive el usuario
La mayoría de las alertas ruidosas viene de alertar sobre causas — CPU, memoria, un pod reiniciado — en lugar de sobre lo que siente el usuario. Un indicador de nivel de servicio (SLI) mide esto directamente: la proporción de solicitudes válidas que fueron buenas. Buena puede significar una respuesta sin error de servidor, una respuesta más rápida que un umbral, o ambas.
Un objetivo de nivel de servicio (SLO) fija una meta para esa proporción en una ventana — por ejemplo, el 99,9% de las solicitudes con éxito en 30 días. La diferencia hasta el 100% es el error budget: aquí, el 0,1% de las solicitudes, o unos 43 minutos de caída total en el mes.
Por qué fallan las alertas de umbral fijo
Una alerta como «tasa de error superior al 1% durante 5 minutos» es demasiado sensible y demasiado lenta a la vez. Avisa por un pico breve que consumió una fracción mínima del budget y nunca salta ante una tasa de error del 0,5% que quema todo el budget en una semana, sin hacer ruido.
El burn rate lo resuelve. Es la velocidad a la que se consume el budget en relación con el SLO: un burn rate de 1 gasta exactamente el budget a lo largo de la ventana; uno de 14,4 gasta un budget de 30 días en poco más de dos días.
Alertas multiventana y con varios burn rates
El enfoque descrito en el SRE Workbook de Google combina cada umbral de burn rate con una ventana larga, que prueba que el problema es relevante, y una ventana corta, que prueba que sigue ocurriendo. Para un SLO del 99,9% en 30 días, un punto de partida habitual es:
- Avisar: burn rate superior a 14,4 en 1 hora y en 5 minutos — el 2% del budget gastado en una hora.
- Avisar: burn rate superior a 6 en 6 horas y en 30 minutos — el 5% del budget gastado.
- Ticket: burn rate superior a 1 en 3 días y en 6 horas — el 10% del budget gastado.
# Fast-burn page for a 99.9% availability SLO (error budget = 0.001)
(
sum(rate(http_requests_total{job="api", code=~"5.."}[1h]))
/ sum(rate(http_requests_total{job="api"}[1h]))
) > (14.4 * 0.001)
and
(
sum(rate(http_requests_total{job="api", code=~"5.."}[5m]))
/ sum(rate(http_requests_total{job="api"}[5m]))
) > (14.4 * 0.001)La ventana corta importa tanto como la larga: en cuanto llega la corrección, la proporción de 5 minutos baja y la alerta se resuelve, en lugar de seguir sonando el resto de la hora.
Detalles que deciden si funciona
- Recording rules: precalcule la tasa de error de cada ventana para que las expresiones de alerta sigan siendo baratas y legibles.
- Poco tráfico: con pocas solicitudes por minuto, un solo fallo es una proporción grande. Exija un número mínimo de solicitudes o mida con sondas sintéticas.
- SLOs de latencia: cuente como eventos malos las solicitudes más lentas que el umbral, con buckets de histograma que incluyan el valor del umbral.
- Exclusiones: decida de antemano si cuentan los errores del cliente y los health checks, y anótelo junto al SLO.
Para qué sirve el budget
El budget es una herramienta de decisión, no solo un buscapersonas. Mientras está sano, el equipo puede desplegar más rápido y asumir cambios más arriesgados. Cuando se agota, el trabajo de confiabilidad pasa por delante de las funcionalidades hasta que la tendencia se recupere. Acuerde esa política con los responsables de producto antes del primer incumplimiento, no durante él.