Las tres de la mañana, una alerta y ninguna pista
Cuando una alerta se disparaba de madrugada, la persona de guardia recibía un mensaje con el nombre de la regla y nada más. Para investigar, tenía que descubrir sola qué dashboard abrir, qué panel mirar y si alguien había hecho deploy a esa hora.
Hice una auditoría en los seis entornos de producción y conté 871 reglas de alerta activas. Solo 40 de ellas, el 4,6%, llevaban a algún panel. Y cuando abrí esos pocos vínculos, la mayoría estaba mal. Apuntaban a paneles de tipo gauge, que muestran el valor del instante sin la curva y sin marcas de eventos. En un caso, la alerta de disco de la base llevaba al panel de tamaño de la base de datos, que es otra magnitud. Quien hiciera clic iba a investigar el número equivocado, y con confianza.
Ningún producto tenía una vista RED de sus servicios (tasa, errores y duración), y ningún Grafana mostraba cuándo había ocurrido un deploy.
Cada alerta apunta a su propia condición
Mapeé regla por regla por la métrica que evalúa, y no por el nombre del panel. Creé los paneles de serie temporal que faltaban y un dashboard completo para el almacenamiento de objetos, con 18 paneles de salud, capacidad, tráfico y latencia. Vinculé cada regla al panel exacto y repetí el enlace en la descripción de la alerta, porque la descripción es lo que aparece en el mensaje de guardia.
Para que esto no se deshiciera con el tiempo, traté la numeración de los paneles como un contrato, de modo que editar un dashboard no rompa enlaces ya publicados, y escribí un script que valida que cada enlace de alerta apunte a un panel que existe. Las reglas fueron a Git y pasaron por promtool antes de aplicarlas.
RED, rápido
Construí dashboards RED en cuatro productos. Donde había instrumentación de aplicación, usé SigNoz, a partir de traces. Donde solo existía la vista del borde, usé las métricas de ingress-nginx en Prometheus.
El histograma bruto de latencia del ingress tenía 238.800 series, y Prometheus rechazaba la consulta en una ventana de seis horas. Creé recording rules que preagregan por servicio y lo bajan a 228 series. Las 12 consultas del dashboard pasaron a responder en 0,05 segundos.
En cada panel escribí una descripción de lo que mide y de cómo leer el número, pensando en quien no es especialista. Ya en la primera lectura, los dashboards mostraron cosas que nadie veía, como un servicio con casi la mitad de las respuestas en error 5xx. En un producto también armé el panel de colas y comparé las métricas con los offsets reales del broker: un 1% de diferencia.
La línea vertical del deploy
La primera pregunta de cualquier incidente es "¿cambió algo?". Configuré ArgoCD Notifications para publicar cada deploy como anotación en Grafana, y cada gráfico pasó a mostrar una línea vertical en el momento en que subió una versión.
Antes de aplicarlo aparecieron dos trampas, y medí las dos. El token de Grafana tenía que quedar en un Secret fuera del release de Helm, porque un helm upgrade reescribiría el Secret y borraría el token sin ningún error. Y, en aplicaciones con varias fuentes, el campo de revisión del ejemplo oficial venía vacío, lo que haría que la notificación se disparara una vez y nunca más. Usé la fecha de conclusión del deploy como clave. La carga retroactiva publicó los deploys antiguos a la hora exacta, verificada al segundo.
Qué cambió
Las alertas pasaron a llevar a la persona de guardia directo al gráfico de la condición que se disparó, por ejemplo 39 de 39 reglas en un entorno y 12 de 12 en otro, con los enlaces validados por script. Los productos ganaron una vista RED por servicio, rápida incluso en ventanas largas, y los gráficos pasaron a mostrar cuándo hubo deploy.
Lo que me llevo
Un dashboard solo ayuda si responde la pregunta que hizo la alerta. Vincular la alerta al panel "más parecido" es peor que no vincularla, porque lleva a la persona al número equivocado. Y un buen panel enseña: la descripción de cada gráfico es documentación para quien está de guardia a las tres de la mañana.