Monitoreado en el papel
Los productos tenían Prometheus, Grafana y reglas de alerta. En cualquier checklist aparecerían como monitoreados. Lo que me hizo desconfiar fue una API pública que estuvo diez minutos caída, y quien lo notó fue un monitor externo, no el nuestro.
Decidí seguir el camino completo de una alerta, desde la métrica hasta una persona recibiendo el mensaje. En varios clústeres, la ruta raíz de Alertmanager apuntaba a un receptor nulo: la alerta se evaluaba y se tiraba. En uno de ellos, 36 alertas activas se iban al vacío. Un enrutador de mensajes descartaba en silencio todo lo de un producto porque el prefijo del nombre tenía un punto, y un canal estuvo 113 días vacío sin que nadie lo notara. Además, las reglas eran casi todas de saturación, como CPU, disco y conexiones. Una base, una cola o una caché podía caerse sin abrir ningún incidente.
Medir lo que usa el cliente
Empecé por lo que siente el cliente. Implementé el Blackbox Exporter para sondear la API pública cada 30 segundos, con alerta crítica tras dos minutos caída y ruta directa al NOC. Los manifiestos quedaron versionados y el token del webhook en un Secret, fuera de Git.
En un producto donde el servicio crítico es la conexión de las instancias con el canal de mensajería, no existía una métrica lista. Creé la señal a partir de los logs: un pipeline en Grafana Alloy que recolecta solo los eventos de conexión y desconexión, descartando cerca del 99% del volumen en el origen, y una regla que detecta desconexión masiva.
Reglas de caída, con cuidado
Escribí reglas de indisponibilidad para PostgreSQL, Redis, Dragonfly, RabbitMQ, Elasticsearch, MongoDB y Kafka en los distintos productos, configuradas para que la desaparición de una métrica también cuente como caída. Antes de encender cualquiera, medí la cobertura de 24 horas de cada señal y las oscilaciones de los cinco días anteriores, para que las reglas nuevas no se volvieran ruido.
En una de ellas, la cuenta no cerraba. La alerta de broker de Kafka esperaba tres brokers caídos, pero el clúster tenía cinco y un tópico interno con factor de replicación 1. Un solo broker caído ya era un incidente. Corregí el umbral y versioné las reglas en el Git del producto.
Probar que llega
Reescribí el enrutamiento de Alertmanager con destinos separados para el NOC, el canal del producto y el chat del equipo, con las alertas críticas yendo al NOC y el ruido conocido contenido a propósito. Antes de aplicarlo, probé la matriz de enrutamiento con amtool en 12 casos y, después, revisé el log del operator.
En el camino, corregí detalles que mataban la entrega sin ningún error: el prefijo con punto, una agrupación que dejaba vacío el nombre de la alerta para el enrutador y una ruta que exigía un label con un espacio al final.
La prueba final fue con alertas sintéticas: 38 disparos en cuatro productos, 38 entregadas en el chat y en el canal del producto, y el conteo coincidiendo uno a uno en el NOC. En la auditoría siguiente todavía encontré una regresión: un webhook que yo había validado días antes había dejado de existir en el gateway del NOC. Quedó documentado y corregido.
Por último, eliminé un falso positivo recurrente (una regla que, sin datos, mantenía el último estado y quedaba trabada disparando después de que el problema ya había pasado) y estandaricé el nombre de todas las reglas con el prefijo del producto en cuatro clústeres, por script, preservando los labels de enrutamiento.
Qué cambió
La caída de cualquier base, cola o caché principal pasó a abrir un incidente, algo que antes no ocurría en varios productos. Las alertas que se descartaban pasaron a llegar a tres destinos, con la entrega comprobada por prueba. La API pública ganó su propio monitoreo de disponibilidad.
Lo que me llevo
Una alerta solo existe cuando alguien la recibe. Escribir la regla es la parte fácil; el monitoreo es el camino entero hasta una persona, probado. Por eso ningún cambio de enrutamiento mío se validó con "la configuración parece correcta".
Y una regla de saturación no reemplaza una regla de caída. Una base al 50% de CPU está bien. Una base que desapareció tampoco está saturada.