Cómo medir I/O de disco por proceso y lanzar alertas en PowerShell

Cuando gestionas decenas o miles de servidores Windows, controlar el uso de disco por proceso y recibir alertas a tiempo marca la diferencia entre un entorno sano y un incidente crítico en plena madrugada. El espacio y la I/O de disco suelen ser cuellos de botella silenciosos: todo parece ir bien… hasta que las escrituras se disparan, la cola de disco se alarga y las aplicaciones empiezan a arrastrarse.

En este artículo vamos a ver, paso a paso, cómo medir la actividad de disco por proceso y generar alertas automáticas con PowerShell, apoyándonos tanto en las herramientas clásicas de Windows (Monitor de rendimiento, registros de datos, alertas nativas) como en scripts avanzados que integran correo electrónico, webhooks y plataformas de monitorización. Además, enlazaremos estos conceptos con escenarios reales de administración masiva (como revisar 6000 servidores antes de un ciclo de parches) y con buenas prácticas para evitar sorpresas con el rendimiento del almacenamiento, incluidos entornos con Espacios de almacenamiento directo (S2D).

Medir espacio libre e I/O de disco por proceso en Windows

La base de cualquier estrategia de alertas es saber medir bien. En Windows contamos con varias opciones para controlar el espacio libre y la actividad de disco, tanto a nivel global como por proceso: Monitor de rendimiento, cmdlets como Get-Counter, clases WMI/CIM y herramientas específicas para S2D.

Contadores de rendimiento clave para disco

En el Monitor de rendimiento puedes ver y registrar los contadores de disco más relevantes para diagnosticar I/O. A nivel de volumen y de disco físico, los más utilizados son:

• LogicalDisk / % Free Space: porcentaje de espacio libre en cada volumen lógico.
• LogicalDisk / Free Megabytes: espacio libre absoluto en MB.
• PhysicalDisk / Disk Reads/sec y Disk Writes/sec: número de lecturas y escrituras por segundo.
• PhysicalDisk / Avg. Disk sec/Read y Avg. Disk sec/Write: latencia media de lectura y escritura.
• PhysicalDisk / Current Disk Queue Length: longitud actual de la cola de disco, clave para detectar saturación.

Si quieres bajar al detalle por proceso, necesitas activar la supervisión de procesos en la política de supervisión (por ejemplo, en entornos Citrix) o usar contadores como Process junto con métricas específicas del agente o soluciones de terceros como Process Hacker que mapeen procesos a I/O de disco. En la consola de Monitor de rendimiento puedes añadir el objeto Process y observar, entre otros, IO Read Bytes/sec y IO Write Bytes/sec por proceso.

Uso de PowerShell y Get-Counter para medir I/O

PowerShell permite consultar los mismos contadores de rendimiento desde línea de comandos mediante Get-Counter. Esto es fundamental si quieres automatizar comprobaciones o generar alertas en un script:

Ejemplos de contadores útiles:

• \Servidor\LogicalDisk(C:)\% Free Space para el espacio libre en C:.
• \Servidor\PhysicalDisk(_Total)\Disk Bytes/sec para el caudal total de I/O.
• \Servidor\Process(*)\IO Write Bytes/sec para ver escrituras por proceso.

Desde PowerShell puedes recuperar estos datos así (a modo de ejemplo conceptual): consultas periódicas con Get-Counter, filtrando por el contador deseado, y luego procesas la salida para quedarte con las instancias que más I/O consumen. De esta forma podrás identificar rápidamente procesos que saturan disco, como el proceso searchindexer.exe, y vincularlos a reglas de alerta.

Espacios de almacenamiento directo (S2D) y métricas específicas

Si estás usando Espacios de almacenamiento directo (S2D), debes tener en cuenta que la degradación de rendimiento puede venir de la propia configuración del espacio de almacenamiento, no solo de procesos concretos. Los síntomas típicos son lecturas/escrituras más lentas de lo normal, colas de disco altas y aplicaciones que tardan en cargar.

En S2D influyen factores como tipo de resiliencia mal elegido (paridad frente a espejo), mezcla de discos SSD/HDD en el mismo pool sin capas adecuadas, firmware o controladores desactualizados y tareas de mantenimiento en segundo plano que compiten por I/O. Antes de culpar a un proceso, conviene revisar:

• La salud del pool con Get-StoragePool y Get-PhysicalDisk.
• El tipo de volumen (Get-VirtualDisk y su ResiliencySettingName).
• Los registros del Visor de eventos en las categorías Sistema y Espacios de almacenamiento.

Una vez comprobado que el tejido de almacenamiento está sano, ya puedes centrarte en qué procesos están ejerciendo presión sobre el disco y si tu sistema necesita más capacidad o una redistribución de cargas.

Configurar alertas de disco nativas en Windows

Windows Server incluye desde hace años un mecanismo para lanzar alertas cuando se alcanza un umbral de espacio en disco sin instalar nada adicional: la característica de Registros de rendimiento y alertas (Performance Logs and Alerts), accesible desde la consola de Rendimiento en versiones clásicas como Windows Server 2003, y su equivalente en versiones más modernas.

Creación de una alerta de espacio en disco bajo con Monitor de rendimiento

Para crear una alerta sencilla que vigile el espacio libre en una unidad lógica y dispare acciones cuando baje de cierto valor, el flujo clásico en la consola de Rendimiento es:

1. Abrir la consola de Rendimiento desde Herramientas administrativas y expandir “Registros de rendimiento y alertas”.
2. En el nodo de Alertas, crear una nueva configuración de alerta con un nombre descriptivo (por ejemplo, “Espacio libre en disco C”).
3. En la pestaña General, definir un comentario claro, como “Supervisar espacio libre en disco en la unidad C:”.
4. Pulsar en Agregar contadores y elegir el objeto LogicalDisk, el contador % Free Space y la instancia de la unidad (C:, D:, etc.).
5. Configurar la condición “Alerta cuando el valor sea: Bajo” y el umbral adecuado (por ejemplo, menos de un 10% de espacio libre).
6. Ajustar el intervalo de muestreo (por defecto 5 segundos, pero en entornos de producción suele ser suficiente cada 1-5 minutos).

Con esto tienes el contador listo para disparar la alerta cuando el valor de espacio libre baje de lo que hayas definido, pero aún falta decidir qué acción se ejecutará al saltar la alerta.

Acciones asociadas a la alerta: registro, mensajes y programas

En la pestaña Acción de la alerta puedes definir qué debe hacer el servidor cuando se cumpla la condición de espacio bajo. Las opciones habituales son:

• Registrar una entrada en el registro de eventos de aplicaciones, para que quede constancia y pueda ser recogida por sistemas de monitorización.
• Enviar un mensaje de red aprovechando el servicio Messenger (en entornos antiguos) que muestre el aviso en otro equipo.
• Iniciar un registro de contador adicional cuando se dispara la alerta, útil para recopilar más datos de diagnóstico durante el incidente.
• Ejecutar un programa o script (por ejemplo, un archivo .ps1 de PowerShell) pasando parámetros de contexto mediante los “Command Line Arguments”.

Este último punto es clave: si apuntas esta acción a un script de PowerShell que mida procesos, genere informes o envíe correos, conviertes una alerta simple de espacio libre en el disparador de tu plataforma de automatización.

Programación y persistencia de las alertas

En la pestaña Programación decides cuándo empieza y termina la supervisión. Puedes:

• Iniciar el examen manualmente o fijar una fecha y hora concreta.
• Detenerlo manualmente, tras un periodo de tiempo o en una fecha y hora.

Para que la alerta siga activa incluso tras reinicios, una práctica común es configurar “Detener examen” con la opción “Después” y un número de días muy alto (hasta 100 000). Además, se marca la casilla “Iniciar un nuevo examen” para que, cuando llegue la fecha de fin, la propia alerta se reinicie automáticamente y continúe su funcionamiento sin intervención manual.

Automatizar con PowerShell: espacio, I/O por proceso y alertas

La magia llega cuando combinas lo anterior con PowerShell. De esta forma puedes consultar el estado de cientos o miles de servidores, medir espacio e I/O, y actuar de forma automática antes de un mantenimiento o cuando se superen ciertos umbrales críticos.

Escenario real: 6000 servidores y comprobación de C: antes de parches

Imagina que gestionas más de 6000 servidores y vas a lanzar una ventana de parcheo. Antes de actualizar, necesitas garantizar que la unidad C: tiene por ejemplo al menos un 20% libre; de lo contrario, el riesgo de que falle el proceso de actualización se dispara. Hacer esto a mano sería un infierno, así que la solución natural es:

• Definir una lista o inventario de servidores (por ejemplo, en un CSV o en Active Directory).
• Usar un script de PowerShell que recoja remotamente el espacio libre de C: en cada servidor.
• Filtrar solo aquellos con menos del 10-20% de espacio disponible.
• Generar un informe y, si la infraestructura lo permite, automatizar la expansión del disco (en VMware, Hyper-V, almacenamiento en la nube, etc.) en el mismo script.

Con PowerShell Remoting y cmdlets de gestión de discos o APIs del hipervisor, puedes montar un flujo donde el propio script amplíe el disco virtual y luego extienda el volumen dentro del sistema operativo, dejando los servidores listos para parchear. Eso sí, siempre respetando las políticas de cambio y con pruebas previas en un entorno controlado.

Diseño de scripts de PowerShell robustos para monitorización

Cuando escribes scripts de monitorización y alertas, conviene aplicar buenas prácticas de scripting en PowerShell para que sean mantenibles, seguros y fáciles de depurar:

• Dividir la lógica en funciones reutilizables: por ejemplo, una función para medir espacio libre, otra para recopilar contadores de I/O por proceso, otra para enviar alertas.
• Usar estructuras try/catch/finally para el manejo de errores, registrándolos con claridad.
• Incluir validación de entradas y parámetros para evitar comportamientos inesperados.
• Centralizar la configuración (umbrales, credenciales, listas de servidores) en ficheros externos o parámetros de script.

También es recomendable apoyar el desarrollo en herramientas de depuración como VS Code, usando puntos de interrupción, inspección de variables y control de $ErrorActionPreference. Cuanto más complejo sea el entorno (AD, Azure, S2D, Citrix, etc.), más agradecerás tener un script modular y probadamente estable.

Envío de alertas: correo, webhooks y mensajería

Una vez detectada la condición peligrosa (poco espacio, I/O disparada, colas de disco altas), el script debe comunicar la alerta de manera fiable. Las vías típicas en PowerShell son:

• Correo electrónico usando cmdlets como Send-MailMessage o módulos modernos que se integren con tu sistema de correo.
• Webhooks HTTP/HTTPS mediante Invoke-RestMethod o Invoke-WebRequest, enviando una carga JSON hacia plataformas como Slack, Teams, sistemas ITSM o herramientas de orquestación.
• Integración con event logs (escribiendo entradas en el Visor de eventos) para que soluciones como SCOM, Nagios, Zabbix o similares recojan y procesen la alerta.

En entornos Citrix DaaS, por ejemplo, las notificaciones por correo se envían habitualmente vía SendGrid desde una dirección predefinida como donotreplynotifications@citrix.com, por lo que conviene tenerla permitida en tu configuración de correo. En el caso de webhooks, puedes definir perfiles con autenticación, cabeceras personalizadas y formato de carga, ya sea texto o JSON.

Alertas avanzadas: Citrix, hipervisores y webhooks

Más allá del sistema operativo, muchas organizaciones se apoyan en capas de monitorización adicionales como Citrix Monitor, Delivery Controllers y alertas del hipervisor para tener una visión completa del rendimiento y la salud, incluida la parte de disco.

Alertas de Citrix y directivas inteligentes

En entornos Citrix, la sección de Supervisar > Alertas muestra avisos críticos y de advertencia con símbolos visuales (círculo rojo, triángulo ámbar) que se actualizan automáticamente cada minuto. Desde ahí puedes:

• Ver un resumen de alertas críticas y de advertencia para tus grupos de entrega y VDAs.
• Acceder a la vista detallada de alertas para filtrar, exportar e investigar lo ocurrido.
• Configurar directivas de alertas de Citrix que definan umbrales para CPU, memoria, sesiones, máquinas fallidas, etc.

Las llamadas directivas de alertas inteligentes vienen predefinidas con umbrales recomendados para distintos ámbitos (por ejemplo, grupo de entrega con SO multisesión) y condiciones como:

• CPU por encima del 80% (advertencia) o 90% (crítico).
• Memoria por encima del 80% (advertencia) o 90% (crítico).
• RTT ICA elevado, tanto por número de sesiones afectadas como por porcentaje.
• Máquinas fallidas, tanto en número absoluto como en porcentaje.

Muchas de estas métricas están relacionadas con carga global de la máquina, que a su vez impacta en la I/O de disco. Una CPU al 90% con mucha paginación y alto uso de disco suele ser una señal clara de que hace falta actuar, ya sea minimizando procesos o ampliando recursos; por ejemplo, aplicaciones que tardan en abrir, como Office tarda mucho en abrir.

Directivas de alerta avanzadas y ahorro de costes

Citrix ha incorporado un marco de directivas de alerta avanzadas que permite crear reglas muy granulares basadas en orígenes de datos como Máquinas, Provisioning Service o StoreFront. Entre otras cosas, puedes configurar:

• Alertas de ahorro de costes para detectar máquinas con administración de energía que no se apagan, no se encienden o tienen un tiempo de actividad excesivo.
• Alertas de infraestructura sobre accesibilidad, servicios dependientes, impacto y utilización de recursos.
• Repetición de alertas con intervalos configurables y diferentes niveles de gravedad.

Cada alerta puede tener un ámbito bien definido (sitio completo, grupo de entrega concreto, subconjunto de máquinas) y excepciones para excluir recursos que no quieras que generen avisos. Además, puedes elegir los canales de notificación: correo o webhook, con opción de adjuntar un CSV o una carga JSON detallada con los parámetros de la alerta.

Integración de PowerShell con directivas y webhooks

El SDK de PowerShell de Citrix permite crear, modificar y eliminar directivas de alerta y perfiles de webhook directamente desde scripts. Esto se traduce en:

• Comandos para crear una directiva nueva con una condición concreta, por ejemplo, porcentaje de máquinas no registradas por encima de un valor.
• Cmdlets para asociar un perfil de webhook o una configuración de correo a la directiva.
• Posibilidad de probar perfiles de webhook desde PowerShell, verificando que la carga llega correctamente a la herramienta de destino.

Los webhooks se definen con parámetros como URL de destino, tipo de autenticación, cabeceras HTTP, tipo de contenido y plantilla de carga. De este modo, cuando una directiva salta (por ejemplo, demasiadas máquinas con alto tiempo de actividad o acciones de encendido/apagado fallidas), se envía un POST HTTP con la información de alerta que tu herramienta de automatización puede procesar.

Alertas de hipervisor y estado del almacenamiento subyacente

No hay que olvidar que, muchas veces, los problemas de disco vienen de la capa de hipervisor, no del sistema operativo invitado. Citrix Hypervisor y VMware vSphere permiten definir umbrales para:

• Uso de CPU, memoria y red del host.
• Uso de disco a nivel de datastore (en el caso de vSphere).
• Estado de conexión del host o clúster de hipervisor.

Cuando estos umbrales se superan, el hipervisor genera alertas que se pueden visualizar en la consola de Supervisar dentro de la categoría “Estado del hipervisor”. Es importante tener claro que:

• Los umbrales se configuran en la consola del hipervisor, no en la de Supervisar.
• Las alertas antiguas (más de un día) se descartan automáticamente en la capa de monitorización.
• Descartar una alerta en Supervisar no la descarta necesariamente en la consola del hipervisor, y viceversa.

Si tus scripts de PowerShell detectan problemas de I/O inusuales en las máquinas virtuales, conviene revisar simultáneamente estas alertas del hipervisor, porque quizás el cuello de botella está en un datastore saturado, un host al límite o un fallo de conectividad con el backend de almacenamiento (por ejemplo, revisar diferencias entre VMCX y VMRs en Hyper-V).

Buenas prácticas para evitar cuellos de botella de disco

Más allá de medir y alertar, resulta esencial aplicar una serie de buenas prácticas de diseño y operación para reducir la probabilidad de encontrarte con un cuello de botella de disco grave.

Diseño y mantenimiento de Espacios de almacenamiento (S2D)

En entornos con S2D, procura que los pools de almacenamiento usen discos homogéneos en cuanto a tipo de medio, capacidad y rendimiento. Evita mezclar SSD y HDD en el mismo pool si no implementas adecuadamente el almacenamiento en capas, y revisa:

• Que el tipo de resiliencia (simple, espejo, paridad) sea el apropiado para la carga de trabajo.
• Que el firmware y los controladores de todas las unidades estén actualizados.
• Que las tareas de mantenimiento de almacenamiento (reparaciones, limpiezas) se programen en periodos de baja actividad.

Regularmente, ejecuta tareas como Optimize-StoragePool para equilibrar el pool y, si usas HDD, desfragmenta cuando proceda. Siempre que hagas cambios de este tipo, merece la pena medir de nuevo el rendimiento para comparar con la línea base anterior.

Supervisión continua y líneas base de rendimiento

No tiene mucho sentido generar alertas sin tener claro qué se considera “normal” en tu entorno. Por eso es tan importante establecer líneas base de rendimiento midiendo durante un tiempo razonable:

• Latencias medias de lectura/escritura.
• Longitud de cola típica bajo carga normal.
• Rango habitual de I/O por proceso para servicios críticos.

Con esos datos en la mano podrás ajustar umbrales realistas, tanto en tus scripts de PowerShell como en directivas de alerta (Citrix, hipervisor, monitorización corporativa) evitando el clásico problema de “alerta por todo” que termina en fatiga y pérdida de confianza en el sistema.

La combinación de medición precisa de I/O por proceso, configuración sensata de alertas nativas, automatización con PowerShell y uso coordinado de plataformas como Citrix Monitor y las alertas del hipervisor te permite detectar rápido los problemas de disco, reaccionar antes de que impacten en el negocio y, de paso, optimizar costes apagando recursos o ajustando tiempos de actividad. Con una buena estrategia de scripting y monitorización, incluso entornos con miles de servidores y soluciones de almacenamiento complejas (S2D, clusters de hipervisores, VDAs de sesión múltiple) se vuelven mucho más manejables.