Freigeben über

Problembehandlung bei IIS-Leistungsproblemen oder Anwendungsfehlern mithilfe von LogParser

von Benjamin Perkins

Tools und Kenntnisse, die in dieser Problembehandlung verwendet werden

Übersicht

Diese Problembehandlung hilft Ihnen bei der Analyse von IIS-Protokolldateien, um die Ursache zu ermitteln, wenn eine Anwendung, die auf IIS gehostet wird, fehlschlägt oder Leistungsprobleme auftritt. Bevor Sie beginnen, ist es wichtig zu beachten, dass alle Felder, die IIS protokollieren kann, standardmäßig nicht aktiviert sind. Beispielsweise sind bytes Sent and Bytes Received not selected, but they are very nützlich when troubleshooting a performance problem. Daher ist die beste Zeit, diese zusätzlichen Felder einzuschließen, bevor Systemprobleme auftreten. Wenn Sie dies noch nicht getan haben, wählen Sie diese zusätzlichen Felder aus, sie helfen Ihnen bei der Suche nach Lösungen, wenn Probleme auftreten.

Im folgenden Blog wird erläutert, wie Sie dies in IIS 7+ ausführen:

Ändern von IIS 7-Protokolldaten in Windows 2008

Szenario

Als Systemadministrator hören Sie Berichte von Benutzern Ihres Systems, die auf IIS gehostet werden, dass die Antwort langsam ist. Es gibt einige Erwähnungen, dass Webbrowser einfach zeitüberschreitungen oder nicht mehr reagieren, wenn sie auf Ihre Website zugreifen.

Sie springen in Aktion und recyceln den Arbeitsprozess; alles scheint wieder zu funktionieren, wie normal.

Sie können dies jedoch nicht als Lösung akzeptieren und wissen, warum dies passiert ist, aber nicht wissen, wo Sie beginnen möchten. Sie haben keine Details der Benutzer, z. B. Fehlercodes, Screenshots und schlimmer, Sie haben keine Leistungsdaten, um zu vergleichen, was gerade mit der normalen Leistung passiert ist. In vielen Fällen bringen Sie andere neue Probleme von einer schwerwiegenden Ursachenanalyse weg.

Microsoft LogParser ist ein gutes Tool, das schnell und einfach zu verwenden ist. In vielen Situationen hilft Ihnen das Tool, schnell ein tieferes Verständnis darüber zu erhalten, was auf dem Server passiert ist, und hilft Ihnen dabei, Probleme zu erkennen. Sie können die Informationen, die Sie mit LogParser sammeln, an Ihr Datenbankteam, Ihr Netzwerkteam oder an Ihre Entwickler weitergeben, um weitere Analysen zu erhalten.

Datensammlung

Standardmäßig befinden sich IIS-Protokolldateien in den folgenden Verzeichnissen:

  • IIS 7 und höher: %SystemDrive%\inetpub\logs\LogFiles
  • IIS 6 und früher: %WinDir%\System32\LogFiles

In dieser Problembehandlung verwende ich IIS 8. Öffnen Sie den IIS-Manager , und wählen Sie "Websites" aus, wie in Abbildung 1 dargestellt. Dadurch wird die ID jeder Website angezeigt, die auf Ihrem Server gehostet wird. Sie benötigen diese ID, um zu bestimmen, welches W3SVC*-Verzeichnis analysiert werden soll.

Screenshot des I S Manager-Fensters mit Websites im Hauptbereich.
Abbildung 1: Abrufen der ID Ihrer Website

Öffnen Sie Windows-Explorer, und navigieren Sie zu dem Verzeichnis, das die IIS-Protokolldateien der Website enthält, die das Leistungsproblem aufgetreten ist. Abbildung 2 zeigt, wie das aussehen kann.

Screenshot des Windows-Explorers mit Dateispeicherorten.
Abbildung 2: Speicherort der IIS-Protokolldatei

IIS-Protokolldateien können ziemlich groß sein; In Abbildung 2 ist die Protokolldatei beispielsweise u_ex12101858.log fast 100 MB groß. Da diese Protokolldateien möglicherweise enorm sind und Hunderte von Tausenden einzelner Protokolldateieinträge enthalten, ist das manuelle Durchsuchen jeder dieser Dateien für einen Fehler kein guter Ansatz, und gibt nur wenige Ergebnisse für die Zeit zurück, die Sie investieren.

Dies ist der Fall, wenn LogParser zu einem unverzichtbaren Tool in Ihrem Problembehandlungsarsenal wird.

Datenanalyse

Der erste Schritt besteht darin, zu ermitteln, welche Protokolldateien Fehler enthalten können. Wenn Kunden beispielsweise am 3. Juni 2012 über die Leistung beschweren, kann die Protokolldatei u_ex120603.log sein, wobei:

  • "12" ist das gekürzte Jahr für 2012
  • "06" bezieht sich auf den sechsten Monat (Juni)
  • "03" ist der 3. Tag des Monats

Hinweis: Im obigen Beispiel wird davon ausgegangen, dass die IIS-Protokollierung so konfiguriert ist, dass Protokolldateien täglich gedreht werden, was die Standardeinstellung ist. Wenn Sie die Einstellungen für IIS geändert haben, um Protokolldateien in einem anderen Zeitintervall wie wöchentlich oder stundenweise zu drehen, sind die Namen der Protokolldateien unterschiedlich. Weitere Informationen zur Syntax für IIS-Protokolldateinamen finden Sie im Artikel zur Benennungssyntax für IIS-Protokolldateien (https://support.microsoft.com/kb/242898).

Hinweis

Standardmäßig werden das Datum und die Uhrzeit in IIS-Protokollen mithilfe von GMT gespeichert; Sie müssen dies berücksichtigen, wenn Sie bestimmen, welche Protokolle Fehler enthalten. Das heißt, Sie können die Datums-/Uhrzeitangaben mithilfe der Funktion Von LogParser TO_LOCALTIME() anpassen, wie im folgenden Beispiel dargestellt:

Hinweis

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

Nachdem Sie die IIS-Protokolldateien identifiziert haben, die Fehler enthalten, sollten Sie sie an einen Speicherort kopieren, an dem sie analysiert werden können. Dieser Schritt ist optional, es wird jedoch nicht empfohlen, Ihre Protokolle auf Ihrem IIS-Server zu analysieren, da Ihre LogParser-Abfragen möglicherweise lange dauern, und wenn Ihre Protokolldateien groß sind, kann der Log Parser mit Systemressourcen konkurrieren.

Beispielsweise können Sie Ihre IIS-Protokolle in einen Ordner auf Ihrem Persönlichen Computer kopieren, auf dem Sie die LogParser-Dateien bereits kopiert haben, was in der Regel meine Protokolldateien analysiert. Abbildung 3 zeigt ein Beispiel dafür, wo ich sie gespeichert habe, um diesen Artikel zu erstellen.

Screenshot des Windows-Explorers mit dem Speicherort der ausführbaren Datei des Protokollparsers.Abbildung 3: IIS protokolliert dateien, die lokal für die Analyse mit LogParser gehostet werden

Nachdem Sie LogParser heruntergeladen haben, können Sie mit der Analyse beginnen. Die erste ausgeführte Abfrage wird in Abbildung 4 angezeigt. Die Ergebnisse geben Ihnen einen Überblick darüber, wie IIS auf die Anforderungen reagiert.

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

Abbildung 4: LogParser-Abfrage (sc-status und sc-substatus)

Die interessanten Punkte innerhalb der Ergebnisse sind:

  • Das Verhältnis zwischen 200 und 304 HTTP-Statuscodes (erfolgreiche Anforderungen)
  • Die Anzahl von 500 HTTP-Statuscodes (fehlgeschlagene Anforderungen)

Die Bedeutung für jede dieser Statuscodes wird unten erläutert.

Das Verhältnis zwischen HTTP 200- und 304-Statuscodes (Analysieren erfolgreicher Anforderungen)

Das Verhältnis zwischen den HTTP-Statuscodes 200 und 304 ist wichtig, da es zeigt, wie viele Anforderungen vom Cache der Clients abgerufen werden, anstatt direkt vom Server. Die Ergebnisse in Abbildung 4 zeigen, dass es 3.920.658 Anforderungen gibt, die zu einem HTTP-Statuscode von 200 geführt haben. Dies bedeutet, dass die angeforderte Datei jedes Mal vom Server bereitgestellt wurde. Im Gegensatz dazu gab es 178.705 Anforderungen, die zu einem 304 HTTP-Statuscode geführt haben. Dies bedeutet, dass die angeforderte Datei aus dem lokalen Cache abgerufen wurde. Anders ausgedrückt: 95,5 % der Anforderungen werden vom Server verarbeitet.

Zwischenspeichern kann eine sehr positive Auswirkung auf die Leistung Ihres Systems haben; Weitere Informationen zur statischen und dynamischen Komprimierung finden Sie im Artikel zum Konfigurieren der HTTP-Komprimierung in IIS 7 .

HTTP 500 Statuscodes (Analysieren fehlgeschlagener Anforderungen)

HTTP 500 Statuscodes weisen möglicherweise schwerwiegende Probleme auf Ihrem System auf. Die Auswirkungsebene, die die Ursache eines HTTP 500-Fehlers auf Ihrem System hat, kann von nichts bis zum Absturz eines Arbeitsprozesses reichen. Wenn dies angezeigt wird, sollten Sie daher die in Abbildung 5 gezeigte Abfrage ausführen, um zu ermitteln, welche Anforderungen zu einem 500 HTTP-Statuscode geführt haben.

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

Abbildung 5: LogParser-Abfrage (cs-uri-stem mit einem 500 sc-status)

Diese Ergebnisse zeigen den Pfad und den Namen der Datei an, die bei Bedarf mit einem HTTP 500-Statuscode beantwortet wurde. Diese Art von Informationen wäre für das Entwicklungsteam wertvoll. Beispielsweise könnte das Entwicklungsteam diesen spezifischen Code weiter untersuchen und nach Code suchen, der ausgeführt wird, ohne in einem try {...} catch {...} Codeblock enthalten zu sein, oder sie führen große Datenabfragen aus, die optimiert werden müssen.

Nehmen wir dieses Beispiel einen Schritt weiter und konzentrieren uns auf den wichtigsten Mitwirkenden für HTTP 500 Statuscodes. Es wäre interessant zu wissen, wann diese Fehler aufgetreten sind, da diese Informationen verwendet werden können, um zu überprüfen, ob Abhängigkeiten gleichzeitig Probleme haben.

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

Abbildung 6: LogParser-Abfrage (cs-uri-stem mit einem 500 sc-status)

Die Teilmenge der Ergebnisse in Abbildung 6 beschränkt den Datumsbereich des Problems. Diese Informationen können an Netzwerk-, Datenbank-, Betriebssystemadministratoren und die Entwicklungsteams übergeben werden, um zu überprüfen, ob gleichzeitig etwas anderes geschieht. Beispiel: Gab es zusätzliche Probleme zwischen 08:00 und 09:59:59 GMT und zwischen 14:00:00 und 14:59:59:59 GMT?

Der nächste Satz von LogParser-Abfragen verwendet die folgenden Felder, die einen besseren Einblick in Leistungsprobleme geben können:

Feld BESCHREIBUNG Standardmäßig aktiviert
Zeitaufwand Die Dauer der Aktion in Millisekunden Ja
sc-bytes Die Anzahl der vom Server gesendeten Bytes Nein
cs-bytes Die Anzahl der vom Server empfangenen Bytes Nein

Wie bereits erwähnt, nehmen Sie sich jetzt Zeit, um die Sc-Bytes- und cs-Bytes-Felder zu aktivieren oder, falls möglich, sie selbst zu aktivieren. Sie bieten wertvolle Einblicke in Ihr System und sein Verhalten. Beispiel : Abbildung 7. Sie sehen, dass die durchschnittliche Zeit bei einigen hundert Millisekunden ziemlich gut ist. Betrachten Sie jedoch die maximale Zeit, die zu viel Zeit dauert.

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

Abbildung 7: LogParser-Abfrage (MAX und AVG-Zeitaufwand)

Ich weiß, dass Sie sich bereits die nächste Frage stellen, die beantwortet werden muss. Welche Anforderung dauert so viel Zeit? Abbildung 8 zeigt die Antwort auf diese Frage. Wie Sie feststellen werden, habe ich das Sc-Bytes-Feld in die LogParser-Abfrage aufgenommen. Denken Sie daran, dass sc-bytes die Größe der vom Server zurück an den Client gesendeten Datei darstellt.

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

Abbildung 8: LogParser-Abfrage (MAX und AVG-Zeitaufwand)

Wir würden wahrscheinlich alle zustimmen, dass die für die Anforderungen benötigte Zeit eine "normale" Antwortzeit überschreitet. Die Größe der Dateien ist jedoch etwas, das der Administrator oder Entwickler analysieren muss, um festzustellen, ob sich die Größen innerhalb eines akzeptablen Bereichs befinden.

Die Schlussfolgerung besteht darin, dass die GetDetailsView.aspx-Datei eine Anzahl von 500 HTTP-Statuscodes ausgelöst hat und irgendwann lange dauerte, bis die Datei abgeschlossen wurde, auch wenn es sich um eine relativ kleine Datei handelte. Möglicherweise möchten Sie sich das Datum und die Uhrzeit ansehen, zu denen Probleme auftreten, die für diese Datei auftreten, und den Code in der Datei mit problemen untersuchen, die aufgetreten sind. (Beispielsweise enthalten die IIS-Protokolle eine Liste von Variablen, die in der Abfragezeichenfolge übergeben wurden. Sie können diese Werte auf schlechte Daten überprüfen.)

Die in Abbildung 4 - 8 angegebenen Beispiele helfen ihnen, ein Verständnis darüber zu erhalten, wo die Ursache eines Problems vorhanden sein kann. Wahrscheinlich hat diese Analyse jedoch nur eine bessere Sicht auf die Situation gemacht, die zu mehr Fragen und tieferen Analysen führen wird. Wenn dies der Fall ist, möchten Sie möglicherweise eine Darstellung dieser Daten auf ansprechendere Weise erstellen. Im folgenden Abschnitt wird dies ausführlich behandelt.

Berichterstellung

Screenshots eines Befehlsfensters mit LogParser-Abfragen und deren Ergebnisse können während der Analysephase eines Leistungsproblems in Ordnung sein; Wenn Sie jedoch vor Vorgesetzten oder Direktoren gehen müssen, um zu erklären, was passiert ist, kann es nicht die Marke erfüllen.

Hinweis

Damit Diagramme über LogParser funktionieren können, müssen Sie die Office Web Components installieren. In den folgenden Artikeln wird erläutert, wie Sie dies tun:

Abbildung 9 zeigt die LogParser-Abfrage zum Erstellen eines 3D-Kreisdiagramms mit der Anzahl der Anforderungen und dem zugehörigen HTTP-Statuscode. Ich habe den Status 200 entfernt, da diese erfolgreich sind. Was ich hier bin, sind die Anforderungen, die etwas anderes als OK sind.

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

Abbildung 9: LogParser-Abfrage (Erstellen eines 3D-Kreisdiagramms)

Das Ergebnis der Abfrage wird in Abbildung 10 veranschaulicht. Es gibt eine Reihe zusätzlicher Parameter, die Sie an LogParser übergeben können, die sich auf das Bild auswirken. Legend, groupSize, config usw. Um eine vollständige Listeneingabe abzurufen: LogParser -h -o:CHART für eine Liste aller Parameter. Dieser Befehl enthält auch eine Liste der verschiedenen Diagrammtypen.

Diagramm eines dreidimensionalen Kreisdiagramms mit Anforderungsstatuszuweisungen.
Abbildung 10: LogParser 3D-Kreisdiagramm

Ein weiteres nützliches Diagramm ist das Verhältnis zwischen zwischengespeicherten und tatsächlichen Anforderungen. Erinnern Sie sich an den Abschnitt "Datenanalyse", in dem ich erläutert habe, dass ein HTTP-Statuscode von 200 bedeutet, dass die angeforderten Dateien jedoch vom Server abgerufen werden, ein 304 wird vom Client abgerufen. Abbildung 11 zeigt die LogParser-Abfrage für die Erstellung dieses Diagramms. Beachten Sie, dass ich den Parameter "-values " verwendet habe.

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

Abbildung 11: LogParser-Abfrage (Erstellen eines 3D-Kreisdiagramms)

Obwohl der Unterschied zwischen HTTP-Statuscode 200 und 304 deutlich sichtbar ist, dachte ich, dass er einige Werte hinzufügen kann, um die Anzahl der Treffer für jede zu enthalten. Abbildung 12 veranschaulicht die Ausgabe der vorherigen LogParser-Abfrage.

Diagramm eines dreidimensionalen Kreisdiagramms mit der Zuordnung des Caches.
Abbildung 12: LogParser 3D-Kreisdiagramm

Ich denke, Sie erhalten jetzt das Bild darüber, wie die Diagrammerstellung der IIS-Protokolle mithilfe von LogParser helfen kann, was viel besser geschieht als eine Tabelle mit Daten. Aber bevor ich stoppe, möchte ich Ihnen ein weiteres Beispiel mit dem Spaltendiagrammtyp anzeigen. Die in Abbildung 13 dargestellte LogParser-Abfrage erzeugt ein 3D-Säulendiagramm mit der Anzahl von 500 HTTPS-Statuscodes pro Stunde.

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

Abbildung 13: LogParser-Abfrage (Erstellen eines 3D-Säulendiagramms)

Das resultierende Diagramm wird in Abbildung 14 veranschaulicht.

Diagramm eines dreidimensionalen Säulendiagramms mit der Anzahl von 500 Fehlern pro Stunde nach Datum.
Abbildung 14: LogParser 3D-Säulendiagramm

Erstellen von Diagrammen mithilfe von Excel und CSV

Am Anfang dieses Abschnitts habe ich erwähnt, dass die Installation der Office Web Component (OWC) eine Anforderung ist, wenn Sie die LogParser-Diagrammfunktionen verwenden möchten. In Ihrer Organisation gibt es möglicherweise Einschränkungen, die dies verbieten, oder Sie möchten es möglicherweise nicht installieren. Wenn dies der Fall ist, sollten Sie das LogParser-Abfrageergebnis in eine CSV-Datei exportieren und in Excel importieren.

Abbildung 15 zeigt die LogParser-Abfrage, die die HTTP-Statuscodes für alle Anforderungen extrahiert, die nicht 200 in eine CSV-Datei sind.

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

Abbildung 15: LogParser-Abfrage (Erstellen einer CSV-Datei zum Importieren in Excel)

Beachten Sie in Abbildung 15 , dass ich den Parameter -o verwendet habe, damit LogParser die Ausgabe im CSV-Format erstellt.

Um die CSV-Datei in Excel zu importieren, damit ein Diagramm daraus erstellt werden kann, öffnen Sie Excel, navigieren Sie zur Registerkarte "DATEN", und wählen Sie "Aus Text" aus. Abbildung 16 zeigt, wie dies aussieht.

Screenshot der Menüoptionen für die Excel-Registerkarte Abbildung 16: Importieren der CSV-Datei, die von LogParser in Excel erstellt wurde

Wählen Sie die status.csv Datei aus, die von der LogParser-Abfrage erstellt wurde, und navigieren Sie durch den Import-Assistenten. Importieren Sie die durch Trennzeichen getrennte CSV-Datei, und Sie enden mit dem Status in Spalte A und der Anzahl der Vorkommen für jeden Status in Spalte B. Dies geht davon aus, dass Sie die in Abbildung 15 dargestellte LogParser-Abfrage ausgeführt haben. Wählen Sie schließlich alle Daten aus Spalte A und B aus, einschließlich der Kopfzeilen, und wählen Sie den Typ des zu erstellenden Kreisdiagramms aus. Abbildung 17 zeigt, wie dies aussehen kann.

Screenshot der Registerkartenoptionen für Excel einfügen. Die Daten in Spalten A und B sind ausgewählt.Abbildung 17: Erstellen eines Kreisdiagramms mithilfe einer CSV-Datei

Das Endergebnis ist ein Kreisdiagramm, Abbildung 18 , das der zuvor in Abbildung 10 gezeigten Ähnlich ist. Es gibt viele Optionen in Bezug auf Farbe, Diagrammtyp, Beschriftungen usw. Mit einem Klick auf eine Schaltfläche können Sie den Diagrammtyp von Kreis in Balken oder in Linie ändern. Es gibt viele Optionen zum Erstellen professioneller aussehender Diagramme in Excel.

Screenshot eines dreidimensionalen Kreisdiagramms mit Anforderungsstatus.
Abbildung 18: Ein Kreisdiagramm mit einer CSV-Datei ähnlich wie Abbildung 10

Es gibt so viele Optionen und Möglichkeiten zur Analyse und Darstellung der Ergebnisse dieser Analyse mithilfe von LogParser. Weitere Tipps und Beispiele finden Sie in diesen Artikeln von Robert McMurray. Es gibt auch eine sehr nützliche Hilfedatei und viele vordefinierte Skripts, die im Installationspaket von LogParser bereitgestellt werden. Im nächsten Abschnitt werden dies und weitere Themen ausführlicher behandelt.

Hilfe

Wenn Sie LogParser 2.2 auf Ihrem Computer installieren, wird sie standardmäßig im C:\Program Files (x86)\Log Parser 2.2 Verzeichnis installiert. Navigieren Sie zu diesem Speicherort, und überprüfen Sie die Verzeichnisse "Samples\Queries" und "Samples\Scripts" für eine vielzahl von vordefinierten Code, die Sie schnell bewegen können.

Sie werden auch einen großen Vorteil erkennen, indem Sie die Inhalte in der Datei "LogParser.chm" lesen.

Verringern der Größe oder Aufteilung von IIS-Protokolldateien

Möglicherweise tritt eine Situation auf, in der die IIS-Protokolldatei zu groß ist, damit LogParser abfragen kann. Dies ist wahrscheinlich auf einem 32-Bit-Computer, kann aber auch auf einem 64-Bit-Computer auftreten. Wenn Sie beim Ausführen einer LogParser-Abfrage jedoch fehler beim Ausführen einer LogParser-Abfrage auftreten, sollten Sie den befehl in Abbildung 19 ausführen. Die Abfrage extrahiert einige wesentliche Felder aus einer großen IIS-Protokolldatei und platziert sie in eine andere, was zu einer kleineren Protokolldatei führt.

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

Abbildung 19: Verringern der Größe einer IIS-Protokolldatei (durch Entfernen von Feldern)

In diesem Beispiel habe ich eine Dateigrößenreduzierung von etwa 45 % realisiert. In vielen Fällen ist dies vielleicht genug, in anderen vielleicht nicht. Dies hängt von der Größe der ursprünglichen Protokolldatei ab. Wenn Sie feststellen, dass Sie die Größe der IIS-Protokolldatei weiterhin verringern müssen, sollten Sie der LogParser-Abfrage, wie in Abbildung 20 dargestellt, eine Datumszeiteinschränkung hinzufügen.

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

Abbildung 20: Weitere Reduzierung der Größe einer IIS-Protokolldatei durch Hinzufügen einer WHERE-Klausel

Dies ist eine wertvolle Methode zum Verringern der Dateigröße, aber es ist auch nützlich, unerwünschte Einträge aus dem IIS-Protokoll zu entfernen. Wenn Sie beispielsweise mit der Behandlung eines Problems beginnen, erkennen Sie, dass Zeitaufwand, sc-Bytes und cs-Bytes nicht protokolliert wurden. Sie haben sie in IIS aktiviert und möchten, dass die Abfrage diese Einträge nur mit den zuletzt aktivierten Feldern analysiert. Verwenden Sie die Where-Anweisung, um die Daten aus der IIS-Protokolldatei aus der Zeit zu extrahieren, in der diese Felder aktiviert wurden. Dies ist wichtig, wenn Sie die AVG-, MIN- und MAX-Aggregate verwenden.

Zusammenfassung

LogParser ist ein kleines, aber leistungsstarkes Tool, um eine Reihe verschiedener Systemprotokolltypen zu analysieren. Dieser Artikel konzentriert sich auf Abfragen, die auf IIS-Protokolle anwendbar sind. Wenn Leistungsprobleme oder Fehler in Ihrer IIS-Umgebung auftreten, ist es manchmal schwierig zu wissen, wo sie beginnen.

LogParser kann als Ausgangspunkt verwendet werden, da ein Systemadministrator, der über einige SQL-Fähigkeiten verfügt, schnell sehr anspruchsvolle LogParser-Abfragen erstellen kann. Diese Abfragen können verwendet werden, um die Ursachenanalyse des Problems weiter zu fördern.

Hier sind die Links, die in diesem Artikel erwähnt werden, sowie einige Links mit zusätzlichen Informationen.