Observabilidad real contra monitoreo pasivo: dashboards de Grafana que sirven en guardia

El problema de la mayoría de las organizaciones no es que falten métricas. Es que sobran.

Un turno de guardia típico tiene el dashboard de Grafana pareciendo la cabina de un avión: cuarenta gráficas de CPU, memoria y disco, todas moviéndose, ninguna respondiendo la única pregunta que importa a las 3 de la mañana. ¿El usuario puede comprar o no puede comprar? Eso es monitoreo pasivo. Mide la máquina y confía en que la máquina represente al usuario. Casi nunca lo hace.

Deja de mirar la CPU

CPU al 90% no es un problema. A veces es un proceso batch bien optimizado exprimiendo el hardware que ya pagaste. Lo que sí es un problema es que el 5% de los checkouts tarde más de dos segundos, y eso no aparece en ninguna gráfica de sistema.

Aquí conviene ordenar el vocabulario, porque circula mezclado y las tres cosas tienen autor:

• Las cuatro señales doradas: Son del capítulo 6 del libro de SRE de Google: latencia, tráfico, errores y saturación. Esa cuarta es la que se cae de casi todas las listas que se citan por ahí. Saturación es "cuán lleno está tu servicio", enfatizando el recurso más restringido.
• RED: Creado por Tom Wilkie en 2015 (Rate, Errors, Duration). Es deliberadamente distinto para microservicios sin estado, eliminando saturación.
• USE: Creado por Brendan Gregg en 2012 (Utilization, Saturation, Errors) para medir el nodo o hardware, no el servicio.

SLI, SLO, SLA, y el error budget

Las definiciones del capítulo 4 del libro de SRE sin adornos: El SLI es la medida cuantitativa. El SLO es el objetivo sobre esa medida. El SLA es el contrato con consecuencias. Si no hay consecuencia explícita ante un fallo, es simplemente un SLO.

"El 99.9% de los logins se completa en menos de 500 ms" es un SLO. "El sistema debe ser rápido" es una aspiración con formato de requisito.

De ahí sale el error budget. Si tu objetivo es 99.9%, tienes un presupuesto de error del 0.1% sobre la ventana. Ese presupuesto es tuyo. Gástalo, para eso está.

Las tablas de burn rate, con los números correctos

La tabla 5-8 del SRE Workbook, para un SLO del 99.9% sobre 30 días, tiene tres filas fundamentales:

PromQL que no miente

Umbrales estáticos tipo cpu > 80% alertan sobre causas posibles, no sobre daño real. Antes de las consultas, tres reglas de oro sobre rate():

1. Los reinicios de contador sí se manejan: Prometheus ajusta automáticamente las rupturas de monotonía.
2. Peligro con gauges: Usar rate() sobre un gauge genera datos erróneos. Usa solo contadores.
3. Primero rate, después agregación: Siempre ejecuta sum(rate(x[5m])) y no al revés.

No consultes 30 días de golpe

Lo correcto es grabar una ventana corta y promediarla sobre el periodo mediante reglas de grabación:

sum_over_time(job:slo_errors_per_request:ratio_rate5m{job="api"}[30d])
/
count_over_time(job:slo_errors_per_request:ratio_rate5m{job="api"}[30d])

No escribas esto a mano

Existen excelentes opciones para automatizar este proceso sin mantener cientos de líneas de reglas PromQL a mano:

• Sloth: Open source, genera reglas de grabación y alertas multiventana desde especificaciones YAML.
• Pyrra: Soporta cuatro tipos de SLOs, incluyendo histogramas nativos.
• Grafana SLO: Integración en Grafana Cloud gestionable por Terraform.

Sobre la carga de guardia

Según el libro de SRE de Google, un incidente cuesta en promedio 6 horas contando remediación y postmortem, derivando en un máximo sostenible de 2 incidentes por turno de 12 horas.