ArcGIS Enterprise-logboeken en System Log Parser
Hoewel er verschillende Community-artikelen bestaan die het analyseren van ArcGIS Enterprise-logboeken bespreken en hoe te beginnen met System Log Parser:
Er zijn weinig bronnen die ingaan op de details van het gegenereerde spreadsheetrapport en hoe GIS-beheerders en/of ontwikkelaars beslissingen kunnen nemen op basis van de prestatie-informatie die het biedt.
Dit artikel zal stap voor stap uitleggen hoe loganalyse kan worden uitgevoerd op een Utility Network-implementatie, die vervolgens kan worden gebruikt om kennis op te bouwen over het gebruik en de efficiëntie van de Site.
Prestatieanalyse van ArcGIS Enterprise-logboeken
Voordat we beginnen, laten we eerst bekijken wat loganalyse is en waar dergelijke loggegevens kunnen worden gevonden in een ArcGIS-implementatie.
Loganalyse:
Het proces van het extraheren van informatie uit loggegevens. Deze informatie kan worden gebruikt om GIS-gebruik te kwantificeren en helpen bij het beantwoorden van:
- Welke services vragen gebruikers aan?
- Welke bewerkingen voeren ze uit?
- Welke prestaties ervaren ze?
Loggegevens:
De loggegevens die geanalyseerd moeten worden zijn de ArcGIS Enterprise-logboeken. Meestal bevinden deze gegevens zich op de implementatieservers en komen ze in verschillende vormen voor:
- ArcGIS Web Adaptor-toegangslogboeken
- De loggegevensbron die in dit artikel wordt gebruikt
- ArcGIS Server-toegangslogboeken
- Door ArcGIS Pro gegenereerde logboeken
Elke logbron biedt zijn eigen schat aan informatie.
Voorbeeldscenario voor loganalyse
Het volgende scenario is de use case voor onze loganalyse:
Uw manager heeft een taak toegewezen:
Kwantificeer het ArcGIS Utility Network gebruik en de efficiëntie van uw Site
Dit betekent dat de volgende vragen beantwoord moeten worden:
- Is de Site goed beheerd en optimaal?
- Welke services zijn het populairst?
- Welke methoden worden aangeroepen?
- query, applyEdits, updateSubnetwork
- Hoe presteren de services?
- Algemene gebruikerservaring?
Onze manager heeft ook gevraagd dat dergelijke analyse kosteneffectief moet worden uitgevoerd.
Opmerking: Voordat met de loganalyse wordt begonnen, wordt aanbevolen om eventuele prestatiecriteria te raadplegen die mogelijk al bestaan voor uw organisatie. Dergelijke criteria kunnen aangeven welke prestaties verwacht worden voor specifieke bewerkingen gedurende een bepaalde periode. Dit kan u helpen te begrijpen hoe uw services presteren ten opzichte van uw implementatie.
Waarom loganalyse uitvoeren?
We hebben onze taak, maar waarom door de logs gaan? Waarom loganalyse uitvoeren?
Om het gebruik en de efficiëntie van de Utility Network-implementatie te herkennen, is een bewezen strategie om verzoekprestaties en gebruik via de logs te begrijpen.
Er zijn verschillende voordelen aan deze aanpak:
- Makkelijk uit te voeren
- Snel uitgevoerd
- Zeer waarschijnlijk dat er al gegevens bestaan om te analyseren
- Niet-invasief lezen
- Kan minimale kosten voor serverbronnen hebben
ArcGIS Enterprise-logboeken (ArcGIS Web Adaptor-toegangslogboeken of ArcGIS Server-logboeken) kunnen een waardevol overzicht bieden van clientverzoeken en serverreacties. Deze gegevens geven een krachtig en nauwkeurig beeld van het verleden.
Hoe de analyse uitvoeren?
De strategie voor deze analyse is eenvoudig:
- Verwerk de implementatielogs
- Extraheer verzoekinformatie
- Genereer statistieken over service- en functieprestaties
Loggegevens kunnen snel gelezen en geanalyseerd worden met behulp van een gratis hulpmiddel: System Log Parser
System Log Parser is een tool voor het verwerken van logs die via een grafische gebruikersinterface (GUI) of opdrachtregel (voor geautomatiseerde scripting) kan worden uitgevoerd. Het is gecompileerd voor het Windows-platform.
Strategieën voor loganalyse
Welke logbron moet worden gebruikt voor de analyse?
Er kunnen verschillende bronopties bestaan voor een implementatie:
- ArcGIS Enterprise
- ArcGIS Web Adaptor-toegangslogboeken
- Microsoft Internet Information Services (IIS)
- Apache Tomcat
- Cloud
Er kunnen ook toegankelijkheidsopties zijn:
- Webtoegang
- Lokaal netwerktoegang
- Lokaal bestandssysteemtoegang
Iedere logbron heeft unieke sterke punten en hoewel er meerdere logbronnen kunnen bestaan voor een implementatie, wordt aanbevolen er één te kiezen en die te gebruiken voor de primaire analyse (bijv. ArcGIS Web Adaptor-toegangslogboeken).
Voor dit artikel zullen we de ArcGIS Web Adaptor-toegangslogboeken lezen via het lokale netwerk als bron van de gegevens gebruiken.
Opmerking: De meeste logformaten zijn besturingssysteemonafhankelijk en standaardiseren de datakolommen. ArcGIS Server-logboeken volgen dit patroon.
System Log Parser uitvoeren
Grafische gebruikersinterface
Makkelijk te gebruiken en configureerbaar.
Mogelijkheden:
- Kies logbron
< LI >Internet Information Services Log Query </ LI ></ UL ></ LI >< LI >< STRONG >Stel pad naar loglocatie in </ STRONG >< UL >< LI >Lokaal: C:\inetpub\logs\LogFiles\W3SVC1 < UL >< LI >Kan ook een gedeelde netwerklocatie zijn: \\server1.yourdomain.org\w3svc1 </ LI ></ UL ></ LI ></ UL ></ LI >< LI >< STRONG >Stel datumbereik in </ STRONG >< UL >< LI >Lokale tijd </ LI ></ UL ></ LI >< LI >< STRONG >Stel analysetype in op Geoptimaliseerd (standaard) </ STRONG >< UL >< LI >Snel en geheugen-efficiënt op machine waarop System Log Parser draait </ LI ></ UL ></ LI >< LI >< STRONG >Analyseer logs! </ STRONG ></ LI ></ UL >< P >< span class = "lia-inline-image-display-wrapper lia-image-align-inline" image-alt = "AaronLopez_1-1770685932956.png" style = "width: 999px;" > </ P >< H2 id = "toc-hId-1454392347" >Automatisering via opdrachtregel< P >Zelfde functionaliteit als GUI maar iets meer flexibiliteit. Ideaal voor het periodiek genereren van geautomatiseerde rapporten (bijv. een Windows Taakplanner-taak).</ P >< P >PowerShell voorbeeld:</ P >< UL >< LI >< STRONG >Kies logbron </ STRONG >< UL >< LI > -f IIS </ LI ></ UL ></ LI >< LI >< STRONG >Stel pad naar loglocatie in </ STRONG ></ LI >< UL >< LI >Lokaal: C:\inetpub\logs\LogFiles\W3SVC1 < UL >< LI >Kan ook een gedeelde netwerklocatie zijn: \\server1.yourdomain.org\w3svc1 </ LI ></ UL ></ LI ></ UL >< LI >< STRONG >Stel datumbereik in </ STRONG >< UL >< LI >Tijd in UTC < UL >< LI >Kan een specifieke datumtijdwaarde doorgeven </ LI >< LI > -startstring "[Start_DateTime_UTC]" </ LI >< LI > -endstring "[End_DateTime_UTC]" </ LI ></ UL ></ LI ></ UL ></ LI >< LI >< STRONG >Stel analysetype in op Geoptimaliseerd </ STRONG >< UL >< LI > -a Geoptimaliseerd </ LI ></ UL ></ LI >< LI >< STRONG >Analyseer logs! </ STRONG ></ LI ></ UL >< pre class = "lia-code-sample language-csharp" > PS C:\> # Voer System Log Parser uit via PowerShell
PS C:\> $startLocal = $endLocal = Get-Date # Nu
PS C:\> $startLocal = $startLocal.AddDays(-7) # Ga 7 dagen terug
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" # Kan ook \\server1\W3SVC1 zijn
PS C:\> $reportDate = $endLocal.ToString("yyyyMMddTHHmm")
& "C:\SystemLogParser\slp.exe" -f IIS -i "$iisLogPath" -startstring "$startUtc" -endstring "$endUtc" -a Geoptimaliseerd -d "C:\MyReports" -n "SLP_IIS_Geoptimaliseerd_$reportDate.xlsx" -o false< P >< FONT color="#FF0000">Aanmerking: Als de grootte van uw loggegevens onbekend is, wordt aanbevolen te beginnen met een kleiner queryvenster (bijv. 1 uur of 6 uur) totdat een relatieve rekentijd bekend is. </ P >< H1 id = "toc-hId-1443889243" >Het lograpport -- Begrijpen van System Log Parser-uitvoer< P >Standaard is het gegenereerde rapport spreadsheet-gebaseerd. Het maakt een XLSX-bestand aan dat een Open Office XML-document is. Het rapport bestaat doorgaans uit meerdere werkbladen, elk samenvattend over een bepaalde metriek.</ P >< H2 id = "toc-hId--486746840">SamenvattingswerkbladDe eerste pagina vermeldt enkele gegevens die het volgende beschrijven:<\/SPAN><\/SPAN><\/P>- De datum waarop het rapport is gegenereerd<\/SPAN><\/SPAN><\/LI>Het analysetype van het rapport<\/SPAN><\/SPAN><\/LI>Specifiek logpad<\/SPAN><\/SPAN><\/LI>Start- en eindtijden<\/SPAN><\/SPAN>Query<\/SPAN><\/SPAN><\/LI>Data<\/SPAN><\/SPAN><\/LI><\/UL><\/LI>Hoogwaardige logquery- en verzoekstatistieken<\/SPAN><\/SPAN><\/LI><\/UL>
Statistieken per methode werkbladHet werkblad Statistieken per methode is een uitsplitsing van verzoeken en reacties per functie die helpen enkele van de belangrijkste vragen van de taak te beantwoorden:<\/P>Welke methoden (ook wel functies of operaties genoemd) werden aangeroepen?query, applyEdits, updateSubnetwork? <\/LI><\/UL><\/LI>Hoe presteerden de services? <\/LI><\/UL>De tabel op dit werkblad biedt veel informatie. De standaardweergave sorteert de tijdkolommen op grootste Somwaarde. Som is afgeleid van de "request<\/EM> occurrence (Count column) * average response time (Avg column)",<\/EM> wat de service en operatie benadrukt waar de servers de meeste tijd aan besteedden om reacties te vervullen. <\/P>
Opmerking: Reactietijden worden alleen ter demonstratie weergegeven. Reactietijden voor elke implementatie zijn uniek omdat prestaties door veel factoren worden beïnvloed.<\/STRONG>Opmerking: De tabelweergave voor daadwerkelijke implementatie kan veel groter zijn met meer services en extra gerapporteerde functies.<\/STRONG>Naast Som, Aantal en Gemiddelde worden de volgende statistieken weergegeven om een dieper inzicht te geven in hoe de services en functies presteren:<\/FONT>Min<\/FONT>Minimum, de laagste of snelste reactietijdwaarde die is waargenomen voor die functie (van die servicebron)<\/FONT> <\/UL>
- P50<\/FONT>
- De 50e percentiel; 50% van de reactietijdgegevens voor die functie (van die servicebron) vallen op of onder dit punt <\/FONT>
<\/UL>
- P95<\/FONT>
- De 95e percentiel; 95% van de reactietijdgegevens voor die functie (van die servicebron) vallen op of onder dit punt<\/FONT>
<\/UL>
- P99<\/FONT>
- De 99e percentiel; 99% van de reactietijdgegevens voor die functie (van die servicebron) vallen op of onder dit punt<\/FONT>
<\/UL>
- Max<\/FONT>
- Maximum, de hoogste reactietijdwaarde die is waargenomen voor die functie (van de servicebron)<\/FONT>
<\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/>- Stdev
Een klein aantal verzoeken in de grotere tijdssegmenten geeft aan dat er enkele langer lopende functies zijn
- Misschien kan dit worden afgestemd
- Functie-invoer (bijv. de parameters van het verzoek) kan ook een factor zijn
Als de services toegewijd zijn (zoals bij Utility Network-services het geval is) en ze zijn geconfigureerd met het juiste aantal instanties
- Configuratie-afstemming kan worden geëlimineerd
De algemene gebruikerservaring:
- Is gerelateerd aan de gebruikte functies en hun respectievelijke prestatieprofiel
Opmerking: Er zijn verschillende factoren die een rol kunnen spelen bij serviceprestaties:
- Aantal instanties
- Alleen beschikbaar bij toegewijde services
- De gegevens
- De aangeroepen methoden
- Evenals gebruikte parameters
- Implementatiearchitectuur
- Beschikbare hardwarebronnen
- Vraag (bijv. gelijktijdige verzoeken)
Het afstemmen van deze kenmerken om de prestaties aan te passen valt buiten de reikwijdte van dit artikel.
Lograpport
Het gegenereerde lograpport maakte het gemakkelijker om de vragen voor de taak te beantwoorden.
Welke services waren het populairst?
- Naperville_Electric was het populairst, gevolgd door Naperville_Overlay
Welke functies werden aangeroepen?
- Er werden veel verschillende methoden aangeroepen: verschillende ruimtelijke queries, applyEdits, updateSubnetwork, trace, validateNetworkTopology, reconcile en post.
Hoe presteerden de services?
- Uiteindelijk kan deze definitie per organisatie verschillen
- Het is meestal gebaseerd op een criterium of overeenkomst die een verwachting voor elke service en operatie vermeldt
- Echter, uit het System Log Parser-rapport:
- Konden serviceprestaties worden geïdentificeerd en een statistisch profiel voor elke operatie (per service) worden gezien
- Besluitvorming ter ondersteuning van onderhouds- en afstemmingsmogelijkheden
Samenvatting
Uit de ArcGIS Enterprise-loganalyse werd een rapport gegenereerd dat de aanvraag- en responsactiviteit van de Utility Network-implementatie samenvatte.
De analyse en prestatieverdeling kwamen van System Log Parser. System Log Parser is een gratis tool voor Windows en wordt ook vermeld in de Well Architected Systems tools sectie.
Het rapport leverde statistische gegevens om vragen over de Site te beantwoorden zoals:
- Wat was de populairste service
- Welke methoden werden door deze services aangeroepen
- Hoe de services presteerden en of de Site goed werd beheerd
- Dit kon worden beantwoord
- In combinatie met prestatie-doelen van de organisatie
- Op basis van oordeel vanuit ervaring
Echter, ondanks dat de analyse en taak voltooid zijn...is je werk nog niet klaar!
De beste Site-analyse komt van periodiek evalueren van de implementatie, omdat:
- Gebruikstrends veranderen in de loop van de tijd
- Sommige services kunnen populairder worden, andere minder
- Een potentiële kans om toegewijde serviceconfiguraties te optimaliseren
- Je wilt historische kennis opbouwen over het prestatiegedrag van de Site
- Begrijpen hoe functies presteren vanuit de services kan helpen identificeren wanneer gedragingen en/of patronen ongewoon of afwijkend lijken
- Dit kan helpen bij probleemoplossing en afstemming
- Kan helpen benadrukken wanneer de services en functies
- Optimaal zijn
- Niet optimaal zijn
P>Systeem Log Parser regelmatig uitvoeren (bijv. eens per maand) kan je helpen een historisch begrip op te bouwen van de prestaties van je Site. Dit artikel richtte zich op het analyseren van een Site met Utility Network-services maar de praktijk en strategieën kunnen worden toegepast op elke GIS-implementatie.
