Una alarma es un mensaje a una persona, no una línea en un log

Cualquier plataforma de monitorización puede detectar un problema. Lo difícil es la última milla: poner la alarma correcta delante de una persona que pueda actuar, en segundos, sin enterrar a esa persona bajo alarmas que no importan. Así enrutamos las alarmas en Zabbix, y así puede comprobar si su propia cadena funciona de verdad.

Detectar es barato, la atención es cara

La mayoría de las monitorizaciones no fallan porque se les escape un problema. Fallan porque nadie lee lo que producen. Las alertas por correo caen en una carpeta que se llena más rápido de lo que nadie puede vaciarla. Los paneles se ponen en rojo y siguen en rojo durante semanas, hasta que el rojo deja de significar nada. El ingeniero que al fin se da cuenta suele estar reaccionando a un cliente, no al monitor.

Añadir más comprobaciones no lo arregla. Lo que lo arregla es un diseño de enrutado que trate la atención de un ingeniero como el recurso más escaso que tiene, y la gaste solo en cosas que necesitan a un humano ahora.

Decida qué puede llegar a una persona

Empiece por la severidad, y sea estricto con ella. Cada trigger de Zabbix lleva una severidad, de información hasta desastre. Nosotros enrutamos solo las dos superiores, alta y desastre, al ingeniero de guardia, y cada trigger de ese nivel tiene que pasar una prueba: si esto salta de noche, ¿alguien tiene que actuar antes de la mañana? Si la respuesta honesta es no, es un aviso. Los avisos pertenecen a los paneles y a la revisión diaria, no al bolsillo de alguien.

En Zabbix esa decisión vive en dos sitios: las condiciones de la acción (la severidad del trigger es mayor o igual que Alta) y el filtro de severidad en el medio del usuario. Configure ambos, y haga que coincidan. Una acción que lo casa todo, combinada con un filtro de medio que descarta la mitad en silencio, es una configuración sobre la que nadie puede razonar a las tres de la madrugada.

Después suprima los ecos. Cuando cae un switch, cada host que hay detrás se vuelve inalcanzable también. Las dependencias de triggers le dicen a Zabbix que las alarmas de los hosts dependen de la alarma del switch, de modo que el ingeniero recibe una alarma que nombra la causa en lugar de cuarenta que nombran los síntomas.

Entréguela donde ya está el ingeniero

Nuestras alarmas salen de Zabbix por un webhook hacia un canal de operaciones dedicado en Mattermost, el chat en el que nuestros ingenieros trabajan todo el día y llevan en el teléfono por la noche. El chat gana al correo para las alarmas por razones prácticas. Es donde la gente ya mira. Muestra quién ha visto el mensaje. Y la conversación sobre la solución ocurre en el hilo bajo la alarma, de modo que el hilo se convierte en el registro de qué se hizo y cuándo.

Un buen mensaje de alarma lleva lo suficiente para actuar sin abrir otras tres herramientas: el host, el nombre del trigger, la severidad, el valor actual, cuánto lleva en ese estado y un enlace directo a la gráfica. Escriba la plantilla del mensaje una vez, con cuidado, y cada alarma que envíe en adelante se beneficiará de ella.

Haga visible la propiedad

Una alarma que vieron tres personas y nadie tomó es tan mala como una que nadie vio. El acuse de recibo cierra ese hueco. Cuando el ingeniero de guardia reconoce un problema en Zabbix, con una nota breve, todos los demás pueden ver que tiene dueño, y la nota es la primera línea del registro. Si su equipo tiene una segunda línea, un paso de escalado en la acción (una notificación adicional cuando un problema de severidad alta sigue sin reconocer tras un número fijado de minutos) convierte «ya lo mirará alguien» en una regla.

El trabajo planificado merece el tratamiento contrario: un equipo al que su propio mantenimiento le manda avisos aprende a ignorar los avisos, y ese hábito no se queda dentro de la ventana de mantenimiento.

Demuestre que funciona

Demuestre la cadena después de cada cambio

Nada de esto cuenta hasta que haya visto una alarma real recorrer todo el camino. Después de cada cambio en la plataforma de monitorización disparamos una alarma genuina y la cronometramos desde el trigger hasta el mensaje. Nuestro equipo de red ha escrito exactamente cómo ejecutar esa prueba, y cómo confirmar que cada dispositivo sigue oyéndose, en Pruebe la ruta de la alarma, no el panel. Conserve los tiempos que registre. Si el número va subiendo entre pruebas, algo en la cadena se está volviendo más lento, y lo ha aprendido de una prueba en lugar de una caída.

Ajuste por host, nunca silencie a ciegas

Las plantillas compartidas son donde nace la fatiga de alarmas. Un servidor de base de datos funciona legítimamente caliente, alguien sube el umbral de CPU en la plantilla para acallarlo, y todos los demás hosts del parque acaban de perder una alarma útil. Nosotros nunca editamos una plantilla compartida para ajustar una máquina. Los umbrales que tienen que diferir se fijan como overrides de macro a nivel de host, por ejemplo el valor propio de ese host de {$CPU.UTIL.CRIT}, de modo que ajustar una máquina nunca cambia las alarmas de otra.

La misma regla se aplica a desactivar triggers. Un trigger que salta todo el tiempo le está diciendo algo: o el umbral es incorrecto para ese host, o el host tiene un problema real. Desactivarlo para que el panel se ponga verde elimina al único testigo. Corrija el umbral en ese host, o corrija el host.

Vigile al vigilante

Un monitor que se ha parado es peor que ninguno, porque se confía en su silencio. Dos comprobaciones cubren la mayor parte del riesgo. Dentro de Zabbix, un trigger nodata en cada agente, como nodata(/<host>/agent.ping,5m)=1, caza un host que ha dejado de informar, que es un fallo distinto y más silencioso que un host que informa de problemas. Fuera de Zabbix, algo independiente tiene que notar cuando la propia plataforma se queda callada: un heartbeat que el servidor envía con una cadencia fija a un sistema separado, que levanta su propia alarma cuando el heartbeat deja de llegar.

También tratamos la plataforma de monitorización como producción: retención de base de datos aplicada, y una auditoría desde el hardware hacia arriba pasando por el sistema operativo, la base de datos, el demonio y la ruta de alerta.

Una segunda opinión antes de que la lea el ingeniero

Las reglas filtran primero el ruido conocido; después, cada alarma que queda es analizada en tiempo real por modelos de IA que se ejecutan en nuestras propias GPU NVIDIA A100, dentro de nuestro propio datacenter. El análisis mira la alarma junto con los eventos recientes, los hosts relacionados y los patrones conocidos, y coloca a su lado una breve segunda opinión: qué más cambió cerca, y qué ha significado antes este patrón. No decide nada y no avisa a nadie. Le ahorra al ingeniero los primeros minutos de mirar alrededor. Como los modelos se ejecutan en nuestro propio hardware, los datos de monitorización nunca salen de nuestra red y nunca se envían a un servicio público de IA.

Si construye algo parecido, mantenga el mismo límite. La IA anota la alarma. Una persona es dueña de la decisión.

Compruebe su propia cadena

• ¿Qué severidades llegan a una persona, y está esa decisión por escrito?
• ¿Puede todo el mundo ver quién es dueño de una alarma abierta?
• ¿Cuándo disparó alguien por última vez una alarma de prueba real y la cronometró de extremo a extremo?
• ¿Un fallo de switch llega como una alarma o como cuarenta?
• ¿Ha ajustado alguien un umbral editando una plantilla compartida?
• ¿Cuántos triggers están desactivados ahora mismo, y sabe alguien por qué?
• ¿Qué le avisa de que la propia plataforma de monitorización se ha parado?

Si quiere un segundo par de ojos sobre cómo llegan sus alarmas a su gente, estaremos encantados de mirar. Hable con un ingeniero

Related

Relacionado: Monitorización de flota y enrutado de alarmas · Telemetría de red y energía, logging, detección de DDoS