Server web e applicativi
    Aggiornato il maggio 2026
    IIS logo

    IIS Monitoraggio

    Monitora in tempo reale lo stato del pool di applicazioni IIS, le code delle richieste, i processi di lavoro e le metriche di risposta senza alcuna configurazione.

    Perché monitorare IIS?

    Internet Information Services (IIS) è il server web di Microsoft che supporta le applicazioni .NET aziendali e i siti web. Il monitoraggio di IIS è fondamentale per tenere sotto controllo il riciclaggio dei pool di applicazioni, la profondità della coda delle richieste e lo stato di salute dei processi di lavoro, nonché per garantire prestazioni ottimali alle applicazioni web ospitate su Windows.

    Rilevamento automatico tramite Xitogent su Windows Server
    Rilevamento di salute e recycle degli application pool
    Profondità della coda richieste e tempi di elaborazione
    Monitoraggio CPU e memoria dei processi worker
    Monitoraggio del tasso di errori HTTP
    Metriche delle connessioni SSL/TLS
    Supporto nativo per Windows Server
    Intervalli di raccolta metriche di 1 minuto
    Intervalli di raccolta metriche di 1 minuto preimpostati
    Conservazione storica dei dati per la pianificazione della capacità e l'analisi post-incidente
    Che cos'è il monitoraggio di IIS?

    Monitoraggio di IIS, in breve

    Il monitoraggio di IIS intercetta le tempeste di recycling degli application pool, l'accumulo nella request queue di HTTP.SYS e i 503 prima che raggiungano i suoi utenti, inclusi i recycle inattesi che sembrano sempre verificarsi alle 3 del mattino. Per i carichi ASP.NET su Windows Server, la visibilità per singolo pool fa la differenza tra il debug di una voce di una sola riga nel registro eventi e il triage di un'interruzione opaca. Xitoring funziona come agente nativo Windows, legge gli stessi contatori di Performance Monitor e instrada gli avvisi verso la sua rotazione on-call esistente.

    Indicatori

    Ciò che monitoriamo

    Richieste correnti

    Numero di richieste in fase di elaborazione.

    Lunghezza della coda di richieste

    Richieste in attesa di elaborazione.

    Stato degli application pool

    Stato di salute di ogni application pool.

    CPU dei processi worker

    Utilizzo CPU per processo worker IIS.

    Errori HTTP/sec

    Tasso di errori HTTP 4xx e 5xx.

    Byte inviati/ricevuti

    Throughput di rete di IIS.

    Connessioni attive

    Connessioni client attualmente attive.

    Rapporto di cache hit

    Efficacia della cache di output di IIS.

    Richieste ASP.NET in coda

    Richieste in attesa sulla coda managed dei worker ASP.NET (separata da HTTP.SYS). Valori elevati indicano starvation del thread pool nei carichi CLR-bound.

    .NET CLR % Time in GC

    Percentuale di CPU spesa in garbage collection per worker. Sopra il 5–10% significa che la pressione del GC sta determinando la latenza: la tracci insieme ai conteggi di Gen 0/1/2.

    w3wp.exe CPU / Working Set

    Utilizzo CPU e memoria residente per worker dalla categoria PerfMon `Process`. Etichettati per application pool, così vede quale carico sta consumando cosa.

    HTTP 4xx / 5xx al secondo

    Tasso di errore per sito. Un picco di 5xx con tasso di richieste stabile indica fallimenti dell'application pool o di dipendenze backend, non traffico.

    Notifiche e avvisi

    Configurabile condizioni di attivazione

    Imposta dei trigger personalizzati nella tua dashboard per ricevere una notifica non appena le metriche dell{name}e superano le soglie da te definite.

    IIS pannello di controllo per la configurazione dei trigger di monitoraggio

    Coda di richieste

    critico

    Si attiva quando la profondità della coda supera la soglia, indicando un collo di bottiglia di elaborazione.

    Recycle del pool di applicazioni

    avviso

    Avvisa quando un application pool si ricicla in modo inatteso.

    Tasso di errori HTTP

    avviso

    Si attiva quando il tasso di errori sale rapidamente.

    CPU dei processi worker

    critico

    Si attiva su un elevato utilizzo CPU nei processi worker.

    Connessioni attive

    avviso

    Avvisa quando le connessioni si avvicinano ai limiti del server.

    01

    Importanza del monitoraggio IIS

    IIS esegue applicazioni .NET mission-critical e intranet aziendali. Senza monitoraggio, crash degli application pool, accumulo in coda e memory leak possono causare interruzioni.

    • Rileva crash dei pool di applicazioni prima che impattino sugli utenti
    • Monitora le code di richieste per prevenire timeout
    • Tieni traccia della memoria dei processi worker per prevenire memory leak
    • Identifica in anticipo i picchi di errori HTTP
    Dashboard di monitoraggio IIS
    Analisi dei processi worker IIS
    02

    Perché scegliere Xitoring

    Supporto nativo per Windows Server con installazione semplice e monitoraggio di livello enterprise.

    • Installer Windows nativo
    • Oltre 15 nodi di monitoraggio globali
    • Dashboard unificata per tutti i servizi
    • Alerting multicanale
    • Conservazione dei dati storici
    Panoramica IIS Xitoring
    Configurazione degli avvisi
    Casi d'uso

    Scenari comuni di monitoraggio di IIS

    Dove IIS viene tipicamente eseguito oggi — e cosa potrebbe andare storto se nessuno lo monitora.

    App aziendali .NET consolidate

    Le app .NET a lunga esecuzione tendono a sviluppare lente perdite di memoria che emergono solo nei momenti peggiori — riavvii notturni, rallentamenti misteriosi, incidenti nel fine settimana. Tracciamo i primi segnali in modo che il team possa risolvere la causa principale secondo il proprio programma, non quello dell'app.

    App .NET moderne in produzione

    Le app .NET più recenti eseguono più codice direttamente all'interno del server web, il che significa che un problema dell'app può bloccare l'intero sito più velocemente. Monitoriamo l'app e il server web come un'unica unità in modo che i problemi vengano isolati immediatamente al livello corretto.

    Porta d'accesso per SharePoint, Exchange o siti interni

    Quando IIS è il gateway per app aziendali come SharePoint o Exchange, un'interruzione blocca l'intera azienda. Rileviamo i segni di un gateway sovraccarico o di un backend in fallimento in modo che il team possa intervenire prima che il personale inizi a presentare ticket.

    Prima di iniziare

    Prerequisiti per IIS

    Assicurati di avere tutto questo in posizione — la maggior parte delle installazioni dura 60 secondi una volta soddisfatte le condizioni.

    • Windows Server 2016 o successivo con il ruolo IIS installato
    • Contatori delle prestazioni IIS abilitati (categoria Web Service)
    • Accesso Amministratore per installare l'agente Windows di Xitogent
    Guida all'installazione

    Inizia con verbali

    1

    Installa Xitogent sul tuo host IIS

    Esegui l'installer Windows di Xitogent sul server IIS. L'MSI registra Xitogent come servizio Windows con il permesso di leggere i Performance Counter di IIS.

    # Download from https://xitoring.com/install.exe # Run the installer as Administrator
    2

    Verifica i Performance Counter di IIS

    IIS espone metriche attraverso i Windows Performance Counter. Conferma che la classe di counter Web Service sia presente eseguendo `Get-WmiObject Win32_PerfFormattedData_W3SVC_WebService -filter "Name='_Total'"` in PowerShell. Se la classe non c'è, esegui `install-windowsfeature web-common-http`.

    xitogent integrate
    3

    Abilita l'integrazione IIS

    Usa la dashboard di Xitoring o la CLI per abilitare l'integrazione IIS. Xitogent enumera automaticamente ogni application pool e sito, quindi le metriche per pool sono disponibili senza ulteriore configurazione.

    4

    Configura le soglie di allerta (opzionale)

    Imposta soglie personalizzate per Request Queue Length, App Pool Recycling o HTTP Error Rate per intercettare problemi di capacità e stabilità per pool.

    5

    Verifica che funzioni

    Esegui questo comando sul server per confermare che Xitogent ha rilevato l'integrazione. In circa 30 secondi nuove metriche cominceranno a comparire sulla tua dashboard.

    sudo xitogent status

    Spesso domande poste

    Questo supporto è compatibile con IIS su Windows Server Core?
    Sì, Xitogent funziona sia con le installazioni complete che con quelle Core.
    Posso monitorare più siti?
    Sì, i dati vengono raccolti per sito e per pool di applicazioni.
    Quali versioni di IIS sono supportate?
    IIS 8.5+ (Windows Server 2012 R2 e versioni successive).
    Qual è la differenza tra pipeline classica e integrata di IIS?
    La pipeline integrata (predefinita da IIS 7) instrada ogni richiesta attraverso la pipeline unificata IIS + ASP.NET: un unico set di moduli HTTP gestisce autenticazione, logging ed elaborazione delle richieste sia per contenuti statici sia managed. La pipeline classica esegue ASP.NET come estensione ISAPI dietro la pipeline IIS legacy (due percorsi di richiesta separati). La modalità classica è deprecata e più lenta; le nuove app dovrebbero usare Integrated. Xitogent monitora entrambe, ma Integrated espone più contatori della pipeline managed.
    Come monitoro la request queue di HTTP.SYS?
    La categoria PerfMon `HTTP Service Request Queues` espone `ArrivalRate` (tasso di richieste in arrivo a livello kernel), `CurrentQueueSize` (richieste in attesa di un worker) e `RejectedRequests` (richieste scartate perché si è raggiunto il limite della coda). Un tasso di RejectedRequests diverso da zero è il singolo miglior indicatore anticipatore di 503 HTTP. Imposti avvisi lì e su `CurrentQueueSize > MaxQueueLength × 0.8`.
    Come monitoro le app ASP.NET Core ospitate su IIS?
    ASP.NET Core usa l'ASP.NET Core Module (ANCM). L'hosting in-process (default dalla 2.2) esegue Kestrel all'interno di `w3wp.exe`: lo monitori come qualunque altro application pool, più il provider `IISHttpServer` per le metriche specifiche di ANCM. L'hosting out-of-process esegue Kestrel separatamente e fa proxy tramite IIS: tracci sia il proxy `w3wp.exe` sia il processo Kestrel backend.
    Cosa causa l'HTTP 503 Service Unavailable in IIS?
    Tre cause principali: (1) l'application pool si è fermato o ha avuto un crash (spesso scatenato da Rapid-Fail Protection), (2) HTTP.SYS ha rifiutato le richieste perché la coda ha superato `MaxQueueLength`, (3) il worker process è in fase di recycling e non ancora pronto. Ognuna mostra un segnale diverso: stato del pool, contatore RejectedRequests o evento di recycle. Xitogent evidenzia tutte e tre, così il triage richiede minuti, non ore.
    Posso monitorare IIS su Windows Server Core?
    Sì. Xitogent funziona in modo identico su Windows Server Core e su installazioni Server complete: legge i performance counter tramite la stessa API. Server Core è in realtà il deployment consigliato per i carichi IIS in produzione, perché riduce la superficie di attacco e gli aggiornamenti del SO che scatenano recycle.
    Con quale frequenza vengono raccolte le metriche?
    Ogni 60 secondi di default, con polling sub-minuto disponibile per la risposta agli incidenti. Gli eventi di recycle per singolo pool vengono catturati nel momento esatto in cui si verificano tramite le sottoscrizioni agli eventi di Windows (senza ritardo di polling), quindi la causa principale di un 503 è visibile immediatamente, non al successivo intervallo di campionamento.

    Inizia a monitorare IIS oggi

    Configurazione in meno di 60 secondi. Non è richiesta alcuna carta di credito. Statistiche complete fin dal primo giorno.

    Inizia la prova gratuita

    Continua a esplorare

    Correlati Integrazioni