Monitorización de Windows Server: métricas clave, alertas y buenas prácticas

Cuando revisitas esa obra maestra llamada Alien, te das cuenta de una cosa, las pistas sutiles de cómo Madre, la computadora, junto a Ash, va a traicionar a la tripulación. Decir que la señal inicial es de auxilio, las respuestas vagas cuando le preguntan, que Ash rompa la cuarentena… Detalles aquí y allá, aparentemente «inocentes». Windows Server no es Madre, pero pasa un poco igual, los problemas rara vez avisan con una caída brusca y la degradación avanza despacio, (casi) silenciosa, hasta que impacta en el servicio.
Por eso la monitorización de Windows Server no es opcional o nos perderemos las pistas del desastre como le ocurrió a la tripulación del Nostromo. Y entonces vamos a tener un caso de acidez estomacal, no tan grave como un alien surgiendo de nosotros, pero casi.
Para evitarlo, la monitorización es el sistema de sensores que marca la diferencia entre si ves venir el problema o te enteras cuando ya te ha explotado el pecho.
Por eso, veremos aquí qué vigilar en Windows Server, cómo interpretarlo y qué señales anticipan el fallo antes de que afecte a la operación.

Qué implica monitorizar Windows Server hoy

Si reducimos monitorizar Windows Server a abrir el Task Manager y echar un vistazo a la CPU, estamos mirando el termómetro cuando el paciente ya tiene cuarenta de fiebre.
Una monitorización útil implica observar de forma continua y contextual:

• El estado del sistema operativo.
• Los servicios que corren sobre él.
• Los recursos que consumen.
• Los errores que generan.
• Las tendencias que dibujan con el tiempo y su relación con el resto de la infraestructura.

Pero por encima de todo, implica hacerlo de forma centralizada y orientada a la operación real, no a coleccionar dashboards que parecen el cuadro de mandos del Enterprise, llenos de datos que nadie interpreta.
La lista anterior, en realidad, no es más que aplicar las mejores prácticas de monitoreo TI moderno, solo que aquí vamos a hacer zoom sobre Windows Server.

Las métricas clave que conviene vigilar en Windows Server

En monitorización, no todos los datos son iguales ni toda la información es conocimiento accionable. Queremos lo segundo y eso significa indicadores clave que debemos vigilar como halcones.
Los principales son:

1. La utilización de la CPU y la cola del procesador

El uso de CPU es lo primero que se mira, pero lo cierto es que no es lo más informativo, necesitamos ver el conjunto.
Lo relevante aquí es la cola del procesador (Processor Queue Length) y comprobar si, de forma sostenida, se mantiene en valores elevados en relación con la capacidad de la CPU.
Cuando es así, el sistema se está atragantando, porque hay más hilos esperando tiempo de CPU del que el sistema puede despachar en ese momento.
Eso ya es señal de atasco antes de que el gráfico de dicha CPU llegue al 100%.
Ahora, hay quien aboga por umbrales concretos (como 2 x procesador lógico disponible), pero cada operación es un mundo. Fiarse de valores estáticos iguales para todos como el anterior puede provocar caídas de rendimiento, aunque no hayamos llegado a dicho umbral.
Por ejemplo, si tenemos 8 procesadores lógicos (4 núcleos con hyper-threading, por ejemplo), ese umbral teórico sería 16, pero en la práctica, valores bastante inferiores mantenidos en el tiempo ya pueden traducirse en toses, cojera y degradación del rendimiento, dependiendo del tipo de carga y del sistema.

2. Memoria: uso, libre y page file

Vamos con el alimento favorito de navegadores web, convertido hoy en un recurso más valioso que el oro.
La memoria disponible no es lo mismo que la memoria libre. Windows gestiona la RAM con su propia lógica, así que la métrica útil es la memoria disponible para nuevas cargas incluyendo la memoria que el sistema puede recuperar rápidamente (como la caché en standby).
Y más importante todavía: la actividad del page file.
Aquí conviene no confundirse con los contadores. Memory\Page Faults/sec suena alarmante, pero incluye muchos fallos resueltos en memoria, así que por sí solo dice poco sobre el rendimiento.
Más útil es Memory\Pages/sec, que agrupa tanto lecturas como escrituras a disco para resolver fallos de página. Si queremos hilar más fino, Memory\Page Reads/sec y Memory\Page Writes/sec desglosan ambas direcciones y sí indican presión real de memoria cuando se mantienen altos.
Si estos valores permanecen elevados de forma constante, el rendimiento se resentirá mucho antes de que salten alertas basadas en porcentajes.

3. Latencia y uso de disco

La latencia de disco es una métrica más traicionera que Ash y Madre juntos, así que hemos de saber leer bien la historia de las cartas que tenemos sobre la mesa.
Por ejemplo, un disco con actividad moderada (como un 70% de Active Time o similar) pero latencia alta es un problema. Mientras, un disco muy ocupado puede seguir rindiendo bien si mantiene latencias bajas y estables.
Lo que hay que monitorizar es el tiempo medio de lectura y escritura, no solo el espacio libre (que enseguida veremos) ni el porcentaje de uso únicamente.
En entornos con bases de datos o IIS, la degradación en la latencia de disco suele ser la antesala de un cuello de botella en la aplicación.

4. Espacio libre por volumen

Lo sencillo puede ser también crítico y este es un ejemplo.
Un volumen lleno puede tumbar un servicio completo sin previo aviso. No hay excusa aquí para que esto nos pille desprevenido con una mínima monitorización.
La alerta debe saltar con tiempo suficiente para actuar, no cuando queda un 2% libre porque alguien ha decidido que se descarga los torrents en el trabajo.
Si queremos hilar fino de nuevo, podemos ajustar la alerta al tipo de disco, ya que no es lo mismo uno de sistema que uno de archivo.

5. Tráfico y errores de red

En este aspecto, el volumen de tráfico en sí puede ser normal, pero:

• Errores de interfaz.
• Paquetes descartados o retransmisiones.
• Picos de latencia de red…

No lo son.
Windows Server puede estar generando errores de red intermitentes que se reflejen en fallos de aplicación aparentemente aleatorios, ante los que te encoges de hombros, achacándolos al capricho insaciable del Dios Máquina.
Si no monitorizamos esa capa, estas incidencias se convierten en gremlins de difícil diagnóstico que pueden poner palos en las ruedas de las operaciones.

6. Estado de servicios críticos

Un servicio detenido puede tener impacto inmediato o pasar desapercibido durante horas.
La clave aquí es:
¿Cuáles son los importantes en nuestro caso?
El estado de IIS, SQL Server, Active Directory, WSUS o cualquier otro servicio crítico debe ser objeto de monitorización continua, no solo verificando que estén en ejecución, sino también que responden correctamente.
De poco sirve saber que IIS se ejecuta si lo hace dando error 500.

7. Eventos del sistema

El Event Viewer de Windows es la mina de oro que rara vez se explota de forma proactiva.
Los errores y advertencias con IDs concretos en logs de sistema, aplicación y seguridad pueden anticipar fallos o evidenciar problemas que aún no han impactado de forma visible.
No me puedo meter a un nivel más bajo sin convertir esto en El Señor de los Anillos, pero además de logs de sistema, aplicación y seguridad (la Santísima Trinidad de lo importante), los Applications and Services Logs o Registros de aplicaciones y servicios (como el log Microsoft-Windows-Diagnostics-Performance o logs específicos de roles como AD DS) pueden ser igual o más relevantes que esos tres clásicos.
Una buena monitorización recoge, filtra y alerta sobre los eventos relevantes, sin ahogarse en el ruido informativo que Windows suele generar en condiciones normales.

8. Tiempos de respuesta de aplicaciones

Para roles como IIS o SQL Server, los tiempos de respuesta son la métrica de usuario final, que al final es el amo al que se supone que servimos.
Si una consulta que normalmente tarda 200 milisegundos empieza a tardar dos segundos, algo ha cambiado.
Una monitorización de sistemas TI efectiva detecta esas desviaciones antes de que lleguen a los usuarios como un ticket de soporte lleno de opiniones asertivas.
Igualmente, es importante no caer en el espejismo que provocan las medias de tiempo de respuesta, ya que pueden ocultar picos graves que dicha media suaviza.
Lo relevante es medir las desviaciones respecto a la línea base histórica de ese entorno concreto.

Qué problemas puede detectar una buena monitorización

Recopilar métricas puede convertirse en hacer esas mil fotos de móvil que luego nunca miras. Por eso, lo importante son los problemas que se detectan gracias a dichas métricas, traducir lo que realmente está diciendo el indicador.
Algunos ejemplos son:

• CPU sistemáticamente elevada. Puede indicar un proceso runaway (que se dispara y no libera la CPU), malware minando bitcoins a nuestra costa, una consulta SQL mal optimizada… O un pico de carga legítimo que ha superado la capacidad del servidor. El síntoma es el mismo, pero vemos que los trastornos pueden ser muy distintos.
• Paginación excesiva. Esto puede ser señal de que el servidor necesita más RAM, o bien que alguna aplicación poco eficiente tiene envidia de Chrome y está devorando memoria de forma anómala, con lo que poner más RAM a precio de oro no soluciona el problema de fondo.
• Degradación progresiva de disco. Pocas veces fallan los discos de golpe (bueno, los SSD la verdad es que pueden). Primero suele subir la latencia, luego aparecen algunos errores y finalmente el disco dobla la servilleta y llega el fallo total, especialmente en los HDD. Con monitorización adecuada, esa servilleta se ve venir en muchos casos.
• Servicios detenidos. Si Active Directory cae sin que nadie lo note, puede paralizar la autenticación de cientos de usuarios antes de que llegue la primera llamada de pánico al helpdesk.
• Volúmenes casi llenos. Un servidor de logs o un directorio temporal a reventar pueden provocar fallos en cascada en aplicaciones, que dependen de ese espacio y lo encuentran okupado cuando llegan.
• Degradación bajo carga. Hay servidores que pueden estar funcionando bien en condiciones normales, pero que no soporten la presión y se degraden en picos de trabajo. Solo el histórico y la correlación entre carga y tiempo de respuesta permiten identificar ese patrón antes de que ocurra en el peor momento.

En todos estos casos, la monitorización no es la ventana para contemplar el descarrilamiento del tren, es el cuadro de mandos de la nave que debe servir para actuar antes de que el impacto de ese tren llegue al servicio (junto con un buen análisis y correlación, claro, que es donde entra Pandora FMS, como veremos más adelante).
Ese es el núcleo del mantenimiento preventivo IT.

Buenas prácticas para monitorizar Windows Server

Una monitorización que sea preventiva y no una mera espectadora de accidentes debe construirse con las columnas de las mejores prácticas. Por eso, veamos las principales en el caso de Windows Server.

1. Definir una línea base

Esta es la piedra fundacional, porque sin saber qué es normal, es imposible saber qué es anómalo.
Todos conocemos a alguien que siempre está repartiendo besos y abrazos por cualquier cosa, mientras que otros son estoicos y media sonrisa en ellos significa más que una carcajada en los primeros.
Por eso, antes de configurar umbrales de alerta, hay que observar el comportamiento del servidor durante un período representativo y establecer una baseline de referencia.
Al fin y al cabo, un servidor de bases de datos tendrá una normalidad muy distinta a un controlador de dominio.

2. Alertar sobre tendencias, no solo sobre picos

Un pico de CPU al 95% durante cinco segundos puede ser irrelevante. Sin embargo, un aumento sostenido del 20% en el uso durante las últimas dos semanas puede ser señal de un problema de planificación de capacidad, o de que hay que analizar y reducir el uso de esa CPU.
Las alertas basadas únicamente en umbrales absolutos son ruidosas e imprecisas.
Un análisis de tendencias suele ser el que realmente anticipa problemas.

3. Adaptar los umbrales al rol del activo

Como no existe un umbral universal correcto, el servidor que aloja SQL Server tolerará un uso de RAM muy distinto al que actúa como servidor de ficheros.
Los umbrales deben adaptarse al papel, carga esperada e historial de comportamiento de cada máquina.

4. Correlacionar métricas entre capas

Desde nuestro Trono de Hierro en Windows Server observamos demasiado tiempo de respuesta en IIS. ¿Por qué?
Puede ser la red, el disco, la CPU, la memoria o la propia aplicación.
Por eso, solo correlacionando métricas de diferentes capas en la misma ventana temporal nos puede dar la causa raíz con rapidez (root cause correlation).
De nuevo, ahí es donde entra una herramienta como Pandora FMS, porque una herramienta para red, otra para sistema y otra para aplicación es estar tuerto tres veces, aunque nos parezca tener tres ojos.

5. Incorporar la planificación de capacidad

Los históricos de monitorización no están para coger polvo en una biblioteca perdida. Ellos nos permiten, entre otras cosas, prever cuándo se quedará un servidor sin recursos antes de que ocurra.
Eso es eficiencia operativa IT concreta, actuar con margen como previsores y no estar siempre en modo bombero con los pantalones ardiendo.

Entornos virtualizados y cargas críticas en Windows Server

Hoy es difícil escapar de Matrix y también de la virtualización cuando gestionamos IT, así que mejor enfrentarla de cara.
En entornos Hyper-V, la monitorización tiene una capa adicional de complejidad, la relación entre el host y sus máquinas virtuales.
Un host con su memoria demasiado comprometida (por ejemplo, con Dynamic Memory mal configurada o demasiadas VMs compitiendo por RAM) provocará contención de recursos entre las VMs. Eso puede hacer que cada una muestre síntomas de degradación que, si solo se monitorizan por dentro, parecen problemas propios de la máquina virtual, cuando el origen real está en el host.
Lo mismo ocurre si ese host está bajo presión de disco o red.
La latencia que sufren las VMs puede ser difícil de diagnosticar desde dentro de cada una de ellas, de modo que la monitorización del sistema operativo invitado es ver solamente la mitad de la película.
Los roles críticos de Windows Server (controladores de dominio, servidores de certificados o características críticas como la replicación de Hyper-V) tienen además sus propias métricas específicas.
Un controlador de dominio con una latencia alta en la replicación puede funcionar con aparente normalidad… hasta que falla la autenticación en toda la red. El reto es que ese tipo de problema no aparece en ningún gráfico de CPU.
Si nuestro caso incluye virtualización, la documentación oficial de Microsoft para Windows Server y el módulo de monitorización de rendimiento son buenos puntos de partida para conocer las herramientas nativas disponibles.
En ellas encontramos:

• El clásico Performance Monitor.
• El Windows Admin Center.
• Los contadores de rendimiento.

Sin embargo, estas herramientas tienen un alcance limitado porque son útiles para diagnóstico puntual y monitorización local, pero requieren integración adicional para una operación continua y centralizada en entornos complejos.
En esos casos, ¿Qué hacemos para monitorizar sin morir en el intento?

Cómo ayuda Pandora FMS a monitorizar Windows Server

Una vez más, no monitorizamos para crear dashboards espectaculares o informes que nadie lee, nuestra misión es evitar los descarrilamientos, no documentarlos una vez ocurridos.
Y una clave para ello es esa correlación profunda de distintas capas y activos de nuestra infraestructura IT.
Pandora FMS cuenta con un agente Windows nativo que recoge métricas del sistema operativo, servicios, procesos, eventos y cualquier otra información relevante, enviándola de forma centralizada a la consola.
Eso permite operar con una vista unificada de monitorización de servidores, en lugar de conectarse a cada máquina por separado cuando algo falla.
Además de darnos superpoderes de visión, Pandora FMS también los concede de análisis y correlación, que como hemos visto, es la clave.
Por eso, más allá del agente, Pandora FMS permite configurar monitores específicos para roles concretos: IIS, SQL Server, Active Directory o Hyper-V.
La correlación entre CPU, memoria, disco, red y estado de servicios en la misma ventana temporal es la clave para diagnosticar problemas con rapidez, sin tener que cruzar datos entre herramientas distintas.
Además, Windows Server es ruidoso y no necesitamos más estrés en IT. Por eso, las alertas son configurables sobre tendencias y no solo sobre umbrales absolutos, lo que reduce ese ruido y mejora la calidad de los avisos.
Siguiendo con las buenas prácticas que hemos visto, el histórico permite hacer capacity planning real.
¿Y qué ocurre en sistemas mixtos? Porque las reglas de pureza quedan bien para cervezas y similares, pero el día a día en IT es una mezcla de servidores Windows y Linux, dispositivos de red, entornos cloud y/o máquinas virtuales.
No pasa nada. Pandora FMS centraliza toda la monitorización de infraestructura sin obligar a operar herramientas distintas para cada capa.
En entornos complejos (no sé si queda alguno sencillo, la verdad) eso marca la diferencia entre tener visibilidad y control total, como Madre en la Nostromo, o gestionar silos de información desconectados.
La detección temprana evita la curación tardía y en eso se resume la monitorización de Windows Server.
Paginación creciente, latencia de disco en aumento, errores relevantes en el Event Viewer, servicios inestables, tendencias de CPU al alza… Se trata de interpretar bien las señales de humo dentro de su contexto y actuar en las que sean fuego de verdad, antes de que el impacto llegue al servicio.
Y hacerlo en conjunto, facilitándonos la vida con una herramienta global y especializada como Pandora FMS. Ella hubiera correlacionado todas esas señales sutiles en Alien y habría detectado a tiempo que Madre nos estaba traicionando.
(Nota para cinéfilos: Sí, lo sé, Madre, en realidad, no traicionó a Ripley y compañía. Solo siguió su programación de salvar al xenomorfo como fuera, a costa de una tripulación prescindible. Pero Pandora hubiera unido los puntos igualmente de antemano si la hubieran tenido instalada, mostrando que Madre no hacía lo que creíamos que hacía…).