Monitoreo de servidores: métricas clave para reducir MTTR (y qué alertas sí importan)

hace 3 días
5 Min. de lectura

Si tu monitoreo “suena bonito” pero en incidentes sigues tardando horas en estabilizar, el problema casi nunca es falta de datos: es falta de señales accionables. El objetivo real del monitoreo no es llenar dashboards; es acortar el tiempo total del incidente (MTTR) y evitar que se repita.

MTTR (Mean Time to Repair/Recovery) se usa para medir el tiempo promedio que toma restaurar un sistema después de una falla. Y aunque el MTTR se siente como “tiempo de reparación”, en la práctica también depende de qué tan rápido detectas, reconoces y priorizas el problema (MTTD/MTTA), algo que en soporte de servidores suele ser decisivo.

En el blog de TBSMEX ya se enfatiza esta idea: monitoreo + runbooks + escalamiento + métricas es lo que vuelve “real” un SLA y baja MTTR. En este artículo vamos a lo práctico: qué medir, qué alertar y cómo alertar para que el monitoreo sí reduzca MTTR.

Por qué “más alertas” suele aumentar tu MTTR

El error clásico es convertir el monitoreo en una fábrica de notificaciones: CPU alta, RAM alta, disco alto, “ping cayó”… y todo llega igual, al mismo canal, con la misma urgencia.

Google SRE lo resume de forma útil: alertar menos y alertar en síntomas suele ser mejor que alertar en “posibles causas”. Y guías de buenas prácticas (por ejemplo, Grafana Alerting) insisten en lo mismo: el problema real es operativo—sistemas complejos, señales imperfectas y humanos de guardia.

Regla que funciona en producción:

Si una alerta no define acción, dueño y urgencia… es ruido.

Las 4 señales “oro” (Golden Signals) aplicadas a servidores

Cuando no sabes por dónde empezar, Google propone enfocarte en 4 señales: latencia, tráfico, errores y saturación. Aunque nacen en sistemas distribuidos, se adaptan perfecto a infraestructura y servidores:

1) Latencia (lo que tarda en responder)

Latencia de aplicaciones (p95/p99 si aplica)
Latencia de disco/almacenamiento (lectura/escritura)
Latencia de red (RTT), DNS, handshake TLS

Por qué baja MTTR: la latencia es síntoma temprano: te avisa antes que el “down”.

2) Tráfico (la demanda real)

Requests/s (si hay app), conexiones, sesiones
Throughput de red (bps), PPS
IOPS y throughput de storage

Por qué baja MTTR: te permite responder con contexto: “¿es carga normal o anomalía?”

3) Errores (fallas visibles)

5xx/errores de app, timeouts
Errores de disco/RAID, NIC errors, retransmisiones
Fallos de backups, fallos de jobs críticos

Por qué baja MTTR: los errores suelen ser síntomas directamente accionables (no “posibles causas”).

4) Saturación (cuello de botella)

CPU (pero con contexto: steal, load average, run queue)
Memoria (incluye swapping / presión)
Disco (queue, iowait, espacio, inodes)
Red (drops, buffer, congestión)

Por qué baja MTTR: te dice dónde se está ahogando el sistema, no solo que “está lento”.

Métricas por capa: qué medir para que el diagnóstico sea rápido

La forma más efectiva de reducir MTTR es que el monitoreo te permita contestar en minutos:

¿Qué se cayó (síntoma)?
¿Qué lo está causando (capa probable)?
¿Qué acción mitiga ya (runbook)?

Capa hardware (la base: si falla, todo se complica)

Estado de PSU, ventiladores, temperatura
Eventos del BMC (iDRAC/iLO), salud del servidor
Estado de RAID/controladora y discos (predictive fail)

En la guía de refacciones de TBSMEX se mencionan ejemplos reales de señales típicas en iDRAC/iLO (p. ej., eventos de fuente “power good lost”), justo el tipo de telemetría que conviene llevar a alertas accionables.

Capa sistema operativo

CPU: uso + load + steal time (virtualización) + saturación real
Memoria: available, page faults, swapping, OOM kills
Disco: iowait, latencia, cola, espacio, inodes
Procesos/servicios críticos: systemd services, Windows services

Capa virtualización

Salud del host (VMware/Hyper-V/KVM), datastore latency
Contención (CPU ready/steal), memoria ballooning
Red virtual (drops, errores, saturación)

Capa red

Errores en interfaz (CRC, drops), retransmisiones
Latencia/packet loss hacia dependencias (DB, DNS, storage, gateways)
Saturación de uplinks y colas

Capa respaldo y recuperación (sí, esto también es monitoreo)

Último backup exitoso / tiempo desde último éxito
Éxito de verificación (si existe) y pruebas de restore (si están programadas)
Replicación/lag (si hay DR)

Si tu recuperación falla en el momento crítico, tu MTTR explota (y tu RTO también).

Qué alertas sí importan (y cuáles casi siempre sobran)

A. Alertas que deben “picar” (paging) porque impactan servicio

Estas deberían ser pocas y estar ligadas a síntoma/impacto:

Servicio no disponible (healthcheck real, no solo ping)
Errores altos / timeouts sostenidos en servicios críticos
Latencia alta sostenida que rompe experiencia/operación
Disco en riesgo (espacio crítico o crecimiento acelerado)
RAID degradado / disco con falla inminente
PSU/fan/temperatura fuera de rango con riesgo de apagado/daño
Backup crítico fallando (según criticidad, puede ser paging)

B. Alertas para ticket (no despiertan a nadie, pero se atienden)

Capacidad: tendencia de crecimiento (espacio, IOPS, CPU)
Certificados por expirar (si aplica)
Parches pendientes críticos (según política)
Reinicios inesperados “no críticos” (si hay redundancia)

C. Señales solo informativas (dashboard)

CPU alta momentánea sin impacto
Memoria alta si no hay swapping/pressure y la app la usa como cache
“Ping intermitente” sin correlación con experiencia del usuario

Clave SRE: empezar por lo que ve el usuario/servicio (síntoma) y luego enriquecer con causas como contexto.

Cómo diseñar alertas para bajar MTTR (no para “verse pro”)

1) Diseña por severidad y acción (no por métrica)

Antes de elegir umbral, define:

Acción (qué harás al disparo)
Dueño (quién responde)
Tiempo (cuándo es urgente vs cuándo puede esperar)

En TBS iT se habla de bajar MTTR con operación 24/7, escalamiento y “monitoreo que alimenta ITSM”, justo porque la alerta debe convertirse en flujo de acción.

2) Alertar por “ventanas” (duración) reduce falsos positivos

Umbrales instantáneos generan ruido. En general, conviene alertar si una condición se mantiene X minutos (dependiendo del servicio).

3) Correlación simple: una alerta raíz, no 40 derivadas

Ejemplo:

Si un datastore se degrada, no pagues 30 alertas de VMs “lentas”
Página por la condición raíz (storage/latencia) y agrega contexto

4) Convierte objetivos (SLO/SLA) en alertas cuando puedas

El workbook de Google SRE propone convertir SLOs en alertas accionables y gestionar el balance entre precisión, recall y tiempo de detección.

Checklist rápido: implementación en 7 pasos

Inventario y criticidad: define qué servidores/servicios son “core”.
Define síntomas: qué significa “degradado” vs “caído”.
Elige señales oro + capa: golden signals + hardware/OS/red/storage.
Triage y runbooks: 5 runbooks para los 5 incidentes más comunes.
Ruteo: paging vs ticket vs info (y canales distintos).
Integración con tickets: alertas críticas abren incidentes (si aplica a tu operación).
Revisión mensual: mata alertas ruidosas, ajusta umbrales, aprende del postmortem.

Cómo esto conecta con tus SLAs y tu soporte (y por qué importa)

Cuando el monitoreo es accionable, habilita lo que en un SLA sí pesa: detectar rápido, escalar rápido y resolver con contexto. En el contenido de TBS iT se recalca que el MTTR mejora cuando el soporte tiene métricas, runbooks y un proceso de atención continuo.

Además, hay un factor “físico” que muchos pasan por alto: si el incidente es hardware, el MTTR depende también de disponibilidad de refacciones y logística. TBS iT describe inventario nacional, envíos express y soporte 24/7 para refaccionamiento (incluyendo instalación/firmware), lo cual impacta directamente el tiempo de recuperación cuando el fallo es de componentes.

Cierre: menos ruido, más restauración

Si quieres bajar MTTR, no necesitas 300 métricas: necesitas 20–30 señales bien elegidas, alertas por severidad y runbooks probados. En resumen:

Mide lo que impacta (golden signals + capas críticas).
Alerta por síntomas (y usa causas como contexto).
Conecta alertas con acción (tickets, escalamiento, runbooks).

Si hoy tu monitoreo está generando ruido (o llegas tarde a los incidentes), una forma práctica de acelerar resultados es combinar monitoreo proactivo + mantenimiento preventivo + cobertura 24/7 como parte de un esquema de soporte; eso es justo lo que TBS iT describe dentro de sus pólizas/servicios administrados y su operación 24/7 con gestión de tickets.

FAQs

¿MTTR es lo mismo que “tiempo de reparación”?

Es el tiempo promedio para volver a estar operativo tras una falla; suele incluir desde el fallo hasta la restauración completa.

¿Por qué no basta con alertas de CPU/RAM?

Porque son causas potenciales, no impacto. Alertar por síntomas (errores, latencia, indisponibilidad) suele reducir ruido y acelerar diagnóstico.

¿Cuál es el error #1 en alertamiento?

No definir severidad/acción y mandar todo igual. Las buenas prácticas recomiendan diseñar alertamiento que escale en operación real.