ArcGIS Enterprise-Protokolle und System Log Parser
Während mehrere Community-Artikel existieren, die die Analyse von ArcGIS Enterprise-Protokollen und den Einstieg in den System Log Parser behandeln:
Es gibt nur wenige Ressourcen, die ins Detail gehen über den generierten Tabellenkalkulationsbericht und wie GIS-Administratoren und/oder Entwicklerentscheidungen basierend auf den Leistungsinformationen getroffen werden können, die er liefert.
Dieser Artikel führt durch, wie man eine Protokollanalyse bei einer Utility Network-Bereitstellung durchführt, die dann genutzt werden kann, um Wissen über die Nutzung und Effizienz der Site aufzubauen.
Leistungsanalyse von ArcGIS Enterprise-Protokollen
Bevor wir einsteigen, lassen Sie uns überprüfen, was Protokollanalyse ist und wo solche Protokolldaten in einer ArcGIS-Bereitstellung gefunden werden können.
Protokollanalyse:
Der Prozess der Informationsgewinnung aus Protokolldaten. Diese Informationen können verwendet werden, um die GIS-Nutzung zu quantifizieren und helfen dabei zu beantworten:
- Welche Dienste fordern Benutzer an?
- Welche Operationen führen sie aus?
- Welche Leistung erleben sie?
Protokolldaten:
Die zu analysierenden Protokolldaten sind die ArcGIS Enterprise-Protokolle. Typischerweise befinden sich diese Daten auf den Bereitstellungsservern und liegen in verschiedenen Formen vor:
- ArcGIS Web Adaptor-Zugriffsprotokolle
- Die in diesem Artikel verwendete Protokolldatenquelle
- ArcGIS Server-Zugriffsprotokolle
- Von ArcGIS Pro generierte Protokolle
Jede Protokollquelle bietet ihren eigenen Reichtum an Informationen.
Beispielszenario für die Protokollanalyse
Das folgende Szenario ist der Anwendungsfall für unsere Protokollanalyse:
Ihr Manager hat eine Aufgabe zugewiesen:
Quantifizieren Sie die ArcGIS Utility Network Nutzung und Effizienz Ihrer Site
Das bedeutet, dass folgende Fragen beantwortet werden müssen:
- Ist die Site gut verwaltet und optimal?
- Welche Dienste sind am beliebtesten?
- Welche Methoden werden aufgerufen?
- query, applyEdits, updateSubnetwork
- Wie performen die Dienste?
- Gesamter Benutzererfahrung?
Unser Manager hat außerdem verlangt, dass eine solche Analyse kosteneffizient durchgeführt wird.
Hinweis: Bevor mit der Protokollanalyse begonnen wird, wird empfohlen, etwaige Leistungsvorgaben zu prüfen, die möglicherweise bereits für Ihre Organisation existieren. Solche Kriterien können angeben, welche Leistung für bestimmte Operationen über einen bestimmten Zeitraum erwartet wird. Dies kann Ihnen helfen zu beantworten, wie Ihre Dienste im Hinblick auf Ihre Bereitstellung performen.
Warum Protokollanalyse durchführen?
Wir haben unsere Aufgabe vor Augen, aber warum sollten wir uns die Protokolle ansehen? Warum eine Protokollanalyse durchführen?
Um die Nutzung der Site und Effizienz der Utility Network-Bereitstellung zu erkennen, ist eine bewährte Strategie, die Leistungsfähigkeit von Anfragen und deren Nutzung durch die Protokolle zu verstehen.
Diese Vorgehensweise bietet mehrere Vorteile:
- Einfach durchzuführen
- Schnell erledigt
- Daten liegen sehr wahrscheinlich bereits zur Analyse vor
- Nicht-invasives Lesen
- Kann minimale Kosten für Serverressourcen verursachen
ArcGIS Enterprise-Protokolle (ArcGIS Web Adaptor-Zugriffsprotokolle oder ArcGIS Server-Protokolle) können einen wertvollen Datensatz von Client-Anfragen und Server-Antworten liefern. Diese Daten bieten eine leistungsstarke und genaue Sicht auf die Vergangenheit.
Wie wird die Analyse durchgeführt?
Die Strategie für diese Analyse ist einfach:
- Daten der Bereitstellungsprotokolle konsumieren
- Anfrageinformationen extrahieren
- Statistiken zur Dienst- und Funktionsleistung generieren
Protokolldaten können schnell gelesen und analysiert werden mit einem kostenlosen Tool: System Log Parser
System Log Parser ist ein Tool zum Verarbeiten von Protokollen, das über eine grafische Benutzeroberfläche (GUI) oder Befehlszeile (für automatisierte Skripte) ausgeführt werden kann. Es ist für die Windows-Plattform kompiliert.
Strategien zur Protokollanalyse
Welche Protokollquelle sollte für die Analyse verwendet werden?
Für eine Bereitstellung können mehrere Quellenoptionen existieren:
- ArcGIS Enterprise
- ArcGIS Web Adaptor-Zugriffsprotokolle
- Microsoft Internet Information Services (IIS)
- Apache Tomcat
- Cloud
Zugriffsoptionen können ebenfalls bestehen:
- Zugriff über Web
- Zugriff über lokales Netzwerk
- Zugriff über lokales Dateisystem
Jede Protokollquelle hat einzigartige Stärken und obwohl mehrere Quellen für eine Bereitstellung existieren könnten, wird empfohlen, eine auszuwählen und diese für die Hauptanalyse zu verwenden (z.B. ArcGIS Web Adaptor-Zugriffsprotokolle).
Für diesen Artikel wird das Lesen der ArcGIS Web Adaptor-Zugriffsprotokolle über das lokale Netzwerk als Datenquelle verwendet.
Hinweis: Die meisten Protokollformate sind betriebssystemunabhängig und standardisieren die Daten-Spalten. ArcGIS Server-Protokolle folgen diesem Muster.
System Log Parser ausführen
Grafische Benutzeroberfläche
Einfach zu bedienen und konfigurierbar.
Optionen:
- Protokollquelle wählen
- Internet Information Services Log Query
- Pfad zum Speicherort der Protokolle festlegen
- Lokal: C:\inetpub\logs\LogFiles\W3SVC1
- Es kann auch ein freigegebener Netzwerkstandort angegeben werden: \\server1.yourdomain.org\w3svc1
- Datumsbereich festlegen
- Analysetyp auf Optimized setzen (Standard)
- Schnell und speichereffizient auf dem Rechner, auf dem System Log Parser läuft
- Protokolle analysieren!
Automatisierung via Befehlszeile
Gleiche Funktionalität wie GUI aber etwas flexibler. Ideal zur periodischen Generierung automatisierter Berichte (z.B. eine Windows-Geplante Aufgabe).
PowerShell-Beispiel:
- Protokollquelle wählen
- Pfad zum Speicherort der Protokolle festlegen
- Lokal: C:\inetpub\logs\LogFiles\W3SVC1
- Es kann auch ein freigegebener Netzwerkstandort angegeben werden: \\server1.yourdomain.org\w3svc1
- Datumsbereich festlegen
- Zeit in UTC
- Kann einen spezifischen Datumszeitwert übergeben bekommen
- -startstring "[Start_DateTime_UTC]"
- -endstring "[End_DateTime_UTC]"
- Analysetyp auf Optimized setzen
- Protokolle analysieren!
PS C:\> # System Log Parser via PowerShell ausführen
PS C:\> $startLocal = $endLocal = Get-Date # Jetzt
PS C:\> $startLocal = $startLocal.AddDays(-7) # Gehe 7 Tage zurück
PS C:\> $startUtc = $startLocal.ToUniversalTime().ToString("yyyy/MM/dd h:mm:ss tt")
PS C:\> $endUtc = $endLocal.ToUniversalTime().ToString("yyyy/MM/dd h:mm:ss tt")
PS C:\> $iisLogPath = "C:\inetpub\logs\LogFiles\W3SVC1" # Könnte auch \\server1\W3SVC1 sein
PS C:\> $reportDate = $endLocal.ToString("yyyyMMddTHHmm")
& "C:\SystemLogParser\slp.exe" -f IIS -i "$iisLogPath" -startstring "$startUtc" -endstring "$endUtc" -a Optimized -d "C:\MyReports" -n "SLP_IIS_Optimized_$reportDate.xlsx" -o falseHinweis: Wenn die Größe Ihrer Protokolldaten unbekannt ist, wird empfohlen mit einem kleineren Abfragefenster zu beginnen (z.B. 1 Stunde oder 6 Stunden), bis eine relative Berechnungszeit verstanden wird.
Der Protokollbericht -- Verständnis der System Log Parser-Ausgabe
Standardmäßig ist der generierte Bericht tabellenkalkulationsbasiert. Er erstellt eine XLSX-Datei, welche ein Open Office XML-Dokument ist. Der Bericht besteht typischerweise aus mehreren Arbeitsblättern, von denen jedes eine bestimmte Metrik zusammenfasst.
Zusammenfassungsarbeitsblatt
Die erste Seite listet einige Informationen auf, die Folgendes detaillieren:
- Das Datum, an dem der Bericht erstellt wurde
- Der Analysetyp des Berichts
- Angegebener Log-Pfad
- Start- und Endzeiten
- Hochrangige Log-Abfrage- und Anforderungsstatistiken
Statistik nach Methode Arbeitsblatt
Das Arbeitsblatt Statistik nach Methode ist eine Aufschlüsselung von Anfragen und Antworten pro Funktion, die helfen, einige der Hauptfragen der Aufgabe zu beantworten:
- Welche Methoden (auch als Funktionen oder Operationen bezeichnet) wurden aufgerufen?
- query, applyEdits, updateSubnetwork?
- Wie haben die Dienste abgeschnitten?
Die Tabelle in diesem Arbeitsblatt bietet eine Fülle von Informationen. Die Standardansicht sortiert die Zeitspalten nach dem größten Sum-Wert. Sum ergibt sich aus der "Anfrage Vorkommen (Count-Spalte) * durchschnittliche Antwortzeit (Avg-Spalte)", was den Dienst und die Operation hervorhebt, auf die die Server die meiste Zeit verwendet haben, um Antworten zu erfüllen.
Hinweis: Die angezeigten Antwortzeiten dienen nur Demonstrationszwecken. Die Antwortzeiten für jede Bereitstellung sind einzigartig, da die Leistung von vielen Faktoren beeinflusst wird.
Hinweis: Die tabellarische Datenansicht für die tatsächliche Bereitstellung kann viel größer sein mit mehr Diensten und zusätzlichen gemeldeten Funktionen.
Zusätzlich zu Sum, Count und Durchschnitt werden folgende Statistiken angezeigt, um ein tieferes Verständnis darüber zu vermitteln, wie die Dienste und Funktionen arbeiten:
- Min
- Minimum, der geringste oder schnellste beobachtete Antwortzeitwert für diese Funktion (von dieser Dienstquelle)
- P50
- Der 50. Perzentil; 50 % der Antwortzeitdaten für diese Funktion (von dieser Dienstquelle) liegen an oder unter diesem Wert
- P95
- Der 95. Perzentil; 95 % der Antwortzeitdaten für diese Funktion (von dieser Dienstquelle) liegen an oder unter diesem Wert
- P99
- Der 99. Perzentil; 99 % der Antwortzeitdaten für diese Funktion (von dieser Dienstquelle) liegen an oder unter diesem Wert
- Max
- Maximum, der höchste beobachtete Antwortzeitwert für diese Funktion (von der Dienstquelle)
- Stdev
- Standardabweichung, eine Berechnung zur Streuung oder Variation der Antwortzeiten für diese Funktion (von dieser Dienstquelle)
Die Tabelle hebt hervor, dass die query-Funktion die am häufigsten angeforderte Methode war. Nach Bereitstellungs-Rechenzeit waren die drei wichtigsten Operationen tatsächlich alle query (z.B. MapServer, FeatureServer und Hosted) über zwei verschiedene Dienste (Naperville_Electric und Naperville_Overlay).
Betrachtet man die Avg-Spalte, so sind die durchschnittlichen Antwortzeiten (in Sekunden) dieser query-Funktionen zusammengefasst und alle drei lagen unter einer Sekunde (das heißt weniger als 1 Sekunde).
Diese Tabelle hilft bei der Beantwortung der Frage, welche Methoden aufgerufen wurdenEin Leistungsprofil für drei verschiedene queries wurde gefunden zusammen mit applyEdits und updateSubnetwork.Andere Funktionen waren vorhanden wie trace, reconcile und post.Was die Leistung der beiden gemeldeten Dienste betrifft, kann die endgültige Antwort auf diese Frage je nach Organisation variieren:Typischerweise basierend auf bestehenden Leistungskriterien für den Dienst, die Funktion und MetrikErste Läufe des System Log Parser liefern ein Verständnis des aktuell ausgewählten ZeitrahmensDies sollte eine gute Gesamtprobe liefern.Das regelmäßige Ausführen des System Log Parser ermöglicht es Ihnen, Änderungen in den Leistungsprofilen zu vergleichen.Wenn in nachfolgenden Berichten ungewöhnliches Verhalten beobachtet wird, kann eine Untersuchung oder Überprüfung erforderlich sein.}Hinweis: Typischerweise folgen nicht alle Methoden denselben Leistungskriterien. Jede Funktion führt andere Arbeiten aus als andere. Eine Feature-Abfrage hätte ein anderes Leistungsprofil als updateSubnetwork..
Anfrageanzahlen nach Ressource ArbeitsblattRessourcenanfragen (methodenbasierte Anfragen)Zählt basierend auf Anfragen, die bekannte Servicefunktionen verwendeten (ähnliche Summen wie im Arbeitsblatt Statistik nach Methode).Ressourcenanfragen (methoden- und serviceendpunktbasierte Anfragen)Zählt basierend auf Anfragen, die bekannte Servicefunktionen verwendeten und Anfragen an REST-Serviceendpunkte, die typischerweise Metadaten abrufen (ähnliche Summen wie im Capability - Server Arbeitsblatt).
Welche Dienste sind am beliebtesten?Capability - Server Arbeitsblatt
Hinweis: Die angezeigten Antwortzeiten dienen nur Demonstrationszwecken. Die Antwortzeiten für jede Bereitstellung sind einzigartig, da die Leistung von vielen Faktoren beeinflusst wird....Ist das Site gut verwaltet und optimal?Gesamter BenutzererfahrungEine gut verwaltete und optimale Site impliziert:Die Mehrheit der durchgeführten Operationen war schnell oder innerhalb des als gut/akzeptabel angesehenen Bereichs„Schnell“ und „innerhalb des Bereichs“ sind subjektive Quantifizierungen und werden am besten durch vorbestehende Leistungskriterien Ihrer Organisation beantwortet.Eine andere Perspektive ist es, Ihr bestes Urteil aus Erfahrung zu verwenden.}} Eine kleine Anzahl von Anfragen in den größeren Zeitabschnitten weist darauf hin, dass es einige länger laufende Funktionen gibtVielleicht kann dies optimiert werdenDer Function input (z. B. die Parameter der Anfrage) kann ebenfalls ein Faktor seinWenn die Dienste dediziert sind (wie bei Utility Network services) und sie mit der entsprechenden Anzahl von Instanzen konfiguriert sindKonfigurationsanpassungen könnten entfallenDie gesamte Benutzererfahrung: Hängt mit den ausgeführten Funktionen und deren jeweiligem Leistungsprofil zusammenHinweis: Es gibt mehrere Faktoren, die eine Rolle bei der Service-Performance spielen können:Anzahl der InstanzenNur bei dedizierten Diensten verfügbarDie DatenDie aufgerufenen MethodenSowie die verwendeten ParameterBereitstellungsarchitekturVerfügbare Hardware-RessourcenNachfrage (z. B. gleichzeitige Anfragen) Die Anpassung dieser Merkmale zur Leistungsoptimierung liegt außerhalb des Umfangs dieses Artikels.ProtokollberichtDer generierte Protokollbericht erleichterte es, die Fragen für die Aufgabe zu beantworten.Welche Dienste waren am beliebtesten?Naperville_Electric war der beliebteste, gefolgt von Naperville_OverlayWelche Funktionen wurden aufgerufen?Viele verschiedene Methoden wurden aufgerufen: mehrere räumliche Abfragen, applyEdits, updateSubnetwork, trace, validateNetworkTopology, reconcile und post. Wie haben sich die Dienste verhalten?Letztendlich kann diese Definition je nach Organisation variierenSie basiert typischerweise auf einem Kriterium oder einer Vereinbarung, die eine Erwartung für jeden Dienst und jede Operation auflistetAus dem System Log Parser Bericht:Konnte die Service-Performance identifizieren und ein statistisches Profil für jede Operation (pro Dienst) sehenEntscheidungsunterstützung für Wartungs- und OptimierungsmöglichkeitenZusammenfassungAus der ArcGIS Enterprise Protokollanalyse wurde ein Bericht erstellt, der die Anfrage- und Antwortaktivität der Utility Network Bereitstellung zusammenfasste.Die Analyse und Leistungsaufgliederung erfolgte durch System Log Parser. System Log Parser ist ein kostenloses Tool für Windows und ist auch im Abschnitt Well Architected Systems tools aufgeführt.Der Bericht lieferte statistische Daten, um Fragen zur Site zu beantworten wie:Welcher war der beliebteste DienstWelche Methoden wurden von diesen Diensten aufgerufenWie sich die Dienste verhielten und ob die Site gut verwaltet wurdeDiese konnten beantwortet werdenKombiniert mit den Leistungszielen der OrganisationBasiert auf Urteilen aufgrund von Erfahrung Trotz der abgeschlossenen Analyse und Aufgabe...ist Ihre Arbeit noch nicht beendet!Die beste Site-Analyse entsteht durch periodische Bewertung der Bereitstellung, weil:Nutzungstrends sich im Laufe der Zeit ändernEinige Dienste können beliebter werden, andere wenigerMögliche Gelegenheit zur Optimierung dedizierter Service-KonfigurationenSie möchten historisches Wissen über das Leistungsverhalten der Site aufbauenDas Verständnis darüber, wie Funktionen von den Diensten ausgeführt werden, kann helfen zu erkennen, wann Verhaltensweisen und/oder Muster ungewöhnlich oder fehl am Platz erscheinenDies kann bei der Fehlerbehebung und Optimierung unterstützenKann hervorheben, wann die Dienste und FunktionenOptimal sindNicht optimal sindDas regelmäßige Ausführen von System Log Parser (z. B. einmal im Monat) kann Ihnen helfen, ein historisches Verständnis der Leistung Ihrer Site aufzubauen. Dieser Artikel konzentrierte sich auf die Analyse einer Site mit Utility Network services, aber die Praxis und Strategien könnten auf jede GIS-Bereitstellung angewendet werden.
