Su monitorización también es un sistema: pruebe la ruta, no el dashboard

Una pantalla de monitorización tranquila tiene dos significados posibles: todo va bien, o la monitorización no puede ver. Desde la pantalla sola no puede saber cuál. Toda pila de monitorización es una cadena de dispositivos, agentes, colectores, reglas y canales de notificación, y cada eslabón puede fallar sin levantar ninguna alarma propia. Este artículo trata de demostrar que la cadena funciona, de forma rutinaria, antes del día en que la necesite.

El silencio no es una prueba

La mayoría de los diseños de monitorización comprueban con cuidado las cosas monitorizadas y dan por supuesta la propia monitorización. Un switch está configurado para enviar syslog, así que se asume que sus logs llegan. Existe una regla de alarma, así que se asume que un aviso llega a alguien. Un trabajo de backup está programado, así que se asume que existe una copia de la configuración. Ninguna de esas suposiciones es una medición.

Los sitios donde esta cadena se rompe normalmente son mundanos: una interfaz de origen de logging o una instancia de routing que no puede alcanzar el colector, una regla de firewall en medio, una entrada del colector que se reconfiguró, una integración de notificaciones cuyo token caducó, un filtro de severidad de alarmas que excluye en silencio el tipo de evento que le importa. Ninguno de ellos hace que un dispositivo parezca enfermo desde su propia línea de comandos.

Comprobación uno: ¿se está oyendo de verdad a cada dispositivo?

La visión del dispositivo (show logging lista un servidor y dice que está activado) es una afirmación. La visión del colector es la prueba. Dele la vuelta y pregunte al colector: ¿cuándo envió algo por última vez cada dispositivo?

En Graylog, una búsqueda agrupada por origen sobre el último día muestra cada dispositivo que habló; compare esa lista con su inventario, y cualquier ausencia es su hallazgo. Una prueba sencilla de extremo a extremo desde el propio dispositivo elimina toda duda. En Cisco IOS y NX-OS, genere un mensaje inofensivo y búsquelo en el colector en cuestión de segundos:

send log 6 "monitoring path test from this device"

En un host Linux:

logger -p user.notice "monitoring path test from $(hostname)"

Si el mensaje no aparece, siga la ruta en orden: dirección de origen e instancia de routing usadas para el logging, alcanzabilidad del colector desde ese origen, cualquier firewall en medio, y después la entrada del colector y las reglas de stream.

Haga la misma comparación para los backups de configuración. Un dispositivo cuya última configuración guardada tiene semanas tiene una ruta de backup rota, aunque nunca haya dado error.

Comprobación dos: ¿llega una alarma a un ser humano?

Dispare una alarma real a través de toda la cadena a propósito: un trigger de prueba, un ítem ficticio que cruce un umbral o una firma de log que inyecte. Confirme que la notificación llega al canal que sus ingenieros leen de verdad, con la severidad correcta, en el tiempo que espera. Hágalo después de cualquier cambio en la propia plataforma de monitorización, y de forma programada aunque nada haya cambiado, porque los tokens caducan y las integraciones se desvían.

En Zabbix, basta con un ítem de prueba en un host monitorizado más un trigger con la severidad con la que avisa. Envíe un valor y vea cómo viaja:

zabbix_sender -z <zabbix-server> -s "<host>" -k monitoring.selftest -o 1

Después confirme tres cosas: el problema apareció, la notificación se entregó y la recuperación se entregó cuando restableció el valor.

Comprobación tres: ¿son honestas las severidades?

Revise qué eventos llegan a una persona y cuáles no. Una lista corta y explícita de firmas que siempre avisan (vecino de routing caído, enlace caído, BFD caído, fallos de cifrado de VPN, averías de alimentación, ventiladores y temperatura, errores en la red de storage, tablas de estado de firewall cerca de su límite) es más fácil de defender que un umbral que alguien fijó hace años.

Aquí ayuda una segunda opinión. Las reglas filtran primero el ruido conocido, y después todo lo que queda lo analizan en tiempo real modelos de IA sobre nuestras propias GPU NVIDIA A100, dentro de nuestro datacenter. El análisis lee una alarma junto con su historial reciente y los eventos relacionados y ofrece a los ingenieros una segunda opinión sobre lo que probablemente está ocurriendo. Los datos de las alarmas nunca salen de nuestra infraestructura, y la decisión sigue siendo del ingeniero.

Comprobación cuatro: mire desde fuera

Toda vista desde dentro de su red comparte los puntos ciegos de su red. Una plataforma de medición global como RIPE Atlas, con un anchor o probes midiendo hacia usted, muestra cómo le alcanzan lugares reales de internet: latencia, pérdidas y cambios de ruta. Cuando un operador hace mantenimiento, la vista exterior le dice cuánto tardó la reconvergencia y si alguien pudo notarlo, cosa que ningún contador interno puede.

Para circuitos privados, un probe dedicado en cada extremo que mida latencia, jitter y rendimiento en ambas direcciones cada minuto, almacenado de forma permanente, convierte cada conversación con un operador de opinión en datos. Excluya el tráfico del probe de las estadísticas del propio circuito para que la evidencia se mantenga limpia.

Comprobación cinco: barra cuando nada va mal

Ejecute barridos de salud de solo lectura de forma programada, no solo después de una alarma. Las variables ambientales, el estado del routing y del overlay, la consistencia de redundancia entre parejas, los niveles de las ópticas y los contadores de errores de las interfaces cambian despacio, y el cambio lento es exactamente lo que las alarmas por umbral pasan por alto. Una óptica que se desliza hacia su límite de luz baja es una sustitución tranquila esta semana o una caída el mes que viene.

Su lista de autocomprobación de la monitorización

• ¿Puede listar cada dispositivo que no ha enviado un log en el último día?
• ¿Puede listar cada dispositivo cuya configuración guardada es anterior a su último cambio?
• ¿Cuándo disparó por última vez una alarma real de extremo a extremo, y llegó?
• ¿Las severidades que avisan a una persona coinciden con una lista escrita?
• ¿Ve su red desde fuera, de forma continua?
• ¿Barre cuando no se sabe que nada vaya mal?

Monitorizamos nuestra red con Zabbix, Graylog, Observium y un anchor de RIPE Atlas, y ejecutamos estas comprobaciones contra ella de forma programada. Si quiere un proveedor que responda con mediciones, o ayuda para probar su propia cadena, hable con nosotros.

Hable con un ingeniero

Related (rows[1])

Relacionado: Monitorización de red y evidencias · Cómo cambiamos las cosas: disciplina de cambios en la red · Red propia: dos ASN, muchos operadores, peering