Monitorización: desplegar alarmas y responder a ellas en una plataforma 24x7

Qué vas a conseguir

Que la historia clínica, el laboratorio o la central de urgencias avisen a IT antes de que llame la planta, y que el técnico de guardia sepa a las 3:40 qué hacer con el aviso sin tener que adivinarlo. Una monitorización útil no es la que más alarmas tiene: es la que despierta a alguien solo cuando hace falta y le dice por dónde empezar. La herramienta da igual (SolarWinds, Grafana u otra); los ejemplos usan las dos.

Antes de empezar

• El inventario de servicios críticos y su responsable: qué aplicaciones, de qué servidores, bases de datos e integraciones dependen.
• El horario de cobertura: qué servicios son 24x7 y cuáles pueden esperar al turno de mañana.
• El calendario de guardias y el canal de aviso (llamada, SMS, aplicación de guardias). Un correo de madrugada no despierta a nadie.
• Acceso a la herramienta de monitorización con permisos para crear reglas, silencios y contactos.

1. Qué vigilar

Empieza por la prueba sintética del servicio (lo que hace un usuario) y añade debajo los componentes. Así sabes si hay impacto antes de mirar por qué.

2. Umbrales, severidad y a quién avisa

• Severidad 1: el servicio no está disponible o hay impacto clínico. Llamada a la guardia a cualquier hora.
• Severidad 2: degradado o con riesgo de caída en horas (disco al 90 %, latencia alta). Aviso a la guardia, sin llamada fuera de horario.
• Severidad 3: hay que verlo en horario (certificado a 30 días, una copia fallida con otra correcta después). Ticket en la cola del equipo.

Cada umbral lleva un periodo de espera: una latencia alta durante un minuto no es una alarma; durante diez, sí.

Las etiquetas severity y equipo son las que usa la política de notificaciones para decidir el punto de contacto: la severidad 1 va a la aplicación de guardias, la 3 al canal del equipo.

3. Un runbook en cada alarma

Una alarma sin instrucciones es una pregunta a las tres de la mañana. Cada regla enlaza su runbook con:

1. Qué significa la alarma y qué ve el usuario.
2. Las comprobaciones en orden, con los comandos.
3. Qué se puede hacer sin permiso (reiniciar el servicio X) y qué no (tocar la base de datos).
4. A quién se escala y cuándo: proveedor, administrador de base de datos, responsable de guardia.

4. Ventanas de mantenimiento

• Antes de un cambio aprobado se silencian solo los componentes afectados y solo durante la ventana: en Grafana, un silencio por etiquetas con hora de fin; en SolarWinds, el modo mantenimiento del nodo con Mute Alerts programado.
• Silenciar no es apagar: la guardia sigue viendo el estado en el panel.
• Al terminar la ventana se comprueba que el silencio ha caducado y que la prueba sintética está en verde.

Un silencio sin hora de fin acaba ocultando una caída real semanas después.

5. El ticket: "alarma de madrugada en la historia clínica"

Domingo, 03:40. La aplicación de guardias llama a javier.ruiz: Sev 1 · HCE · prueba sintética fallando desde hace 5 min.

1. Reconocer el aviso en menos de cinco minutos. Así no escala al siguiente de la lista y queda constancia de quién lo tiene.
2. Confirmar el impacto: abrir la aplicación como lo haría la planta, o llamar a urgencias.
3. Seguir el runbook:

›Test-NetConnection srv-hce-app01 -Port 443 | Select-Object ComputerName, TcpTestSucceededComputerName   TcpTestSucceeded------------   ----------------srv-hce-app01  True›Get-Service -ComputerName srv-hce-app01 -Name HCE* | Select-Object Name, StatusName         Status----         ------HCEAppPool   RunningHCEIntegra   Stopped

El servidor responde y el servicio de integración está parado. El runbook permite arrancarlo una vez; si vuelve a pararse, se escala al proveedor.

1. Arrancar, comprobar que la prueba sintética vuelve a verde y que los mensajes en cola hacia laboratorio se procesan.
2. Cerrar con un registro: hora del aviso, del reconocimiento y de la recuperación, causa aparente y si hace falta un problema para el turno de mañana.

6. La revisión del ruido

Cada mes, con el informe de alarmas de la herramienta:

• Las alarmas que nadie atendió o que se cerraron solas: umbral mal puesto o alarma inútil. Se ajusta o se elimina.
• Las que sonaron más de diez veces: un problema de fondo que pide un cambio, no más avisos.
• Las caídas que no dieron alarma: falta una comprobación.
• Las llamadas de madrugada que podían esperar: bajan de severidad.

Siguientes pasos

• La guía de SolarWinds del Nivel 3 explica nodos, alertas y modo mantenimiento.
• La guía de Grafana del Nivel 3 cubre fuentes de datos, paneles y reglas de alerta.
• La guía de Azure Monitor y Log Analytics sirve si parte de la plataforma está en Azure.

¿Quieres practicarlo? Resuelve el ticket «Ha fallado la fuente de un switch, pero nadie lo ha notado» en SysAdmin Desks, gratis y en el navegador.

¿Falta algo o en tu entorno es distinto? Escríbeme y lo corrijo.