Monitoraggio con gli strumenti di Windows Server e Azure Monitor

Il dominio «Monitor and troubleshoot Windows Server environments» non chiede di elencare strumenti: chiede di scegliere lo strumento giusto per la domanda giusta, e di sapere dove ciascuno si ferma. Perfmon vede i contatori ma non il kernel; Server Manager aggrega eventi ma su una finestra corta; Azure Monitor raccoglie tutto ma solo ciò che una data collection rule gli ha detto di raccogliere. Le domande d’esame vivono quasi tutte su questi confini.

Performance Monitor: il contatore dice dove NON guardare

Il caso classico è un file server con \Processor(_Total)\% Processor Time sopra il 90% per ore, mentre né Task Manager né l’oggetto Process mostrano un processo che consumi in modo significativo. Non è un mistero: è la firma del tempo speso in kernel mode, che l’oggetto Process — che misura i processi in user mode — non attribuisce a nessuno.

La scomposizione si fa con i contatori dell’oggetto Processor:

Se % User Time resta basso e % Privileged Time, % Interrupt Time o % DPC Time salgono, il sospettato è un driver (rete, storage, antivirus filter driver), non un’applicazione. Microsoft è esplicita su un limite: Performance Monitor non ha accesso al kernel e non ne registra le informazioni, quindi identifica il tipo di consumo, non la funzione colpevole; per arrivare al modulo servono strumenti di tracing come TSS o Windows Performance Analyzer.

Perfmon si guida anche da riga di comando, cosa utile quando il problema è sporadico e serve un log lungo:

logman create counter CORE_%computername% -f bin -v mmddhhmm -max 2048 -c "\Processor(*)\*" "\Process(*)\*" "\Memory\*" "\System\*" -si 00:00:01
logman start CORE_%computername%
logman stop CORE_%computername%

-f bin produce un .blg, -max 2048 limita il file a 2 GB, -si è l’intervallo di campionamento. I log finiscono sotto C:\PerfLogs. La stessa sintassi con contatori nella forma \\NOMESERVER\Processor(*)\* raccoglie da remoto.

Data collector set: pianificato non vuol dire eseguito

Un DCS user-defined si crea sotto Performance > Data Collector Sets > User Defined e può avere una schedule propria. Esiste però un difetto noto che l’esame ama: su Windows 10/Windows Server dalla 1703 fino alla 1909 il task che Windows crea automaticamente in Task Scheduler Library > Microsoft > Windows > PLA viene generato con un’azione Custom Handler invece di Start a program. Risultato: Task Scheduler riporta l’esecuzione come riuscita, ma nessun file .blg viene scritto, perché il task non fa nulla.

Il problema è corretto nella versione 2004 e successive. Il workaround sulle versioni affette è chirurgico: nelle proprietà del task, scheda Actions, si elimina il Custom Handler e si crea una nuova azione con programma C:\windows\system32\rundll32.exe e argomenti C:\windows\system32\pla.dll,PlaHost "{Name}" "$(Arg0)", dove {Name} è il nome del data collector set.

Nota la diagnosi: «Task Scheduler dice OK ma il file non c’è» non significa permessi, disco o stop condition — significa guardare l’azione del task.

System Insights: previsione più azione automatica

System Insights è il motore predittivo locale di Windows Server. Quattro capability di default — CPU capacity forecasting, Networking capacity forecasting, Total storage consumption forecasting, Volume consumption forecasting — girano sulla macchina, per impostazione predefinita ogni giorno alle 3:00, e analizzano dati giornalieri per cogliere tendenze di lungo periodo, non picchi.

Gli stati sono cinque e hanno una semantica precisa: Ok (la previsione non supera la capacità), Warning (la supera nei prossimi 30 giorni), Critical (nei prossimi 7 giorni), Error (errore imprevisto), None (dati insufficienti). Con 0-5 giorni di dati non viene fatta alcuna previsione; il modello autoregressivo richiede tre settimane di dati e fino ad allora usa un trend lineare di base.

Il punto che l’esame sfrutta è la remediation automatica. Non serve un alert esterno: per ogni capability e per ogni stato si associa uno script PowerShell.

Get-InsightsCapability
Invoke-InsightsCapability -Name "Volume consumption forecasting"
Get-InsightsCapabilityResult -Name "Volume consumption forecasting" -History

$Cred = Get-Credential
Set-InsightsCapabilityAction -Name "Volume consumption forecasting" -Type Critical `
  -Action "C:\Scripts\ExtendVolume.ps1" -ActionCredential $Cred

Set-InsightsCapabilityAction vuole -Type (lo stato che scatena l’azione) e -ActionCredential (le credenziali con cui lo script gira). Si rimuove con Remove-InsightsCapabilityAction. Le schedule si governano con Set-InsightsCapabilitySchedule, Enable-InsightsCapabilitySchedule e Disable-InsightsCapabilitySchedule; le capability si accendono e spengono con Enable-InsightsCapability / Disable-InsightsCapability.

Per aggregare più macchine, System Insights scrive un evento per ogni previsione nel canale Microsoft-Windows-System-Insights/Admin, con un ID per stato: 151 Ok, 148 Warning, 150 Critical, 149 Error, 132 None. Sono questi gli eventi da raccogliere in Azure Monitor se vuoi una vista di flotta.

Server Manager e Windows Admin Center: due console, due limiti

In Server Manager la dashboard mostra le thumbnail; cliccando la riga Events si apre Events detail View, che filtra gli alert evidenziati. Due vincoli che le domande usano come trappola:

• gli eventi evidenziati sono un sottoinsieme di quelli raccolti. Allargare i criteri nel detail View non cambia la raccolta: quella si configura in Configure Event Data nel tile Events (default: severità Critical, Error, Warning; log Application, Setup, System; età 24 ore);
• il campo time period del detail View accetta al massimo 1440 minuti, 24 ore, 1 giorno. Non esiste modo di farci vedere la settimana scorsa.

Terza trappola: in Server Manager i performance counter sono disattivati per impostazione predefinita, e i server appaiono come «online - Performance counters not started» finché non si sceglie Start Performance Counters. La soglia di alert CPU predefinita è 85%, la memoria disponibile 2 MB.

Windows Admin Center copre lo stesso terreno con estensioni per server: Performance Monitor, Events, System Insights (dove le capability si abilitano, si invocano e si configurano con schedule e azioni dalle schede Settings > Schedule e Settings > Actions). WAC però non è un sistema di alerting autonomo: per notifiche e regole si passa dall’integrazione con Azure Monitor, quindi da Azure Arc, agente e DCR.

Data collection rule: raccogliere solo ciò che serve

Su macchine Azure Arc-enabled con Azure Monitor Agent installato, la raccolta si definisce in una data collection rule e si attiva associando la DCR alle macchine (DCRA). L’associazione è molti-a-molti: una DCR su più risorse, e fino a 30 DCR su una singola risorsa.

Per «solo gli eventi 4625 dal log Security» la configurazione Basic non basta: filtra per log e severità, non per Event ID. Serve Custom con una query XPath, nella forma LogName!XPathQuery:

Security!*[System[(EventID=4625)]]

Si valida in locale prima di metterla nella DCR:

Get-WinEvent -LogName 'Security' -FilterXPath '*[System[(EventID=4625)]]'

Attenzione ai limiti: Get-WinEvent regge fino a 23 espressioni, le DCR ne supportano 20; XPath 1.0 non offre starts-with né contains; i canali Analytic e Debug non sono sottoscrivibili e quindi non si raccolgono.

Destinazione: i Windows event possono andare solo in un Log Analytics workspace, dove finiscono nella tabella Event — anche quelli del log Security. Finiscono in SecurityEvent solo se si usa il connettore «Windows Security Events via AMA» di Microsoft Sentinel. Più workspace come destinazione significano dati duplicati e costo doppio.

Alert sui dati raccolti

Con gli eventi nella tabella Event, la notifica si costruisce con una log search alert rule: una query KQL che restituisce le righe da contare, una finestra, una frequenza di valutazione e un action group con l’azione Email.

Event
| where EventLog == "Security" and EventID == 4625
| summarize FailedLogons = count() by Computer, bin(TimeGenerated, 1h)
| where FailedLogons > 10

La regola raggruppata per Computer produce un alert per macchina (dimension splitting), che è ciò che serve quando la condizione è «più di 10 eventi per lo stesso computer». Per soglie su metriche di piattaforma si usa invece una metric alert rule, più economica e a bassa latenza; per il guest bisogna prima che le metriche esistano.

VM Insights: due esperienze, non una

Abilitando l’enhanced monitoring su una VM Azure si sceglie tra due esperienze, e nel portale l’OpenTelemetry metrics è attivo per impostazione predefinita.

Chi accetta il default e poi chiede la vista Performance multi-VM di VM insights (Monitor > Virtual Machines > Performance, con Top N Charts, elenco fino a 500 macchine, intervallo storico fino a 30 giorni) non la trova: quella esperienza è logs-based e va abilitata in aggiunta. Servono inoltre i permessi Monitoring Reader sia sulle VM sia sulla DCR di VM Insights.

Da sapere per il presente: la funzionalità Map di VM insights e il Dependency Agent sono deprecati, con ritiro annunciato al 30 giugno 2028. La dipendenza fra processi non è più la risposta giusta a una domanda di progettazione.

Trappole tipiche d’esame

• CPU alta senza processo colpevole. La risposta non è «riavvia» né «apri un caso»: è aggiungere % Privileged Time, % Interrupt Time e % DPC Time dell’oggetto Processor. L’oggetto Process non può mostrarti il tempo kernel, e Perfmon non vede dentro il kernel: serve un tracing di livello superiore per arrivare al driver.
• Task Scheduler «riuscito» ma nessun log. Sulle build 1703-1909 il task PLA nasce con azione Custom Handler. Si sostituisce con rundll32.exe + pla.dll,PlaHost. Risolto in 2004 e successive: se la domanda cita Windows Server 2022, la causa è un’altra.
• System Insights Critical → script automatico. La risposta è Set-InsightsCapabilityAction -Type Critical -Action ... -ActionCredential ..., non una scheduled task e non un alert di Azure Monitor. Ricorda che Critical significa «capacità superata entro 7 giorni», Warning «entro 30».
• Server Manager Events detail View. Allargare severità ed Event ID lì dentro non allarga la raccolta: quella sta in Configure Event Data. E il periodo massimo resta 24 ore / 1440 minuti, quindi non aspettarti eventi di tre giorni fa.
• Solo l’ID 4625 dal Security log. Il filtro Basic della DCR non arriva all’Event ID: serve Custom con Security!*[System[(EventID=4625)]]. E gli eventi atterrano nella tabella Event, non in SecurityEvent — a meno che non ci sia di mezzo il connettore Sentinel via AMA.
• VM insights Performance multi-VM assente. Non è un bug di permessi: è il default OpenTelemetry-only. Le viste Top N e Aggregated Charts richiedono l’esperienza logs-based con InsightsMetrics in un Log Analytics workspace.