Risoluzione dei problemi di prestazioni di IIS o di errori dell'applicazione mediante Log Parser

di Benjamin Perkins

Strumenti e conoscenze usati in questo strumento di risoluzione dei problemi

Panoramica

Questo strumento di risoluzione dei problemi consente di analizzare i file di log iis per determinare la causa in cui un'applicazione ospitata in IIS ha esito negativo o riscontra problemi di prestazioni. Prima di iniziare, è importante notare che tutti i campi iis possono registrare non sono abilitati per impostazione predefinita. Ad esempio, i byte inviati e i byte ricevuti non sono selezionati, ma sono molto utili per la risoluzione di un problema di prestazioni. Pertanto, il momento migliore per includere questi campi aggiuntivi è prima di riscontrare problemi di sistema. Pertanto, se non è già stato fatto, selezionare questi campi aggiuntivi, consentono di trovare soluzioni in caso di problemi.

Il blog seguente illustra come eseguire questa operazione in IIS 7+:

Modifica dei dati di log iis 7 in Windows 2008

Scenario

L'amministratore di sistemi inizia a sentire i report degli utenti del sistema ospitato in IIS che la risposta è lenta. C'è qualche menzione che i Web browser semplicemente timeout o smettere di rispondere completamente quando accedono al tuo sito Web.

Si passa all'azione e si ricicla il processo di lavoro; tutto sembra funzionare di nuovo, come di consueto.

Tuttavia, non è possibile accettarlo come soluzione ed è necessario sapere perché questo è accaduto, ma non sapere dove iniziare. Non sono presenti dettagli degli utenti, ad esempio codici di errore, schermate e peggio, non sono disponibili dati sulle prestazioni per confrontare ciò che è successo alle normali prestazioni. In molti casi, altri nuovi problemi ti allontanano da qualsiasi grave analisi della causa radice.

LogParser di Microsoft è un ottimo strumento che è facile e veloce da usare. In molte situazioni, lo strumento consente di ottenere rapidamente una comprensione più approfondita di ciò che è accaduto nel server e può aiutare a identificare i problemi. È possibile raccogliere le informazioni raccolte con LogParser e passarle al team di database, al team di rete o agli sviluppatori per ulteriori analisi.

Raccolta di dati

Per impostazione predefinita, i file di log IIS si trovano nelle directory seguenti:

  • IIS 7 e versioni successive: %SystemDrive%\inetpub\logs\LogFiles
  • IIS 6 e versioni precedenti: %WinDir%\System32\LogFiles

In questo strumento di risoluzione dei problemi si usa IIS 8. Aprire Gestione IIS e selezionare Siti, come illustrato nella figura 1. Verrà visualizzato l'ID di ogni sito Web ospitato nel server. Questo ID sarà necessario per determinare la directory W3SVC* da analizzare.

Screenshot della finestra I S Manager che mostra Siti nel riquadro principale.
Figura 1: Ottenere l'ID del sito Web

Aprire Esplora risorse e passare alla directory contenente i file di log IIS del sito Web che hanno riscontrato il problema di prestazioni. Nella figura 2 viene illustrato l'aspetto che potrebbe essere simile al seguente.

Screenshot di Esplora risorse che mostra i percorsi dei file.
Figura 2: Percorso del file di log IIS

I file di log IIS possono essere piuttosto grandi; Nella figura 2, ad esempio, il file di log u_ex12101858.log è di dimensioni quasi 100 MB. Poiché questi file di log possono essere enormi e contengono centinaia di migliaia di singole voci di file di log, la ricerca manuale di ognuno di questi file per un errore non è un buon approccio e restituisce pochi risultati per il tempo che si investe.

Questo è quando LogParser diventa uno strumento indispensabile nell'arsenale di risoluzione dei problemi.

Analisi dei dati

Il primo passaggio consiste nel determinare quali file di log possono contenere errori. Ad esempio, se i clienti si lamentavano delle prestazioni il 3 giugno 2012, il file di log potrebbe essere u_ex120603.log, dove:

  • "12" è l'anno abbreviato per il 2012
  • "06" si riferisce al sesto mese (giugno)
  • "03" è il terzo giorno del mese

Nota: nell'esempio precedente si presuppone che la registrazione IIS sia configurata per ruotare i file di log su base giornaliera, ovvero l'impostazione predefinita. Se sono state modificate le impostazioni di IIS per ruotare i file di log in base a un intervallo di tempo diverso, ad esempio settimanale o oraria, i nomi dei file di log saranno diversi. Per altre informazioni sulla sintassi per i nomi dei file di log IIS, vedere l'articolo Sintassi di denominazione dei file di log iis (https://support.microsoft.com/kb/242898).

Nota

Per impostazione predefinita, la data e l'ora nei log IIS vengono archiviate tramite GMT; È necessario tenere conto di questo problema quando si determinano i log contenenti errori. Detto questo, è possibile modificare le date/ore usando la funzione di TO_LOCALTIME() LogParser, come illustrato nell'esempio seguente:

Nota

logparser.exe "SELECT TO_STRING(TO_LOCALTIME(TO_TIMESTAMP(date,time)),'yyyy-MM-dd hh:mm:ss') AS LocalTime,
COUNT(*) AS Hits FROM *.log WHERE date='2012-10-18'
GROUP BY LocalTime ORDER BY LocalTime" -i:w3c

Dopo aver identificato i file di log IIS che contengono errori, è necessario copiarli in un percorso in cui è possibile analizzarli. Questo passaggio è facoltativo, ma non è consigliabile analizzare i log nel server IIS perché l'esecuzione delle query LogParser potrebbe richiedere molto tempo e, se i file di log sono di grandi dimensioni, Il parser di log potrebbe competere per le risorse di sistema.

Ad esempio, è possibile copiare i log di IIS in una cartella nel computer personale in cui sono già stati copiati i file LogParser, che è il modo in cui i file di log vengono in genere analizzati. Nella figura 3 viene illustrato un esempio di posizione in cui sono stati archiviati per creare questo articolo.

Screenshot di Esplora risorse che mostra il percorso dell'eseguibile del parser di log.Figura 3: File di log IIS ospitati localmente per l'analisi tramite LogParser

Dopo aver scaricato LogParser, si è pronti per iniziare l'analisi. La prima query eseguita è illustrata nella figura 4. I risultati offrono una panoramica del modo in cui IIS risponde alle richieste.

logparser.exe "SELECT sc-status, sc-substatus, COUNT(*) FROM *.log GROUP BY sc-status, sc-substatus ORDER BY sc-status" -i:w3c
    
    sc-status sc-substatus COUNT(ALL *)
    --------- ------------ ------------
    200       0            3920658
    206       0            2096
    301       0            1031
    302       0            65386
    304       0            178705
    400       0            35
    401       2            692096
    404       0            2935
    404       11           7
    405       0            1
    406       0            36
    500       0            11418
    
    Statistics:
    -----------
    Elements processed: 4189228
    Elements output:    12
    Execution time:     7.70 seconds

Figura 4: Query LogParser (sc-status e sc-substatus)

I punti di interesse all'interno dei risultati sono:

  • Rapporto tra 200 e 304 codici di stato HTTP (richieste riuscite)
  • Numero di 500 codici di stato HTTP (richieste non riuscite)

Di seguito viene illustrato il significato di ognuno di questi codici di stato.

Rapporto tra i codici di stato HTTP 200 e 304 (analisi delle richieste riuscite)

Il rapporto tra i codici di stato HTTP 200 e 304 è importante perché mostra il numero di richieste recuperate dalla cache dei client anziché direttamente dal server. I risultati nella figura 4 mostrano che sono presenti 3.920.658 richieste che hanno generato un codice di stato HTTP pari a 200. Ciò significa che il file richiesto è stato servito dal server ogni volta. Al contrario, ci sono state 178.705 richieste che hanno generato un codice di stato HTTP 304. Ciò significa che il file richiesto è stato recuperato dalla cache locale. In altre parole, il 95,5% delle richieste viene gestito dal server.

La memorizzazione nella cache può avere un impatto molto positivo sulle prestazioni del sistema; vedere i dettagli per la compressione statica e dinamica nell'articolo Configurazione della compressione HTTP in IIS 7 .

Codici di stato HTTP 500 (analisi delle richieste non riuscite)

I codici di stato HTTP 500 possono indicare problemi gravi nel sistema. Il livello di impatto che la causa radice di un errore HTTP 500 può avere nel sistema può variare da nulla all'arresto anomalo di un processo di lavoro. Pertanto, quando vengono visualizzate, è necessario eseguire la query illustrata nella figura 5 per individuare le richieste che hanno generato un codice di stato HTTP 500.

logparser.exe "SELECT cs-uri-stem, COUNT(*) FROM *.log WHERE sc-status=500 GROUP BY cs-uri-stem ORDER BY COUNT(*) DESC" -i:w3c
    
    cs-uri-stem                 COUNT(ALL *)
    --------------------------- ------------
    /ShoppingCart/ViewCart.aspx 1378
    /DataService.asmx           1377  
    /Start/default.aspx         949
    /GetDetailsView.aspx        753
    /Details/ImageUrls.asmx     722
    
    Statistics:
    -----------
    Elements processed: 4189228
    Elements output:    5
    Execution time:     24.89 seconds

Figura 5: Query LogParser (cs-uri-stem con 500 sc-status)

Questi risultati mostrano il percorso e il nome del file che, quando richiesto, ha risposto con un codice di stato HTTP 500. Questo tipo di informazioni sarebbe utile per il team di sviluppo. Ad esempio, il team di sviluppo potrebbe esaminare ulteriormente il codice specifico e cercare il codice che viene eseguito senza essere contenuto in un try {...} catch {...} blocco di codice o che eseguono query di dati di grandi dimensioni che devono essere ottimizzate.

Si esamini ora questo esempio in modo più approfondito e si esaminino i principali collaboratori per i codici di stato HTTP 500. Sarebbe interessante sapere quando si sono verificati questi errori, perché queste informazioni possono essere usate per controllare se le dipendenze presentano problemi contemporaneamente.

logparser.exe "SELECT TO_STRING(TO_TIMESTAMP(date,time),'yyyy-MM-dd hh') AS Hour,
COUNT(*) FROM *.log WHERE sc-status=500 AND cs-uri-stem='/Start/default.aspx' AND date='2012-10-18' GROUP BY Hour ORDER BY Hour" -i:w3c
    
    Hour          COUNT(ALL *)
    ------------- ------------
    2012-10-18 08 191
    2012-10-18 09 163
    2012-10-18 14 150
    
    Statistics:
    -----------
    Elements processed: 4189228
    Elements output:    3
    Execution time:     6.36 seconds

Figura 6: Query LogParser (cs-uri-stem con 500 sc-status)

Il subset dei risultati nella figura 6 limita l'intervallo di date del problema. Queste informazioni possono essere passate alla rete, al database, agli amministratori del sistema operativo e ai team di sviluppo per verificare se si è verificato un altro problema contemporaneamente. Ad esempio: sono stati riscontrati problemi aggiuntivi tra le 08:00 e le 09:59:59 GMT e tra le 14:00:00 e le 14:59:59 GMT?

Il set successivo di query LogParser usa i campi seguenti, che possono fornire informazioni più dettagliate sui problemi di prestazioni:

Campo Descrizione Abilitato per impostazione predefinita
tempo impiegato Durata dell'esecuzione dell'azione, in millisecondi Sì
sc-bytes Numero di byte inviati dal server No
cs-bytes Numero di byte ricevuti dal server No

Come accennato in precedenza, richiedere ora i campi sc-bytes e cs-bytes essere abilitati o, se possibile, abilitarli manualmente. Forniscono informazioni preziose sul sistema e sul suo comportamento. Prendere la figura 7, ad esempio. Si noterà che il tempo medio è abbastanza buono a poche centinaia di millisecondi. Tuttavia, esaminare il tempo massimo impiegato, che è troppo tempo.

logparser.exe "SELECT  cs-method, COUNT(*) AS TotalCount, MAX(time-taken) AS MaximumTime, AVG(time-taken) AS AverageTime FROM *.log GROUP BY cs-method ORDER BY TotalCount DESC" -i:w3c
    
    cs-method TotalCount MaximumTime AverageTime
    --------- ---------- ----------- -----------
    GET       3172034    1366976     153
    POST      1011765    256539      359  
    HEAD      5363       26750       209  
    
    Statistics:
    -----------
    Elements processed: 4189228
    Elements output:    3
    Execution time:     6.36 seconds

Figura 7: Query LogParser ( tempo impiegato da MAX e AVG)

So che lei sta chiedendo se stessi già la prossima domanda che deve essere risposta. Quale richiesta richiede tanto tempo? La figura 8 mostra la risposta a tale domanda. Come si noterà, sono andato avanti e ho incluso il campo sc-bytes nella query LogParser. Tenere presente che sc-bytes rappresenta le dimensioni del file inviato dal server al client.

logparser.exe "SELECT cs-uri-stem, time-taken, sc-bytes FROM *.log WHERE time-taken > 250000 ORDER BY time-taken DESC" -i:w3c
    
    cs-uri-stem                 time-taken sc-bytes
    --------------------------- ---------- --------
    /ShoppingCart/ViewCart.aspx 1366976    256328
    /DataService.asmx           1265383    53860
    /Start/default.aspx         262796     8077
    /GetDetailsView.aspx        261305     5038
    /Details/ImageUrls.asmx     256539     2351
    
    Statistics:
    -----------
    Elements processed: 4189228
    Elements output:    5
    Execution time:     8.98 seconds

Figura 8: Query LogParser (tempo impiegato da MAX e AVG)

È probabile che tutti concordino che il tempo impiegato per le richieste supera il tempo di risposta "normale". Tuttavia, le dimensioni dei file sono un elemento che l'amministratore o lo sviluppatore deve analizzare per determinare se le dimensioni sono entro un intervallo accettabile.

La conclusione è che il file GetDetailsView.aspx ha generato un numero di 500 codici di stato HTTP e ha impiegato molto tempo per il completamento, anche se si tratta di un file relativamente piccolo. È possibile esaminare la data e l'ora in cui si verificano problemi per questo file ed esaminare il codice nel file con eventuali problemi che si sono verificati. Ad esempio, i log IIS contengono un elenco di variabili passate nella stringa di query. È possibile controllare tali valori per dati non validi.

Gli esempi forniti nelle cifre da 4 a 8 consentono di comprendere dove può esistere la causa radice di un problema. È probabile, tuttavia, che questa analisi abbia reso solo una migliore visione della situazione che porterà ad altre domande e ad analisi più approfondite. In questo caso, è possibile creare una rappresentazione di questi dati in modo più presentabile. La sezione seguente illustra in dettaglio questo aspetto.

Creazione di report

Screenshot di una finestra di comando contenente query LogParser e i relativi risultati possono essere corretti durante la fase di analisi di un problema di prestazioni; tuttavia, se è necessario andare davanti ai manager o ai direttori per spiegare cosa è successo, potrebbe non incontrare il marchio.

Nota

Per ottenere il funzionamento del grafico tramite LogParser, è necessario installare il Office Web Components. Gli articoli seguenti illustrano come eseguire questa operazione:

La figura 9 mostra la query LogParser per creare un grafico a torta 3D contenente il numero di richieste e il codice di stato HTTP associato. Ho rimosso lo stato 200, perché hanno avuto esito positivo. Ciò che mi segue sono le richieste che sono diverse da OK.

logparser.exe "SELECT sc-status AS Status, COUNT(*) AS Count INTO status.gif FROM *.log WHERE sc-status > 200 GROUP BY Status ORDER BY Status" -i:w3c -o:CHART -chartType:PieExploded3D -ChartTitle:"Request Status"
    
    Statistics:
    -----------
    Elements processed: 4189228
    Elements output:    10
    Execution time:     6.20 seconds

Figura 9: Query LogParser (Creare un grafico a torta 3D)

Il risultato della query è illustrato nella figura 10. Esistono diversi parametri aggiuntivi che è possibile passare a LogParser che influiscono sull'immagine. Ad esempio, legenda, groupSize, configurazione e così via... Per ottenere un elenco completo immettere : LogParser -h -o:CHART per un elenco di tutti i parametri. Questo comando fornirà anche un elenco dei diversi tipi di grafico.

Diagramma di un grafico a torta tridimensionale che mostra le allocazioni dello stato della richiesta.
Figura 10: Grafico a torta 3D di LogParser

Un altro grafico utile è il rapporto tra le richieste memorizzate nella cache e le richieste effettive. Si ricordi dalla sezione Analisi dei dati in cui si è discusso che un codice di stato HTTP pari a 200 indica che i file richiesti vengono recuperati dal server, tuttavia, un valore 304 viene recuperato dal client. La figura 11 mostra la query LogParser per la creazione di questo grafico. Si noti che è stato usato il parametro -values .

logparser.exe "SELECT sc-status AS Status, COUNT(*) AS Count INTO cache.gif FROM *.log WHERE sc-status=200 OR sc-status=304 GROUP BY Status ORDER BY Status" -i:w3c -o:CHART -chartType:PieExploded3D -ChartTitle:"Cache" -values:ON
    
    Statistics:
    -----------
    Elements processed: 4189228
    Elements output:    2
    Execution time:     6.35 seconds

Figura 11: Query LogParser (Creare un grafico a torta 3D)

Anche se la differenza tra il codice di stato HTTP 200 e 304 è chiaramente visibile, ho pensato che possa aggiungere un valore per includere il numero di riscontri per ognuno. La figura 12 illustra l'output della query LogParser precedente.

Diagramma di un grafico a torta tridimensionale che mostra l'allocazione della cache.
Figura 12: Grafico a torta 3D di LogParser

Penso che ora si stia ottenendo l'immagine su come creare grafici dei log IIS usando LogParser può aiutare a trasmettere ciò che accade molto meglio di una tabella di dati. Ma prima di smettere, voglio mostrarvi un altro esempio usando il tipo di istogramma. La query LogParser illustrata nella figura 13 produce un istogramma 3D che mostra il conteggio di 500 codici di stato HTTPS all'ora.

logparser.exe "SELECT to_string(to_timestamp(date, time), 'yyyy-MM-dd hh') AS Hour, COUNT(*) AS Count INTO 500.gif FROM *.log WHERE sc-status=500 GROUP BY Hour ORDER BY Hour" -i:w3c -o:CHART -chartType:Column3D -ChartTitle:"500 Errors by Hour"
    
    Statistics:
    -----------
    Elements processed: 4189228
    Elements output:    13
    Execution time:     6.32 seconds

Figura 13: Query LogParser (Creare un istogramma 3D)

Il grafico risultante è illustrato nella figura 14.

Diagramma di un istogramma tridimensionale che mostra il numero di 500 errori all'ora per data.
Figura 14: Istogramma a colonne LogParser 3D

Creazione di grafici con Excel e CSV

All'inizio di questa sezione ho accennato che l'installazione del componente Office Web (OWC) è un requisito se si desidera utilizzare le funzionalità di creazione di grafici LogParser. Nell'organizzazione potrebbero esserci restrizioni che impediscono questa operazione o semplicemente non si vuole installarla. In entrambi i casi, è consigliabile esportare il risultato della query LogParser in un file CSV e importarlo in Excel.

La figura 15 mostra la query LogParser che estrae i codici di stato HTTP per tutte le richieste che non sono 200 in un file CSV.

logparser.exe "SELECT sc-status AS Status, COUNT(*) AS Count INTO status.csv FROM *.log WHERE sc-status > 200 GROUP BY Status ORDER BY Status" -i:w3c -o:csv
    
    Statistics:
    -----------
    Elements processed: 4189228
    Elements output:    10
    Execution time:     6.20 seconds

Figura 15: Query LogParser (Creare un file CSV per l'importazione in Excel)

Si noti che nella figura 15 è stato usato il parametro -o in modo che LogParser crei l'output in formato CSV.

Per importare il file CSV in Excel in modo che un grafico possa essere creato, aprire Excel, passare alla scheda DATI e selezionare Da testo. Nella figura 16 viene illustrato l'aspetto seguente.

Screenshot che mostra le opzioni del menu della scheda Dati di Excel.Figura 16: Importare un file CSV creato da LogParser in Excel

Selezionare il file status.csv creato dalla query LogParser e passare all'importazione guidata. Importare il file CSV delimitato da 'virgola' e si finisce con lo stato nella colonna A e il numero di occorrenze per ogni stato nella colonna B. Si presuppone che sia stata eseguita la query LogParser illustrata nella figura 15. Infine, selezionare tutti i dati dalla colonna A e B, incluse le intestazioni e scegliere il tipo di grafico a torta da creare. La figura 17 illustra l'aspetto di questo aspetto.

Screenshot che mostra le opzioni della scheda Inserisci di Excel. I dati nelle colonne A e B sono selezionati.Figura 17: Creare un grafico a torta usando un file CSV

Il risultato finale è un grafico a torta, figura 18 simile a quello illustrato in precedenza nella figura 10. Esistono molte opzioni per quanto riguarda il colore, il tipo di grafico, le etichette e così via. Con un clic di un pulsante è possibile modificare il tipo di grafico da Torta a Barra o a Linea. Sono disponibili numerose opzioni per la creazione di grafici dall'aspetto professionale all'interno di Excel.

Screenshot di un grafico a torta tridimensionale che mostra lo stato della richiesta.
Figura 18: Grafico a torta con un file CSV simile alla figura 10

Esistono così tante opzioni e possibilità per analizzare e presentare i risultati di tale analisi usando LogParser. Per altri suggerimenti ed esempi, vedere questi articoli scritti da Robert McMurray. Esiste anche un file della Guida molto utile e molti script prescritti forniti all'interno del pacchetto di installazione di LogParser. La sezione successiva illustra in modo più dettagliato questo e altri argomenti.

Help

Quando si installa LogParser 2.2 nel computer, viene installato per impostazione predefinita nella C:\Program Files (x86)\Log Parser 2.2 directory . Passare a tale posizione ed esaminare le directory Samples\Queries and Samples\Scripts per un'ampia fornitura di codice prescritto che consente di spostarsi rapidamente.

Si realizzerà anche un grande vantaggio leggendo il contenuto all'interno del file LogParser.chm.

Riduzione delle dimensioni o della suddivisione dei file di log iis

È possibile che si verifichi una situazione in cui il file di log IIS è troppo grande per La query di LogParser. Questo è molto probabile in un computer a 32 bit, ma può verificarsi anche in un computer a 64 bit. Tuttavia, se si verificano errori di memoria insufficiente durante l'esecuzione di una query LogParser, provare a eseguire il comando illustrato nella figura 19. La query estrae alcuni campi essenziali da un file di log IIS di grandi dimensioni e li inserisce in un altro file di log, con un file di log più piccolo.

logparser.exe "SELECT date, time, c-ip, cs-uri-stem, cs-uri-query, sc-status, sc-substatus, sc-win32-status, sc-bytes, cs-bytes, time-taken INTO u_exJUSTRIGHT.log FROM u_exTOOBIG.log" -i:w3c -o:w3c
    
    Statistics:
    -----------
    Elements processed: 19712301
    Elements output:    19712301
    Execution time:     3.07 seconds

Figura 19: Riduzione delle dimensioni di un file di log IIS (rimuovendo i campi)

In questo esempio ho realizzato una riduzione delle dimensioni del file di circa il 45%. In molti casi questo potrebbe essere sufficiente, in altri forse no. Dipende dalle dimensioni del file di log originale. Se si ritiene che sia ancora necessario ridurre le dimensioni del file di log IIS, prendere in considerazione l'aggiunta di un vincolo di data e ora alla query LogParser, come illustrato nella figura 20.

logparser.exe "SELECT date, time, c-ip, cs-uri-stem, cs-uri-query, sc-status, sc-substatus, sc-win32-status, sc-bytes, cs-bytes, time-taken INTO u_exJUSTRIGHT.log FROM u_exTOOBIG.log WHERE to_timestamp(date, time) >= timestamp('2012-11-09 00:00:00', 'yyyy-MM-dd hh:mm:ss')" -i:w3c -o:w3c
    
    Statistics:
    -----------
    Elements processed: 240123
    Elements output:    240123
    Execution time:     0.45 seconds

Figura 20: Ridurre ulteriormente le dimensioni di un file di log IIS aggiungendo una clausola WHERE

Si tratta di una tecnica utile per ridurre le dimensioni del file, ma è utile anche rimuovere le voci indesiderate dal log IIS. Ad esempio, quando si inizia a risolvere un problema, ci si rende conto che la registrazione di tempo, sc-bytes e cs-bytes non è stata registrata. Sono stati abilitati in IIS e si vuole che la query analizzi solo le voci con i campi abilitati di recente. Utilizzare l'istruzione where per estrarre i dati dal file di log IIS dal momento in cui tali campi sono stati abilitati. Questo è importante quando si usano le aggregazioni AVG, MIN e MAX.

Conclusione

LogParser è uno strumento piccolo ma potente per analizzare diversi tipi di log di sistema. Questo articolo è incentrato sulle query applicabili ai log IIS. Quando si verificano problemi di prestazioni o errori nell'ambiente IIS, talvolta è difficile sapere dove iniziare.

LogParser può essere usato come punto di partenza, perché un amministratore di sistema con alcune competenze SQL può creare rapidamente alcune query LogParser molto sofisticate. Queste query possono essere usate per analizzare ulteriormente la causa radice del problema.

Ecco i collegamenti a cui si fa riferimento in questo articolo, oltre ad alcuni collegamenti con informazioni aggiuntive.

  • Last updated on