Alertas de monitorización útiles: activación, recuperación y entrega en Fleetd

Reunir servidores y routers en una consola facilita el trabajo, pero la monitorización queda a medias si todavía hay que abrirla cada día para descubrir problemas. Las alertas parecen el siguiente paso: CPU elevada, disco casi lleno, equipo sin conexión.

Es fácil escribir una regla. Lo difícil es que el aviso ayude a decidir qué hacer. Si cada pico envía correo y cada fallo persistente se repite continuamente, terminamos ignorándolo. Y no recibir mensajes tampoco demuestra que todo esté bien.

Esta quinta entrega explica Fleetd v0.3.0. Tras instalar el cliente en Linux y OpenWrt, seguimos el recorrido del informe hasta la alerta, la notificación y su resolución.

Qué representa una alerta

Fleetd comprueba ausencia de informes, CPU, memoria, espacio, inodes, servicios fallidos, contenedores anómalos y antigüedad del handshake WireGuard. Los cambios de dirección son eventos puntuales.

Las señales tienen significados distintos. La falta de espacio puede impedir escribir, la CPU alta puede ser una compilación prevista y un handshake antiguo puede corresponder a un peer inactivo. Superar un umbral no prueba por sí solo una caída del servicio de negocio.

Un aviso debe identificar máquina, objeto y condición. El diagnóstico depende del uso del equipo. Fleetd ofrece comprobaciones concretas, no diagnóstico automático ni reinicios de servicios por CPU alta.

Distinguir picos y carga sostenida

CPU y memoria tienen un umbral predeterminado del 90% y una ventana de cinco minutos:

alerts:
  offline: 40s
  cpu_percent: 90
  mem_percent: 90
  sustain: 5m
  disk_percent: 90
  inode_percent: 90
  wg_handshake: 5m

Son valores de v0.3.0, no recomendaciones universales. Se configuran para todo el servidor; no hay umbrales independientes por máquina en esta configuración.

Como ejemplo conceptual, una tarea puede alcanzar el 98% y terminar enseguida, mientras otro equipo permanece saturado. No son incidentes medidos. La ventana filtra el primer caso y señala el segundo para investigar colas, procesos o trabajo previsto.

Fleetd toma el mínimo de las muestras recientes de CPU y memoria. Si el mínimo supera el umbral, todas las muestras recibidas lo superan. No utiliza el promedio ni cuenta excesos aislados. Un valor exactamente igual al 90% no supera el 90%.

También exige que la muestra más antigua cubra suficiente tiempo, con treinta segundos de tolerancia. No significa esperar exactamente cinco minutos completos. Tampoco exige un número mínimo de muestras ni verifica todos los huecos entre ellas. Evalúa las muestras disponibles con margen de cobertura, no una observación continua demostrada.

La memoria se calcula como total menos MemAvailable, dividido por el total. No considera automáticamente toda la caché Linux como memoria inutilizable, ni diagnostica una fuga de la aplicación.

Sin conexión significa que faltan informes

El cliente suele informar cada diez segundos y el servidor evalúa cada cinco. Con el valor predeterminado, unos cuarenta segundos sin informes permiten abrir la alerta en una evaluación posterior. Se usa la hora de recepción del servidor, no directamente el reloj del cliente.

Puede deberse al cliente detenido, corte eléctrico, router desconectado, DNS o ruta inaccesible. La alerta no distingue esas causas. Se toleran varias muestras perdidas; planificación, base de datos y correo añaden tiempo, así que no hay garantía de entrega exactamente a los cuarenta segundos.

Un equipo aprobado que nunca informó no se considera una caída. Después de arrancar el servidor, las nuevas alertas de desconexión esperan offline + 15s: unos cincuenta y cinco segundos por defecto para permitir reconexiones.

Por eso hay que confirmar el primer informe al dar de alta un equipo. Y si el propio servidor Fleetd deja de funcionar, no puede evaluar ni enviar correo: necesita una comprobación externa independiente.

Perder contacto no debe resolver otros fallos

Imagina una alerta de disco seguida de una desconexión. No hay información nueva del disco. Cerrarla porque esta ronda no vio el exceso produciría una recuperación engañosa.

Fleetd conserva las alertas activas de equipos desconectados. No abre ni resuelve otros estados usando datos obsoletos y añade la desconexión cuando corresponde, respetando la gracia inicial.

Cuando vuelven los informes, se reanuda la evaluación. Puede cerrarse la desconexión y seguir abierto el problema de espacio. Recuperar comunicación no libera disco.

Los recolectores lentos tienen otro ritmo

Discos, servicios, contenedores y WireGuard se recogen normalmente cada seis rondas, alrededor de un minuto. Evaluar cada cinco segundos no crea información nueva cada cinco segundos.

Comprobación	Condición actual
Espacio	Porcentaje del montaje superior al umbral
Inodes	Porcentaje utilizado superior al umbral
Servicios	Unidad systemd fallida informada
Contenedores	Reiniciando, unhealthy o salida no cero
WireGuard	Peer con handshake previo que supera la antigüedad permitida

Discos e inodes no usan la ventana sostenida de CPU; se evalúa el último informe lento guardado. Los inodes importan porque puede quedar espacio en bytes sin capacidad para crear más archivos.

Los contenedores que terminan con código 0 se ignoran: finalizar una tarea puntual no es necesariamente un fallo. Se detectan salidas no cero, unhealthy y el estado restarting. No se cuentan reinicios por minuto, y running tampoco prueba que la aplicación responda correctamente.

WireGuard omite peers que nunca hicieron handshake. Compara la hora del informe del cliente con la del handshake, evitando mezclar el reloj del servidor. Un handshake antiguo es un indicio, no una prueba completa de conectividad. Hay que entender tráfico y keepalive antes de usar la regla para peers intermitentes. wg_handshake: 0 la desactiva globalmente; no hay exclusiones por peer aquí.

Resolver significa que la regla ya no coincide

Cada evaluación construye el conjunto esperado y lo compara con registros abiertos. Los nuevos se abren, los ausentes se resuelven y los persistentes se conservan. Se distingue máquina y objeto: montajes o contenedores distintos tienen registros propios.

En un equipo conectado, una sola muestra de CPU o memoria igual o inferior al umbral rompe la condición de que todas lo superen. No hay umbral inferior separado de recuperación ni exigencia de estabilidad durante otros dos minutos. La espera para abrir no implica la misma espera para cerrar.

Un informe básico sin nuevos datos lentos conserva los anteriores. Pero un nuevo informe lento con una lista vacía por herramienta ausente o fallida puede hacer desaparecer la alerta del objeto. Por ejemplo, una unidad antes fallida deja de aparecer porque falló la propia consulta.

La implementación no distingue exhaustivamente comprobación correcta y saludable de comprobación no disponible. Un registro resuelto no demuestra por sí solo recuperación del negocio. Como vimos antes, la recogida de servicios fallidos usa systemd, no una comprobación completa de procd en OpenWrt.

Quitar duplicados no garantiza entrega

Fleetd no crea ni notifica de nuevo cada cinco segundos la misma alerta persistente. Cuando desaparece la condición, genera un cambio de resolución. Los cambios de una evaluación se reúnen en un correo.

No existe una ventana adicional de varios minutos ni recordatorios periódicos para fallos abiertos. Los eventos puntuales, como cambiar de dirección, siguen otra vía y no se agregan necesariamente con esa evaluación.

El estado se escribe antes del envío asíncrono. Si falla el correo, se registra el error; no hay cola persistente ni reintento automático. Un registro en la consola no acredita recepción. La siguiente evaluación tampoco reenvía automáticamente una notificación de apertura fallida si el problema sigue abierto.

La deduplicación reduce ruido, pero no sustituye entrega fiable, recordatorios, confirmación de lectura o escalado.

El correo es una salida, no el único registro

SMTP envía a los destinatarios configurados. Sin host o destinatarios, las notificaciones se registran en el log y los estados siguen en la consola. language: zh selecciona chino para avisos y correos del servidor; el idioma web se elige aparte en el navegador.

Se conservan siete días de métricas y noventa de alertas resueltas, con limpieza periódica. Puede quedar una alerta histórica sin sus curvas detalladas. Una investigación de mayor alcance necesita planificar retención.

Cambiar una dirección de conexión existente genera un evento puntual, no un fallo que espere la vuelta de la IP anterior. Puede ser simplemente otro punto de salida a la red.

Validar toda la cadena de notificación

Antes de ajustar valores, conviene entender apertura, registro, aviso y resolución. Estos son escenarios de aceptación sugeridos, no fallos provocados en producción.

Escenario	Qué observar
Pico breve de CPU	Una muestra alta no basta para una alerta sostenida
Muestras altas sostenidas de prueba	Una apertura al cumplir cobertura, sin aperturas repetidas
Se detienen informes durante un fallo	Conservar el fallo y añadir desconexión cuando corresponda
Vuelven informes con el mismo fallo	Resolver desconexión, conservar el fallo original
SMTP inaccesible	Registro y error de envío; no suponer reintentos
Recolector inaccesible	Comprobar el efecto de datos ausentes sobre la resolución

Se pueden usar datos controlados en un entorno aislado para validar umbrales y ventanas. No hace falta llenar la raíz de producción ni cortar el router que sostiene el acceso remoto.

Las pruebas existentes cubren parte de las reglas lentas: discos, salidas normales y anómalas de contenedores y handshake WireGuard. Una prueba integral también verifica un informe que crea una alerta de disco. No acreditan cobertura completa de transiciones y entrega de correo.

Fleetd busca avisos explicables para una flota pequeña: qué los activó, por qué no se repiten, cuándo se cierran y dónde puede fallar el envío. Disponibilidad de recolectores, frescura de datos, correo fiable y reglas por máquina son mejoras concretas. La próxima entrega tratará verificación de actualizaciones firmadas, versiones y límites de recuperación.