Com mesurar I/O de disc per procés i llançar alertes a PowerShell

Quan gestiones desenes o milers de servidors Windows, controlar lús de disc per procés i rebre alertes a temps marca la diferència entre un entorn sa i un incident crític en plena matinada. L'espai i la I/O de disc solen ser colls d'ampolla silenciosos: tot sembla anar bé… fins que les escriptures es disparen, la cua de disc s'allarga i les aplicacions es comencen a arrossegar.

En aquest article veurem, pas a pas, com mesurar l'activitat de disc per procés i generar alertes automàtiques amb PowerShell , recolzant-nos tant en les eines clàssiques de Windows (Monitor de rendiment, registres de dades, alertes natives) com en scripts avançats que integren correu electrònic, webhooks i plataformes de monitorització. A més, enllaçarem aquests conceptes amb escenaris reals d'administració massiva (com revisar 6000 servidors abans d'un cicle de pegats) i amb bones pràctiques per evitar sorpreses amb el rendiment de l'emmagatzematge, inclosos entorns amb Espais d'emmagatzematge directe (S2D).

Mesurar espai lliure i I/O de disc per procés a Windows

La base de qualsevol estratègia d'alertes és saber mesurar bé. A Windows comptem amb diverses opcions per controlar l'espai lliure i l'activitat de disc, tant a nivell global com per procés: Monitor de rendiment, cmdlets com Get-Counter, classes WMI/CIM i eines específiques per a S2D.

Comptadors de rendiment clau per a disc

Al monitor de rendiment pots veure i registrar els comptadors de disc més rellevants per diagnosticar I/O . A nivell de volum i de disc físic, els més utilitzats són:

• LogicalDisk / % Free Space: percentatge d'espai lliure a cada volum lògic.
• LogicalDisk / Free Megabytes: espai lliure absolut a MB.
• PhysicalDisk / Disk Reads/sec y Disk Writes/sec: nombre de lectures i escriptures per segon.
• PhysicalDisk / Avg. Disk sec/Read y Avg. Disk sec/Write: latència mitjana de lectura i escriptura.
• PhysicalDisk / Current Disk Queue Length: longitud actual de la cua de disc, clau per detectar saturació.

Si vols baixar al detall per procés, necessites activar la supervisió de processos a la política de supervisió (per exemple, en entorns Citrix) o utilitzar comptadors com Process juntament amb mètriques específiques de l'agent o solucions de tercers com Hacker de processos que mapegin processos a I/O de disc. A la consola de Monitor de rendiment podeu afegir l'objecte procés i observar, entre d'altres, IO Read Bytes/sec y IO Write Bytes/sec per procés.

Ús de PowerShell i Get-Counter per mesurar I/O

PowerShell permet consultar els mateixos comptadors de rendiment des de línia de ordres mitjançant Get-Counter. Això és fonamental si vols automatitzar comprovacions o generar alertes en un script:

Exemples de comptadors útils:

• \Servidor\LogicalDisk(C:)\% Free Space per a l'espai lliure a C:.
• \Servidor\PhysicalDisk(_Total)\Disk Bytes/sec per al cabal total de I/O.
• \Servidor\Process(*)\IO Write Bytes/sec per veure escriptures per procés.

Des de PowerShell pots recuperar aquestes dades així (a tall d'exemple conceptual): consultes periòdiques amb Get-Counter , filtrant pel comptador desitjat, i després processes la sortida per quedar-te amb les instàncies que més I/O consumeixen. D'aquesta manera podreu identificar ràpidament processos que saturen disc, com el procés searchindexer.exe , i vincular-los a regles d'alerta.

Espais d'emmagatzematge directe (S2D) i mètriques específiques

Si utilitzeu Espais d'emmagatzematge directe (S2D) , heu de tenir en compte que la degradació de rendiment pot venir de la pròpia configuració de l'espai d'emmagatzematge , no només de processos concrets. Els símptomes típics són lectures/escriptures més lentes del normal, cues de disc altes i aplicacions que triguen a carregar.

A S2D influeixen factors com a tipus de resiliència mal triat (paritat davant de mirall), barreja de discos SSD/HDD al mateix pool sense capes adequades, firmware o controladors desactualitzats i tasques de manteniment en segon pla que competeixen per I/O. Abans de culpar un procés, convé revisar:

• La salut del pool amb Get-StoragePool y Get-PhysicalDisk.
• El tipus de volum (Get-VirtualDisk i la seva ResiliencySettingName).
• Els registres del Visor d'esdeveniments a les categories Sistema y Espais d'emmagatzematge.

Un cop comprovat que el teixit d'emmagatzematge està sa, ja et pots centrar en quins processos estan exercint pressió sobre el disc i si el teu sistema necessita més capacitat o una redistribució de càrregues.

Configurar alertes de disc natives a Windows

Windows Server inclou des de fa anys un mecanisme per llançar alertes quan s'arriba a un llindar d'espai en disc sense instal·lar res addicional: la característica de Registres de rendiment i alertes (Performance Logs and Alerts), accessible des de la consola de Rendiment en versions clàssiques com Windows Server 2003, i el seu equivalent en versions més modernes.

Creació d'una alerta d'espai al disc baix amb Monitor de rendiment

Per crear una alerta senzilla que vigili l'espai lliure en una unitat lògica i dispari accions quan baixi de cert valor, el flux clàssic a la consola de Rendiment és:

1. Obrir la consola de Rendiment des d'Eines administratives i expandir “Registres de rendiment i alertes”.
2. Al node d'Alertes, crear una nova configuració d'alerta amb un nom descriptiu (per exemple, “Espai lliure al disc C”).
3. A la pestanya General, definir un comentari clar, com “Supervisar espai lliure en disc a la unitat C:”.
4. Cliqueu a Afegeix comptadors i trieu l'objecte LogicalDisk, el comptador % Free Space i la instància de la unitat (C:, D:, etc.).
5. Configurar la condició “Alerta quan el valor sigui: Baix” i el llindar adequat (per exemple menys d'un 10% d'espai lliure).
6. Ajusteu l'interval de mostreig (per defecte 5 segons, però en entorns de producció sol ser suficient cada 1-5 minuts).

Amb això tens el comptador llest per disparar l'alerta quan el valor d'espai lliure baixi del que hagis definit, però encara falta decidir quina acció s'executarà en saltar l'alerta.

Accions associades a l'alerta: registre, missatges i programes

A la pestanya Acció de l'alerta podeu definir què ha de fer el servidor quan es compleixi la condició d'espai baix . Les opcions habituals són:

• Registrar una entrada al registre d'esdeveniments d'aplicacions, perquè en quedi constància i pugui ser recollida per sistemes de monitorització.
• Enviar un missatge de xarxa aprofitant el servei Missatger (en entorns antics) que mostri l'avís a un altre equip.
• Iniciar un registre de comptador addicional quan es dispara l'alerta, útil per recopilar més dades de diagnòstic durant l'incident.
• Executar un programa o script (per exemple, un fitxer .ps1 de PowerShell) passant paràmetres de context mitjançant els “Command Line Arguments”.

Aquest darrer punt és clau: si apunteu aquesta acció a un script de PowerShell que mesuri processos, generi informes o envieu correus , convertiu una alerta simple d'espai lliure en el disparador de la vostra plataforma d'automatització.

Programació i persistència de les alertes

A la pestanya Programació decideixes quan comença i acaba la supervisió . Pots:

• Inicieu l'examen manualment o fixeu una data i hora concreta.
• Aturar-lo manualment, després d'un període de temps o en una data i hora.

Perquè l'alerta segueixi activa fins i tot després de reinicis , una pràctica comuna és configurar “Aturar examen” amb l'opció “Després” i un nombre de dies molt alt (fins a 100.000). A més, es marca la casella “Iniciar un nou examen” perquè, quan arribi la data de fi, la pròpia alerta es reiniciï automàticament i continuï el seu funcionament sense intervenció manual.

Automatitzar amb PowerShell: espai, I/O per procés i alertes

La màgia arriba quan combines això amb PowerShell. D'aquesta manera podeu consultar l'estat de centenars o milers de servidors, mesurar espai i I/O, i actuar de forma automàtica abans d'un manteniment o quan se superin certs llindars crítics.

Escenari real: 6000 servidors i comprovació de C: abans de pegats

Imagina que gestiones més de 6000 servidors i llançaràs una finestra de pegat . Abans d'actualitzar, necessiteu garantir que la unitat C: té per exemple almenys un 20% lliure; altrament, el risc que falli el procés d'actualització es dispara. Fer això a mà seria un infern, així que la solució natural és:

• Definir una llista o inventari de servidors (per exemple, en un CSV o Active Directory).
• Utilitza un script de PowerShell que reculli remotament l'espai lliure de C: a cada servidor.
• Filtrar només aquells amb menys del 10-20% despai disponible.
• Generar un informe i, si la infraestructura ho permet, automatitzar l'expansió del disc (en VMware, Hyper-V, emmagatzematge al núvol, etc.) en el mateix script.

Amb PowerShell Remoting i cmdlets de gestió de discos o APIs de l'hipervisor, pots muntar un flux on el mateix script ampliï el disc virtual i després estengui el volum dins del sistema operatiu , deixant els servidors llestos per a pegats. Això sí, sempre respectant les polítiques de canvi i amb proves prèvies en un entorn controlat.

Disseny de scripts de PowerShell robusts per a monitorització

Quan escrius scripts de monitorització i alertes, convé aplicar bones pràctiques de scripting a PowerShell perquè siguin mantenibles, segurs i fàcils de depurar:

• Dividir la lògica en funcions reutilitzables: per exemple, una funció per mesurar espai lliure, una altra per recopilar comptadors de I/O per procés, una altra per enviar alertes.
• Usar estructures provar/atrapar/finalment per al maneig derrors, registrant-los amb claredat.
• Incloure validació d'entrades i paràmetres per evitar comportaments inesperats.
• Centralitzar la configuració (llindars, credencials, llistes de servidors) en fitxers externs o paràmetres de script.

També és recomanable donar suport al desenvolupament en eines de depuració com VS Code, usant punts d'interrupció, inspecció de variables i control de $ErrorActionPreference. Com més complex sigui l'entorn (AD, Azure, S2D, Citrix, etc.) més agrairàs tenir un script modular i provadament estable.

Enviament d'alertes: correu, webhooks i missatgeria

Un cop detectada la condició perillosa (poc espai, I/O disparada, cues de disc altes), l'script ha de comunicar l'alerta de manera fiable . Les vies típiques a PowerShell són:

• Correu electrònic usant cmdlets com Send-MailMessage o mòduls moderns que s'integrin amb el vostre sistema de correu.
• Webhooks HTTP/HTTPS mitjançant Invoke-RestMethod o Invoke-WebRequest, enviant una càrrega JSON cap a plataformes com Slack, Teams, sistemes ITSM o eines d'orquestració.
• integració amb registres d'esdeveniments (escrivint entrades al Visor d'esdeveniments) perquè solucions com SCOM, Nagios, Zabbix o similars recullin i processin l'alerta.

En entorns Citrix DaaS, per exemple, les notificacions per correu s'envien habitualment via SendGrid des d'una adreça predefinida com [email protected], pel que convé tenir-la permesa a la teva configuració de correu. En el cas de webhooks, podeu definir perfils amb autenticació, capçaleres personalitzades i format de càrrega, ja sigui text o JSON.

Alertes avançades: Citrix, hipervisors i webhooks

Més enllà del sistema operatiu, moltes organitzacions es recolzen en capes de monitoratge addicionals com Citrix Monitor, Delivery Controllers i alertes de l'hipervisor per tenir una visió completa del rendiment i la salut, inclosa la part de disc.

Alertes de Citrix i directives intel·ligents

En entorns Citrix, la secció de Supervisar > Alertes mostra avisos crítics i d'advertència amb símbols visuals (cercle vermell, triangle ambre) que s'actualitzen automàticament cada minut. Des d'allà pots:

• Veure un resum d'alertes crítiques i d'advertència per als grups de lliurament i VDAs.
• Accedir a la vista detallada d'alertes per filtrar, exportar i investigar el que ha passat.
• Configura directives d'alertes de Citrix que defineixin llindars per a CPU, memòria, sessions, màquines fallides, etc.

Les trucades directives d'alertes intel·ligents vénen predefinides amb llindars recomanats per a diferents àmbits (per exemple, grup de lliurament amb SO multisessió) i condicions com:

• CPU per sobre del 80% (advertiment) o 90% (crític).
• Memòria per sobre del 80% (advertiment) o 90% (crític).
• RTT ICA elevat tant per nombre de sessions afectades com per percentatge.
• Màquines fallides, tant en nombre absolut com en percentatge.

Moltes d'aquestes mètriques estan relacionades amb càrrega global de la màquina, que alhora impacta a la I/O de disc . Una CPU al 90% amb molta paginació i alt ús de disc sol ser un senyal clar que cal actuar, ja sigui minimitzant processos o ampliant recursos; per exemple, aplicacions que triguen a obrir, com Office triga molt a obrir.

Directives d'alerta avançades i estalvi de costos

Citrix ha incorporat un marc de directives d'alerta avançades que permet crear regles molt granulars basades en orígens de dades com ara Màquines, Provisioning Service o StoreFront. Entre altres coses, podeu configurar:

• Alertes d'estalvi de costos per detectar màquines amb administració denergia que no sapaguen, no sencenen o tenen un temps dactivitat excessiu.
• Alertes d'infraestructura sobre accessibilitat, serveis dependents, impacte i utilització de recursos.
• Repetició d'alertes amb intervals configurables i diferents nivells de gravetat.

Cada alerta pot tenir un àmbit ben definit (lloc complet, grup de lliurament concret, subconjunt de màquines) i excepcions per excloure recursos que no vulguis que generin avisos. A més, podeu triar els canals de notificació: correu o webhook, amb opció d'adjuntar un CSV o una càrrega JSON detallada amb els paràmetres de l'alerta.

Integració de PowerShell amb directives i webhooks

El Citrix SDK de PowerShell permet crear, modificar i eliminar directives d'alerta i perfils de webhook directament des de scripts. Això es tradueix en:

• Ordres per crear una nova directiva amb una condició concreta, per exemple, percentatge de màquines no registrades per sobre d'un valor.
• Cmdlets per associar un perfil de webhook o una configuració de correu a la directiva.
• Possibilitat de provar perfils de webhook des de PowerShell, verificant que la càrrega arriba correctament a l'eina de destinació.

Els webhooks es defineixen amb paràmetres com a URL de destinació, tipus d'autenticació, capçaleres HTTP, tipus de contingut i plantilla de càrrega . D'aquesta manera, quan una directiva salta (per exemple, massa màquines amb alt temps d'activitat o accions d'encesa/apagada fallides), s'envia un POST HTTP amb la informació d'alerta que la vostra eina d'automatització pot processar.

Alertes d'hipervisor i estat de l'emmagatzematge subjacent

Cal no oblidar que, moltes vegades, els problemes de disc vénen de la capa d'hipervisor , no del sistema operatiu convidat. Citrix Hypervisor i VMware vSphere permeten definir llindars per a:

• Ús de CPU, memòria i xarxa del host.
• Ús de disc a nivell de datastore (en el cas de vSphere).
• Estat de connexió de l'amfitrió o clúster d'hipervisor.

Quan aquests llindars se superen, l'hipervisor genera alertes que es poden visualitzar a la consola de Supervisar dins de la categoria “Estat de l'hipervisor”. És important tenir clar que:

• Els llindars es configuren a la consola de l'hipervisor, no a la de Supervisar.
• Les alertes antigues (més d'un dia) es descarten automàticament a la capa de monitoratge.
• Descartar una alerta a Supervisar no la descarta necessàriament a la consola de l'hipervisor, i viceversa.

Si els vostres scripts de PowerShell detecten problemes d'I/O inusuals a les màquines virtuals , convé revisar simultàniament aquestes alertes de l'hipervisor, perquè potser el coll d'ampolla està en un datastore saturat, un host al límit o una fallada de connectivitat amb el backend d'emmagatzematge (per exemple, revisar diferències entre VMC ).

Bones pràctiques per evitar colls d'ampolla de disc

Més enllà de mesurar i alertar, és essencial aplicar una sèrie de bones pràctiques de disseny i operació per reduir la probabilitat de trobar-te amb un coll d'ampolla de disc greu.

Disseny i manteniment d'espais d'emmagatzematge (S2D)

En entorns amb S2D, procura que els pools d'emmagatzematge usin discos homogenis quant a tipus de medi, capacitat i rendiment. Evita barrejar SSD i HDD al mateix pool si no implementes adequadament l'emmagatzematge en capes, i revisa:

• Que el tipus de resiliència (simple, mirall, paritat) sigui l'apropiat per a la càrrega de feina.
• Que el microprogramari i els controladors de totes les unitats estiguin actualitzats.
• Que les tasques de manteniment demmagatzematge (reparacions, neteges) es programin en períodes de baixa activitat.

Regularment, executa tasques com Optimize-StoragePool per equilibrar el pool i, si uses HDD, desfragmenta quan sigui procedent. Sempre que feu canvis d'aquest tipus, val la pena tornar a mesurar el rendiment per comparar amb la línia base anterior.

Supervisió contínua i línies base de rendiment

No té gaire sentit generar alertes sense tenir clar què es considera “normal” al teu entorn. Per això és tan important establir línies base de rendiment mesurant durant un temps raonable:

• Latències mitjanes de lectura/escriptura.
• Longitud de cua típica sota càrrega normal.
• Rang habitual de I/O per procés per a serveis crítics.

Amb aquestes dades a la mà podràs ajustar llindars realistes , tant als teus scripts de PowerShell com a directives d'alerta (Citrix, hipervisor, monitorització corporativa) evitant el clàssic problema d'“alerta per tot” que acaba en fatiga i pèrdua de confiança en el sistema.

La combinació de mesurament precisa d'I/O per procés, configuració assenyada d'alertes natives, automatització amb PowerShell i ús coordinat de plataformes com Citrix Monitor i les alertes de l'hipervisor us permet detectar ràpidament els problemes de disc, reaccionar abans que impactin en el negoci i, de passada, optimitzar costos apagant recursos o ajustant temps d'activitat. Amb una bona estratègia de scripting i monitorització, fins i tot entorns amb milers de servidors i solucions demmagatzematge complexes (S2D, clústers dhipervisors, VDAs de sessió múltiple) es tornen molt més manejables.