Un servidor no suele caerse de golpe. Primero se llena un disco, luego la memoria empieza a intercambiarse contra el disco, después las consultas tardan el doble y, al final, un martes a las diez de la mañana, la aplicación deja de responder y nadie sabe desde cuándo venía avisando. El monitoreo de servidores es lo que convierte esa cadena de señales en un aviso a tiempo, en lugar de en una llamada del gerente.
Este artículo es material de consulta y sirve en dos niveles. Si usted no es de sistemas pero le toca decidir sobre esto, empiece por el principio: verá qué se vigila, qué significa cada número y qué preguntar a su proveedor. Si ya administra infraestructura, salte a las tablas: encontrará las métricas por capa con sus umbrales, cómo funciona SNMP por dentro, la comparación de herramientas y el cálculo real de lo que cuesta un porcentaje de disponibilidad.
Qué es el monitoreo de servidores
El monitoreo de servidores consiste en recoger, de forma continua y automática, el estado de una máquina y de los servicios que corre, guardar esa medición en el tiempo y avisar a alguien cuando un valor se sale de lo esperado. Son tres cosas distintas y las tres hacen falta: medir, guardar y avisar.
Medir sin guardar sirve para mirar el momento actual, pero no permite responder a la pregunta que de verdad importa cuando algo falla: «¿esto es normal?». Guardar sin avisar produce paneles bonitos que nadie mira. Y avisar sin haber medido bien produce lo peor de todo, que es un equipo que ya no lee las alertas.
Conviene distinguirlo de dos cosas parecidas. La supervisión de un servidor no es lo mismo que su administración: monitorear dice que el disco está al 92 %, administrar es quien lo amplía. Y tampoco es lo mismo que el registro de seguridad: un sistema de monitoreo técnico vigila salud y rendimiento, no analiza indicadores de ataque, que es otra disciplina con otras herramientas.
Monitoreo de servidores: los cuatro planos que hay que vigilar
Casi todo el monitoreo de servidores cae en uno de estos cuatro planos. Además, separarlos ayuda a no dejar huecos y, sobre todo, a no vigilar diez veces lo mismo.
| Plano | Qué responde | Ejemplo de medición |
|---|---|---|
| Disponibilidad | ¿Está vivo? | El servidor responde a ping y el puerto 443 acepta conexiones |
| Rendimiento | ¿Va rápido? | La página responde en 300 ms; la consulta tarda 40 ms |
| Capacidad | ¿Cuánto aguanta? | Queda el 18 % del disco y crece un 2 % semanal |
| Corrección | ¿Hace lo que debe? | El respaldo de anoche terminó sin errores y pesa lo esperado |
El cuarto plano es el que más se olvida y el que más caro sale. Un servidor puede estar encendido, rápido y con disco de sobra mientras su tarea de respaldo lleva tres semanas fallando en silencio. Ese caso concreto lo tratamos aparte en el artículo sobre qué falla en las copias de seguridad.
Métricas de monitoreo de servidores, capa por capa
Esta es la tabla de referencia del monitoreo de servidores. Ahora bien, los umbrales son puntos de partida razonables para un servidor de empresa, no verdades universales: por ejemplo, una base de datos con el 95 % de memoria usada puede estar perfectamente sana, porque así es como funciona su caché.
| Capa | Métrica | Umbral orientativo | Qué suele significar |
|---|---|---|---|
| Sistema | Carga media (load average) | > número de núcleos | Hay procesos esperando turno de CPU |
| Uso de CPU sostenido | > 85 % durante 15 min | Falta capacidad o hay un proceso desbocado | |
| Memoria disponible | < 10 % | Riesgo de intercambio a disco y de que el sistema mate procesos | |
| Espacio en disco | < 15 % libre | Registros sin rotar, respaldos acumulados o crecimiento real | |
| Disco | Latencia de escritura | > 20 ms en disco de estado sólido | Cabina saturada o disco degradado |
| Cola de peticiones | > 2 por disco | El almacenamiento es el cuello de botella | |
| Inodos libres | < 10 % | Millones de ficheros pequeños; el disco parece libre y no lo está | |
| Red | Uso del enlace | > 70 % sostenido | Enlace corto para el tráfico real |
| Errores y descartes | > 0 creciendo | Cable, óptica o negociación de velocidad en mal estado | |
| Latencia entre sedes | > 100 ms o con saltos | Problema del operador o saturación | |
| Servicio | Tiempo de respuesta | Según lo acordado | La medida que de verdad siente el usuario |
| Tasa de errores | > 1 % de las peticiones | Fallo de aplicación o dependencia caída | |
| Certificado TLS | < 21 días para vencer | Caída anunciada con fecha y hora | |
| Base de datos | Conexiones activas | > 80 % del máximo | Fugas de conexión o pico real |
| Consultas lentas | Creciendo | Falta un índice o cambió el volumen de datos |
Dos trampas de estas métricas
La primera: el uso de CPU aislado engaña, porque un pico del 100 % durante treinta segundos es normal, mientras que uno del 60 % sostenido durante ocho horas puede no serlo. Es decir, lo que importa es la duración, no el instante.
La segunda: los inodos agotados son la causa favorita de los incidentes que empiezan con «pero si el disco tiene sitio». Se comprueban con df -i, no con df -h. Por eso conviene que el monitoreo de servidores vigile las dos cosas por separado.
Las cuatro señales de oro
Si le abruma la tabla anterior, hay un atajo con nombre propio. El equipo de ingeniería de fiabilidad de Google propuso reducir el monitoreo de un servicio a cuatro señales, y la idea se ha vuelto estándar de facto porque funciona: si solo puede vigilar cuatro cosas, vigile estas.
| Señal | Qué mide | Cómo se ve en la práctica |
|---|---|---|
| Latencia | Cuánto tarda una petición | Separe la de las peticiones que fallan: un error rápido falsea la media |
| Tráfico | Cuánta demanda hay | Peticiones por segundo, sesiones activas, transacciones por minuto |
| Errores | Qué proporción falla | Códigos 5xx, excepciones, respuestas correctas con contenido inválido |
| Saturación | Cuán lleno está el recurso más escaso | El que primero se agota: memoria, disco de entrada y salida, o hilos |
Una precisión sobre la latencia que ahorra discusiones: no mire el promedio, mire los percentiles. Si mil usuarios cargan una página en 200 ms y diez tardan doce segundos, el promedio dirá 320 ms y parecerá que todo va bien. El percentil 95 dirá la verdad. La regla práctica es reportar siempre p50, p95 y p99, y prometer sobre el p95.
Cómo llega el dato hasta el panel
Hay tres formas de que una herramienta sepa qué le pasa a un servidor. Sin embargo, elegir la equivocada es el motivo más común de que un proyecto de monitoreo de servidores se atasque a mitad de camino.
| Método | Cómo funciona | A favor | En contra |
|---|---|---|---|
| Agente | Un programa pequeño instalado en el servidor envía las métricas | Mucho detalle: procesos, servicios, registros, ficheros | Hay que instalarlo, actualizarlo y abrirle un puerto o una salida |
| Sin agente por SNMP | El equipo publica contadores y la herramienta los consulta | Ya viene en switches, firewalls, impresoras y cabinas | Vocabulario limitado; casi nada de lógica de aplicación |
| Sin agente por API o sondeo | Se consulta un extremo del propio servicio | Mide lo que ve el usuario, sin tocar el servidor | Solo ve el resultado; no dice por qué falla |
La combinación que funciona en la mayoría de las empresas es sencilla: agente en los servidores propios, SNMP en el equipamiento de red y sondeo externo para los servicios que el cliente usa desde fuera. Ninguno de los tres sustituye a los otros dos.
SNMP, por dentro y sin misterio
SNMP es el protocolo con el que casi todo el equipamiento de red se deja preguntar. Lleva desde 1988 y sigue siendo el idioma común de switches, routers, impresoras y sistemas de alimentación. Funciona con una idea simple: cada equipo mantiene un árbol de valores numerados y usted pide el número que le interesa.
| Concepto | Qué es |
|---|---|
| OID | La dirección de un dato dentro del árbol, como 1.3.6.1.2.1.1.3.0, que es el tiempo encendido |
| MIB | El diccionario que traduce esos números a nombres legibles |
| GET / WALK | Pedir un valor concreto, o recorrer una rama entera |
| TRAP | Lo contrario: el equipo avisa por su cuenta cuando pasa algo |
| Comunidad | La contraseña en claro de las versiones 1 y 2c |
Consultar el tiempo que lleva encendido un switch y recorrer sus interfaces se hace así:
# Tiempo encendido del equipo
snmpget -v2c -c publico 192.168.1.1 1.3.6.1.2.1.1.3.0
# Nombre de todas las interfaces
snmpwalk -v2c -c publico 192.168.1.1 1.3.6.1.2.1.2.2.1.2
# Lo mismo, con SNMPv3 y cifrado
snmpwalk -v3 -l authPriv -u vigilante -a SHA -A "clave-auth" \
-x AES -X "clave-cifrado" 192.168.1.1 1.3.6.1.2.1.2.2.1.2Y aquí va la advertencia que importa. Las versiones 1 y 2c mandan la comunidad en texto claro por la red, y en la mayoría de los equipos viene de fábrica como public. Cualquiera que escuche el tráfico puede leerla y, con ella, obtener el mapa completo de su red. La versión 3 añade autenticación y cifrado. Si va a habilitar SNMP, habilítelo en v3, restrinja por dirección de origen y deje el acceso en solo lectura. Y si mantiene v2c por un equipo antiguo, al menos cambie la comunidad y limítela a la red de gestión. Esto conecta directamente con cómo esté segmentada su red de área local.
Umbrales, alertas y la fatiga que las mata
El problema del monitoreo maduro no es que falten alertas: es que sobran. Un equipo que recibe cuarenta correos al día deja de leerlos en dos semanas, y el día que llega el importante ya nadie mira. La regla que ordena esto es incómoda pero clara: si una alerta no exige que alguien haga algo ahora, no es una alerta.
| Nivel | Criterio | A dónde va |
|---|---|---|
| Crítico | Hay impacto en el usuario ahora mismo | Llamada o mensaje al responsable de turno |
| Alto | Habrá impacto en horas si nadie actúa | Ticket con prioridad y aviso al equipo |
| Informativo | Conviene saberlo, no urge | Panel y resumen diario; nunca correo individual |
Cuatro técnicas reducen el ruido sin perder cobertura:
- Histéresis. Que la alerta salte al 90 % pero se cierre al 80 %, para que un valor que oscila no genere veinte avisos.
- Duración mínima. Exigir que la condición se mantenga cinco o quince minutos antes de avisar.
- Dependencias. Si cae el switch, no envíe cuarenta alertas de los servidores que cuelgan de él: envíe una.
- Tendencia en vez de valor. Avisar de que el disco se llenará en cuatro días es más útil que avisar cuando ya está lleno.
La cuarta es la que cambia el carácter del trabajo. Con umbrales fijos usted corre detrás de los incidentes; con proyección de tendencia los previene, que es de lo que trata realmente la continuidad operativa.
Qué significa de verdad un porcentaje de disponibilidad
Cuando en un contrato aparece un porcentaje de disponibilidad, conviene traducirlo a minutos antes de firmar. La tabla es la misma para todo el sector y no depende de proveedor alguno.
| Disponibilidad | Caída máxima al mes | Caída máxima al año |
|---|---|---|
| 99 % | 7 h 18 min | 3 días 15 h |
| 99,5 % | 3 h 39 min | 1 día 19 h |
| 99,9 % | 43 min 50 s | 8 h 45 min |
| 99,95 % | 21 min 55 s | 4 h 22 min |
| 99,99 % | 4 min 23 s | 52 min 35 s |
Dos lecturas prácticas. La primera: cada nueve adicional multiplica el costo, porque exige redundancia real, no mejores intenciones. La segunda, y más importante: ese número no significa nada si no se mide desde donde está el usuario. Un servicio puede estar disponible al 99,99 % medido dentro del centro de datos y ser inservible para una sede cuyo enlace se cae dos veces por semana.
Herramientas de monitoreo de red y de servidores
El mercado de herramientas de monitoreo de red es amplio y, en el fondo, casi todas hacen lo mismo. Por lo tanto, la diferencia real está en cuánto trabajo de puesta en marcha piden y en qué tan bien escalan.
| Herramienta | Modelo | Encaja bien cuando | Cuesta trabajo si |
|---|---|---|---|
| Zabbix | Libre, con agente y SNMP | Quiere una sola pieza que vigile servidores y red, con plantillas listas | Espera que la interfaz sea moderna sin ajustes |
| Prometheus y Grafana | Libre, extrae métricas por HTTP | Tiene contenedores o servicios que ya publican métricas | Necesita vigilar equipos de red antiguos, que no hablan ese idioma |
| Nagios y sus derivados | Libre, comprobaciones por guion | Quiere comprobaciones a medida y control total | Busca gráficas y tendencias sin añadir componentes |
| Checkmk | Mixto | Quiere descubrimiento automático y poco mantenimiento | Su presupuesto es cero y el parque es grande |
| PRTG | Comercial, por sensores | Prefiere instalar y andar, sobre todo en entornos Windows | El número de sensores crece, porque el precio va con ellos |
| Uptime Kuma | Libre, sondeo externo | Solo necesita saber si sus sitios y servicios responden | Espera métricas internas del sistema operativo |
Un consejo que vale más que la elección: empiece por la herramienta que su equipo sepa mantener. De hecho, un Uptime Kuma bien atendido avisa de más incidentes reales que un Prometheus a medio configurar que nadie se atreve a tocar. En resumen, el mejor software de monitoreo de red es el que alguien de la casa entiende.
Monitoreo de servidores desde dentro y desde fuera
El monitoreo de servidores interno ve el detalle: procesos, discos, memoria, colas. El externo, en cambio, ve lo que ve el cliente: si la página abre y en cuánto tiempo. Es decir, cada uno detecta fallos que el otro no puede ver.
| Fallo | ¿Lo ve el interno? | ¿Lo ve el externo? |
|---|---|---|
| Disco lleno en el servidor | Sí, con antelación | Solo cuando ya rompió algo |
| Certificado vencido | Sí, si se vigila | Sí, de inmediato |
| Caída del enlace de la sede | No: el servidor está bien | Sí |
| Fallo del DNS o del proveedor de nube | Casi nunca | Sí |
| Proceso caído sin impacto visible aún | Sí | No |
Las cuartas filas son la razón por la que el monitoreo propio no se puede delegar entero en el proveedor de nube: cuando el que falla es él, su panel también falla. Lo tratamos con casos concretos en el artículo sobre las caídas de servicios en la nube.
Métricas, registros y trazas
Son tres tipos de dato distintos y, sin embargo, se mezclan con frecuencia. Hacerlo genera confusión y también facturas altas de almacenamiento.
| Tipo | Qué es | Para qué sirve | Cuánto ocupa |
|---|---|---|---|
| Métrica | Un número cada cierto tiempo | Ver tendencias y disparar alertas | Poco y predecible |
| Registro | Una línea de texto por suceso | Entender qué pasó exactamente | Mucho, y crece sin avisar |
| Traza | El recorrido de una petición entre servicios | Saber cuál de siete servicios va lento | Alto; se suele muestrear |
La regla práctica: alerte con métricas, diagnostique con registros. Poner una alerta sobre el texto de un registro parece cómodo el primer día y se vuelve inmanejable el mes siguiente, porque cualquier cambio de formato la rompe en silencio.
Cómo montar el monitoreo de servidores en cinco pasos
- Inventario primero. No se puede vigilar lo que no se sabe que existe. Liste servidores, servicios, enlaces y certificados con su responsable.
- Defina qué es «caído» para el negocio. No en términos técnicos: «los vendedores no pueden facturar» es un criterio; «el proceso httpd no responde» es un síntoma.
- Empiece por disponibilidad y capacidad. Ping, puertos, disco, memoria y certificados cubren la mayoría de los incidentes reales con muy poco esfuerzo.
- Ajuste durante dos semanas. Toda instalación nueva genera falsos positivos. Si no dedica ese tiempo, el equipo aprenderá a ignorar el sistema.
- Escriba quién responde y cuándo. Una alerta sin destinatario definido es una alerta que nadie atiende.
Por último, una comprobación rápida para saber si su monitoreo de servidores funciona: apague a propósito un servicio secundario un martes por la tarde. Si nadie se entera en quince minutos, entonces lo que tiene es un panel, no un sistema de monitoreo.
Cinco errores que se repiten
| Error | Qué provoca | Qué hacer |
|---|---|---|
| Vigilar todo desde el primer día | Miles de métricas y ninguna alerta útil | Empezar por lo que rompe el negocio |
| Alertas por correo a una lista | Nadie se siente responsable | Un destinatario nombrado por turno |
| Umbrales copiados de internet | Falsos positivos constantes | Medir dos semanas y ajustar sobre lo real |
| Monitorear solo el servidor | El servicio cae y el panel está verde | Añadir sondeo desde fuera |
| Dejar el sistema sin vigilancia propia | El monitoreo se cae y nadie lo nota | Un aviso externo que confirme que sigue vivo |
Preguntas frecuentes
¿Cada cuánto conviene tomar una medida?
Un minuto es el estándar razonable para casi todo. Bajar a diez segundos multiplica el almacenamiento y rara vez cambia una decisión. Subir a cinco minutos hace que un incidente corto pase desapercibido.
¿Cuánto histórico hay que guardar?
Con detalle fino, entre siete y treinta días. Después conviene consolidar a promedios por hora y conservar uno o dos años, que es lo que permite justificar una compra con datos de crecimiento en lugar de con impresiones.
¿Sirve el monitoreo de servidores si están en la nube?
Sirve igual, y hay un matiz importante. El proveedor le muestra el estado de su plataforma, no el de su aplicación. Que la máquina virtual esté encendida no dice nada sobre si su sistema responde. Y cuando el incidente es del proveedor, su panel es el que no funciona.
¿Monitorear consume recursos del servidor?
Un agente típico consume bastante menos del 1 % de CPU y unas decenas de megabytes de memoria. El consumo que sí importa está en el otro extremo: el servidor que recibe y guarda las métricas necesita disco rápido y crece con el número de equipos vigilados.
¿Y si la empresa es pequeña?
Con más razón. Una empresa de veinte personas no tiene a nadie mirando pantallas, así que depende por completo de que el aviso llegue solo. Vigilar cinco cosas bien elegidas cuesta muy poco y evita el tipo de caída que se descubre cuando llama un cliente.
Lo que hay que recordar
El monitoreo de servidores no consiste en tener paneles, sino en enterarse antes que el usuario. Se sostiene sobre cuatro planos —disponibilidad, rendimiento, capacidad y corrección—, se resume en cuatro señales cuando hay que priorizar, y se arruina por una sola causa: demasiadas alertas que nadie lee. Empiece pequeño, mida dos semanas antes de fijar umbrales y escriba quién responde a cada aviso.
Si prefiere que esto lo lleve alguien de forma continua, con la vigilancia, los umbrales y la respuesta acordados por escrito, ese es justamente nuestro servicio de monitoreo de infraestructura TI. Y si el problema que tiene es más de fondo, porque no sabe qué hay ni en qué estado, empiece por el inventario y la administración de la infraestructura.
Para profundizar en el marco conceptual de las cuatro señales y en cómo se traducen a objetivos medibles, la referencia abierta es el capítulo de monitoreo del libro de ingeniería de fiabilidad de Google, disponible en línea sin costo.
