Monitor de Salud de Servicios
Enterarme yo antes que el cliente.
El problema
El servidor de producción empezó a fallar y a caerse sin aviso: no sabíamos cuándo pasaba porque no nos llegaba ninguna notificación. Nos enterábamos por los clientes, que empezaron a llamarnos constantemente por las caídas. Estar siempre un paso atrás, apagando incendios que ya habían escalado, era insostenible.
La solución
Lo primero era dejar de enterarme por el cliente: puse un monitor que chequea cada servicio por su cuenta y me avisa al instante por Telegram apenas algo cambia de estado. Pero enseguida apareció el problema real: muchas caídas eran blips de segundos, y si alertaba por cada una el canal se volvía puro ruido y dejaba de mirarlo. Así que antes de gritar agregué un re-chequeo: si la caída no se sostiene, la ignora. Y lo dejé extensible —consola, Telegram, email, webhook— detrás de una interfaz de un método, para sumar un canal sin tocar el monitor. La idea de fondo: que avise de lo real, rápido, y en el canal donde sí lo voy a ver.
Decisiones técnicas
Una goroutine por servicio
Cada servicio se chequea en su propio goroutine, con su ticker e intervalo; uno lento o caído nunca frena al resto del monitoreo.
Alertar solo en cambio de estado
Nada de ruido mientras está sano; avisa cuando cae y cuando se recupera, no en cada chequeo.
Flap-filter antes de alertar
Re-chequea N veces antes de gritar; un blip de segundos no despierta a nadie a las 3am.
Notifiers detrás de una interfaz de un método
Agregar Telegram, email o webhook nunca toca el monitor: cada canal es un archivo aparte.
En vivo
El monitor en acción: arranque, caída forzada y recuperación, con sus alertas a Telegram.