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
| Qué | Ejemplo | Por qué |
|---|---|---|
| Disponibilidad | La página de inicio de la historia clínica responde 200 | Es lo que ve el usuario |
| Latencia | Tiempo de respuesta de la consulta de paciente | En planta, lenta es igual que caída |
| Capacidad | Disco de logs y de base de datos, CPU, memoria, sesiones | Avisa con días de margen |
| Certificados | Días hasta la caducidad del certificado del servicio | Caducan de madrugada y en fin de semana |
| Copias de seguridad | Último trabajo correcto de cada base de datos | Una copia fallida no se nota hasta que hace falta |
| Integraciones | Mensajes en cola hacia laboratorio y farmacia | La aplicación funciona pero los resultados no llegan |
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:
- Qué significa la alarma y qué ve el usuario.
- Las comprobaciones en orden, con los comandos.
- Qué se puede hacer sin permiso (reiniciar el servicio X) y qué no (tocar la base de datos).
- 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.
- Reconocer el aviso en menos de cinco minutos. Así no escala al siguiente de la lista y queda constancia de quién lo tiene.
- Confirmar el impacto: abrir la aplicación como lo haría la planta, o llamar a urgencias.
- Seguir el runbook:
Test-NetConnection srv-hce-app01 -Port 443 | Select-Object ComputerName, TcpTestSucceededComputerName TcpTestSucceeded------------ ----------------srv-hce-app01 TrueGet-Service -ComputerName srv-hce-app01 -Name HCE* | Select-Object Name, StatusName Status---- ------HCEAppPool RunningHCEIntegra StoppedEl servidor responde y el servicio de integración está parado. El runbook permite arrancarlo una vez; si vuelve a pararse, se escala al proveedor.
- Arrancar, comprobar que la prueba sintética vuelve a verde y que los mensajes en cola hacia laboratorio se procesan.
- 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.
¿Falta algo o en tu entorno es distinto? Escríbeme y lo corrijo.
What you'll get
The health record, the laboratory or the A&E system alerting IT before the ward phones, and the on-call technician knowing at 03:40 what to do with the page without guessing. Useful monitoring isn't the one with the most alarms: it's the one that wakes someone only when needed and tells them where to start. The tool doesn't matter (SolarWinds, Grafana or another); the examples use both.
Before you start
- The inventory of critical services and their owner: which applications, and which servers, databases and integrations they depend on.
- The hours of cover: which services are 24x7 and which can wait for the morning shift.
- The on-call rota and the paging channel (call, SMS, on-call app). An email at night wakes nobody.
- Access to the monitoring tool with rights to create rules, silences and contacts.
1. What to watch
| What | Example | Why |
|---|---|---|
| Availability | The health record home page returns 200 | It's what the user sees |
| Latency | Response time of the patient lookup | On a ward, slow is as bad as down |
| Capacity | Log and database disks, CPU, memory, sessions | Warns days in advance |
| Certificates | Days until the service certificate expires | They expire at night and at weekends |
| Backups | Last successful job for each database | A failed backup goes unnoticed until you need it |
| Integrations | Messages queued to laboratory and pharmacy | The app works but results don't arrive |
Start with the service's synthetic check (what a user does) and add the components underneath. That way you know whether there's impact before you look at why.
2. Thresholds, severity and who gets paged
- Severity 1: the service is unavailable or there's clinical impact. Call the on-call engineer at any hour.
- Severity 2: degraded or at risk of failing within hours (disk at 90%, high latency). Notify on-call, no call out of hours.
- Severity 3: to be looked at in hours (certificate at 30 days, a failed backup with a good one after it). Ticket in the team queue.
Each threshold has a pending period: high latency for one minute isn't an alarm; for ten, it is.
The severity and team labels are what the notification policy uses to choose the contact point: severity 1 goes to the on-call app, severity 3 to the team channel.
3. A runbook in every alarm
An alarm without instructions is a question at three in the morning. Each rule links to its runbook with:
- What the alarm means and what the user sees.
- The checks in order, with the commands.
- What can be done without permission (restart service X) and what can't (touch the database).
- Who to escalate to and when: vendor, database administrator, on-call manager.
4. Maintenance windows
- Before an approved change, silence only the affected components and only for the window: in Grafana, a silence by labels with an end time; in SolarWinds, the node's maintenance mode with a scheduled Mute Alerts.
- Silencing isn't switching off: on-call still sees the state on the dashboard.
- When the window ends, check the silence has expired and the synthetic check is green.
A silence with no end time ends up hiding a real outage weeks later.
5. The ticket: "night-time alarm on the health record"
Sunday, 03:40. The on-call app calls javier.ruiz: Sev 1 · HCE · synthetic check failing for 5 min.
- Acknowledge the page within five minutes. That stops it escalating to the next person and records who owns it.
- Confirm the impact: open the application as the ward would, or phone A&E.
- Follow the runbook:
Test-NetConnection srv-hce-app01 -Port 443 | Select-Object ComputerName, TcpTestSucceededComputerName TcpTestSucceeded------------ ----------------srv-hce-app01 TrueGet-Service -ComputerName srv-hce-app01 -Name HCE* | Select-Object Name, StatusName Status---- ------HCEAppPool RunningHCEIntegra StoppedThe server responds and the integration service is stopped. The runbook allows starting it once; if it stops again, escalate to the vendor.
- Start it, check the synthetic check goes back to green and the messages queued for the laboratory are processed.
- Close with a record: time of the page, acknowledgement and recovery, apparent cause and whether a problem record is needed for the morning shift.
6. The noise review
Each month, with the tool's alarm report:
- Alarms nobody acted on or that closed by themselves: a badly set threshold or a useless alarm. Adjust or remove it.
- Those that fired more than ten times: an underlying problem that needs a change, not more alerts.
- Outages that didn't raise an alarm: a check is missing.
- Night-time calls that could have waited: lower their severity.
Next steps
- The Level 3 SolarWinds guide explains nodes, alerts and maintenance mode.
- The Level 3 Grafana guide covers data sources, dashboards and alert rules.
- The Azure Monitor y Log Analytics guide helps if part of the platform runs in Azure.
Is something missing, or different in your environment? Get in touch and I'll fix it.
Tech Career Lab · newsletter
¿Te ha servido? Cada dos semanas envío una idea práctica para perfiles IT: LinkedIn, proyectos, networking y procesos de selección.Found this useful? Every two weeks I send one practical idea for IT professionals: LinkedIn, projects, networking and hiring processes.
Apúntate y llévate las 33 ideasSign up and get the 33 ideas →