ArcGIS Enterprise Logy a System Log Parser
Zatímco existuje několik Community Articles, které diskutují analýzu logů ArcGIS Enterprise a jak začít se System Log Parser:
Existuje málo zdrojů, které podrobně popisují generovanou zprávu ve formě tabulky a jak na základě poskytnutých informací o výkonu činit rozhodnutí jako GIS administrátor a/nebo vývojář.
Tento článek vás provede, jak provést analýzu logů nasazení Utility Network, která pak může být použita k získání znalostí o využití a efektivitě Site.
Analýza výkonu logů ArcGIS Enterprise
Než začneme, pojďme si shrnout, co je analýza logů a kde lze taková data najít v nasazení ArcGIS.
Analýza logů:
Proces extrakce informací z dat logu. Tyto informace mohou být použity k kvantifikaci využití GIS a pomoci odpovědět na:
- Jaké služby uživatelé požadují?
- Jaké operace provádějí?
- Jaký výkon zažívají?
Data logu:
Data logu k analýze jsou logy ArcGIS Enterprise. Typicky tato data sídlí na serverech nasazení a existují v různých formách:
- Logy přístupu ArcGIS Web Adaptor
- Zdrojem dat logu použitým v tomto článku
- Logy přístupu ArcGIS Server
- Logy generované ArcGIS Pro
Každý zdroj logu nabízí své vlastní bohatství informací.
Ukázkový scénář pro analýzu logů
Následující scénář je případ použití naší analýzy logů:
Váš manažer vám zadal úkol:
Kvantifikovat ArcGIS Utility Network využití a efektivitu vašeho Site
To znamená, že je potřeba odpovědět na následující otázky:
- Je Site dobře spravován a optimální?
- Které služby jsou nejoblíbenější?
- Které metody jsou volány?
- query, applyEdits, updateSubnetwork
- Jak služby fungují?
- Celková uživatelská zkušenost?
Náš manažer také požádal, aby byla taková analýza provedena nákladově efektivním způsobem.
Poznámka: Před zahájením analýzy logů se doporučuje odkázat na jakékoli výkonnostní cíle, které již mohou existovat pro vaši organizaci. Taková kritéria mohou uvádět očekávaný výkon pro specifické operace během daného časového období. To vám může pomoci odpovědět, jak vaše služby fungují vzhledem k vašemu nasazení.
Proč provádět analýzu logů?
Máme úkol, ale proč procházet logy? Proč provádět analýzu logů?
Abychom rozpoznali využití Site a efektivitu nasazení Utility Network, osvědčenou strategií je poražení výkonu požadavků a využití prostřednictvím logů.
Tato metoda má několik výhod:
- Snadné provedení
- Rychlé provedení
- Velmi pravděpodobné, že data již existují k analýze
- Nevstupné čtení
- Může mít minimální náklady na serverové zdroje
Logy ArcGIS Enterprise (logy přístupu ArcGIS Web Adaptor nebo logy ArcGIS Server) mohou poskytnout cenný záznam klientských požadavků a odpovědí serveru. Tato data představují silný a přesný pohled do minulosti.
Jak provést analýzu?
Strategie této analýzy je přímočará:
- Zpracovat logy nasazení
- Extrahovat informace o požadavcích
- Generovat statistiky o výkonu služeb a funkcí
Data z logu lze rychle číst a analyzovat pomocí bezplatného nástroje: System Log Parser
System Log Parser je nástroj pro zpracování logů, který lze spustit přes grafické uživatelské rozhraní (GUI) nebo příkazový řádek (pro automatizované skriptování). Je kompilován pro platformu Windows.
Strategie analýzy logů
Který zdroj logu by měl být použit pro analýzu?
Pro nasazení může existovat několik zdrojových možností:
- ArcGIS Enterprise
- Logy přístupu ArcGIS Web Adaptor
- Microsoft Internet Information Services (IIS)
- Apache Tomcat
- Cloud
Mohou také existovat možnosti přístupu:
- Přístup přes web
- Přístup přes lokální síť
- Přístup přes lokální souborový systém
Každý zdroj logu má jedinečné silné stránky a i když může existovat několik zdrojů pro nasazení, doporučuje se vybrat jeden a použít jej jako primární zdroj pro analýzu (např. logy přístupu ArcGIS Web Adaptor).
Pro tento článek bude zdrojem dat čtení logů přístupu ArcGIS Web Adaptor přes lokální síť.< / STRONG >
Poznámka: Většina formátů logů je nezávislá na operačním systému a standardizuje sloupce dat. Logy ArcGIS Server následují tento vzor.< / STRONG >
Spouštění System Log Parser< / h1 >Grafické uživatelské rozhraní< / h2 >Snadné použití a konfigurovatelné.< / p >Možnosti:< / p >Vybrat zdroj logu< / strong >Internet Information Services Log Query< / li >Nastavit cestu umístění logu< / strong >Lokální: C:\inetpub\logs\LogFiles\W3SVC1Lze také specifikovat sdílené síťové umístění: \\server1.yourdomain.org\w3svc1< / li >Nastavit časové rozmezí< / strong >Místní čas< / li >Nastavit typ analýzy na Optimized (výchozí)< / strong >Rychlé a paměťově efektivní na stroji spouštějícím System Log Parser< / li >Analyzovat logy!< / strong >
< / span >Automatizace příkazového řádku< / h2 >Stejná funkčnost jako GUI, ale s větší flexibilitou. Ideální pro pravidelné generování automatizovaných zpráv (např. Windows Scheduled Task).< / p >Ukázka PowerShell:< / p >Vybrat zdroj logu< / strong >-f IIS< / li >Nastavit cestu umístění logu< / strong >Lokální: C:\inetpub\logs\LogFiles\W3SVC1Lze také specifikovat sdílené síťové umístění: \\server1.yourdomain.org\w3svc1< / li >Nastavit časové rozmezí< / strong >Čas v UTCLze zadat konkrétní hodnotu datetime< / li >-startstring "[Start_DateTime_UTC]"< / li >-endstring "[End_DateTime_UTC]"< / li >Nastavit typ analýzy na Optimized< / strong >-a Optimized< / li >Analyzovat logy!< / strong >PS C:\> # Spustit System Log Parser přes PowerShell
PS C:\> $startLocal = $endLocal = Get-Date # Nyní
PS C:\> $startLocal = $startLocal.AddDays(-7) # Jít zpět 7 dní
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" # Může být také \\server1\W3SVC1
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 falsePoznámka: Pokud je velikost vašich dat z logu neznámá, doporučuje se začít s menším dotazovacím oknem (např. 1 hodina nebo 6 hodin), dokud nebude pochopen relativní čas výpočtu. < / STRONG >Zpráva z logu -- Porozumění výstupu System Log Parser< / SPAN >
Ve výchozím nastavení je generovaná zpráva založená na tabulkách. Vytváří soubor XLSX, což je dokument Open Office XML. Zpráva obvykle obsahuje několik listů, z nichž každý shrnuje konkrétní metriku.< / SPAN >
Souhrnný list
Úvodní stránka uvádí některé informace podrobně popisující:
- Datum vytvoření zprávy
- Typ analýzy zprávy
- Specifikovaná cesta k logu
- Časy začátku a konce
- Statistiky dotazů do logu a požadavků na vysoké úrovni
List Statistiky podle metody
List Statistiky podle metody je rozpis požadavků a odpovědí podle funkcí, který pomáhá odpovědět na některé z hlavních otázek úkolu:
- Které metody (také označované jako funkce nebo operace) byly volány?
- query, applyEdits, updateSubnetwork?
- Jak si služby vedly?
Tabulka na tomto listu poskytuje mnoho informací. Výchozí zobrazení třídí sloupce času podle největší hodnoty Sum. Sum je odvozeno z "request occurrence (Count column) * average response time (Avg column)", což zdůrazňuje službu a operaci, na které servery strávily nejvíce času při plnění odpovědí.
Poznámka: Časy odezvy jsou zobrazeny pouze pro demonstrační účely. Časy odezvy pro každé nasazení jsou jedinečné, protože výkon ovlivňuje mnoho faktorů.
Poznámka: Tabulkové zobrazení dat pro skutečné nasazení může být mnohem větší s více službami a dalšími hlášenými funkcemi.
Kromě Sum, Count a Average jsou zobrazeny následující statistiky, které pomáhají poskytnout hlubší pochopení toho, jak služby a funkce fungují:
- Min
- Minimum, nejmenší nebo nejrychlejší hodnota času odezvy pozorovaná pro tuto funkci (z tohoto zdroje služby)
- P50
- 50. percentil; 50 % dat o čase odezvy pro tuto funkci (z tohoto zdroje služby) je na nebo pod touto hodnotou
- P95
- 95. percentil; 95 % dat o čase odezvy pro tuto funkci (z tohoto zdroje služby) je na nebo pod touto hodnotou
- P99
- 99. percentil; 99 % dat o čase odezvy pro tuto funkci (z tohoto zdroje služby) je na nebo pod touto hodnotou
- Max
- Maximum, nejvyšší hodnota času odezvy pozorovaná pro tuto funkci (ze zdroje služby)
- Stdev
- Směrodatná odchylka, výpočet rozptylu nebo variability časů odezvy pro tuto funkci (ze zdroje služby)
Tabulka zdůrazňuje, že funkce query byla nejoblíbenější volanou metodou. Podle výpočetního času nasazení byly tři nejlepší operace všechny query (např. MapServer, FeatureServer a Hosted) napříč dvěma různými službami (Naperville_Electric a Naperville_Overlay).
Podíváme-li se na sloupec Avg, průměrný čas odezvy (v sekundách) těchto funkcí query je shrnut a všechny tři byly podsekundové (což znamená méně než 1 sekundu).
S identifikovanými metodami query jsme v tabulce našli i další zajímavé funkce applyEdits a updateSubnetwork.
Podíváme-li se na další zajímavé funkce, můžeme pozorovat applyEdits a updateSubnetwork. Průměrně měla applyEdits podsekundové časy odezvy a updateSubnetwork trvala několik sekund.
- Tato tabulka pomáhá odpovědět na otázku, které metody byly volány
- Byl nalezen profil výkonu pro tři různé queries spolu s applyEdits a updateSubnetwork.
- Další funkce byly přítomny jako trace, reconcile a post.
- Co se týče výkonu dvou hlášených služeb, jednoznačná odpověď na tuto otázku se může lišit podle organizace:
- Obvykle založeno na existujících kritériích výkonu pro službu, funkci a metriku
- Počáteční běhy System Log Parseru poskytnou pochopení aktuálně vybraného časového rámce
- Toto by mělo poskytnout dobrý celkový vzorek
- Pravidelné spouštění System Log Parseru vám umožní porovnat změny ve výkonnostních profilech
- Pokud jsou v následných zprávách pozorovány neobvyklé chování, může být nutné vyšetřování nebo revize
< FONT color = "#FF0000" >< STRONG > Poznámka: Obvykle ne všechny metody sledují stejná kritéria výkonu. Každá funkce vykonává jinou práci než ostatní. Funkce feature query by měla jiný profil výkonu než updateSubnetwork.</ STRONG ></ FONT ></ P >
List Počty požadavků podle zdroje </ H2 >< P > List Počty požadavků podle zdroje je jednoduchý pohled na to, které služby byly nejoblíbenější. Celkové počty jsou rozděleny do dvou skupin:</ P >< UL >< LI > Požadavky na zdroj (požadavky založené na metodách)< UL >< LI > Uvádí počty založené na požadavcích využívajících známé funkce služeb (podobné součty jako v listu Statistiky podle metody)</ LI ></ UL ></ LI >< LI > Požadavky na zdroj (požadavky založené na metodách a koncových bodech služeb)< UL >< LI > Uvádí počty založené na požadavcích využívajících známé funkce služeb a požadavky na REST koncové body služeb, které obvykle získávají metadata (podobné součty jako v listu Capability - Server)
</ LI ></ UL ></ LI ></ UL >< P >< span class = "lia-inline-image-display-wrapper lia-image-align-center" image-alt = "report4a.png" style = "width: 997px;" >< img src = "https://us.v-cdn.net/6038851/uploads/images/149234i5F6C299E03D4CDFA/report4a.png" role = "button" title = "report4a.png" alt = "report4a.png" / ></ span ></ P >< P > Tato tabulka může pomoci odpovědět na zbývající otázky úkolu:</ P >< UL >< LI > Které služby jsou nejoblíbenější?</ LI ></ UL >< P > Na základě sloupců Source a Total vidíme, že Naperville_Electric je nejvíce požadovaný zdroj.</ P >< H2 id = "toc-hId--1614142933" > List Capability - Server </ H2 >< P > List Capability -- Server je alternativní pohled na hodnocení výkonu služby. Uvádí rozpis podle Capability a Source, ale metoda je odstraněna. Bez rozdělení podle metody je celkový počet požadavků u mnoha služeb vyšší. Je to proto, že mohou existovat požadavky na službu, které nevolají žádnou funkci. Některé požadavky pouze volají metadata služby nebo vrstvy.</ P >< P > Místo statistického pohledu na výkon požadavků jsou časy seskupeny do intervalů doby odezvy. Tyto intervaly sestávají z rozsahu trvání (např. 0-1 sekunda nebo 6-10 sekund). Tento zjednodušený pohled usnadňuje vidět, kde se čas tráví.</ P >< P > V následujícím příkladu jsou zvýrazněny dva intervaly času. I když představovaly malý procentní podíl celkového počtu požadavků MapServeru, upozorňují na možnost ladění pro správce GIS a/nebo vývojáře, kteří mohou rozhodnout, zda byly množství a hodnoty přijatelné.</ P >< P >< span class = "lia-inline-image-display-wrapper lia-image-align-center" image-alt = "report3d.png" style = "width: 999px;" >< img src = "https://us.v-cdn.net/6038851/uploads/images/149248i91D2BD3DD2A14858/report3d.png" role = "button" title = "report3d.png" alt = "report3d.png" / ></ span ></ P >< P >< FONT color = "#000000" >< FONT color = "#FF0000" >< STRONG > Poznámka: Časy odezvy jsou zobrazeny pouze pro demonstrační účely. Časy odezvy pro každé nasazení jsou jedinečné, protože výkon ovlivňuje mnoho faktorů.</ STRONG ></ FONT ></ FONT ></ P >< P > Tato tabulka může pomoci odpovědět na zbývající otázky úkolu:</ P >< UL >< LI > Je lokalita dobře spravována a optimální?</ LI >< LI > Celková uživatelská zkušenost</ LI ></ UL >< P > Dobře spravovaná a optimální lokalita znamená:</ P >< UL >< LI > Většina provedených operací byla rychlá nebo v rozsahu považovaném za dobrý/přijatelný< LI >„Rychlé“ a „v rozsahu“ jsou subjektivní kvantifikace a nejlépe je odpovídají předem stanovená kritéria výkonu vaší organizace</ LI >< LI >Další perspektiva je použití vašeho nejlepšího úsudku z praxe</ LI ></ UL ></ LI >< LI >A malý počet požadavků ve větších časových intervalech naznačuje, že existují některé funkce s delší dobou běhuMožná by to šlo doladitVstup do funkce (např. parametry požadavku) může být také faktoremPokud jsou služby dedikované (jako je tomu u Utility Network služeb) a jsou nakonfigurovány s odpovídajícím počtem instancíLadění konfigurace by mohlo být eliminovánocelková uživatelská zkušenost:Souvisí s vykonávanými funkcemi a jejich příslušným výkonovým profilemPoznámka: Existuje několik faktorů, které mohou ovlivnit výkon služby:Počet instancíDostupné pouze u dedikovaných služebDataVolané metodyStejně jako použité parametryArchitektura nasazeníDostupné hardwarové zdrojePoptávka (např. současné požadavky) Ladění těchto charakteristik pro úpravu výkonu je mimo rozsah tohoto článku.Zpráva z protokoluVygenerovaná zpráva z protokolu usnadnila odpovědi na otázky pro úkol.Které služby byly nejoblíbenější?Naperville_Electric byla nejoblíbenější, následovaná Naperville_OverlayKteré funkce byly volány?Bylo voláno mnoho různých metod: několik prostorových dotazů, applyEdits, updateSubnetwork, trace, validateNetworkTopology, reconcile a post. Jak si služby vedly?Konečně, tato definice se může lišit podle organizaceObvykle je založena na kritériích nebo dohodě, která uvádí očekávání pro každou službu a operaciAle ze zprávy System Log Parser:Bylo možné identifikovat výkon služby a vidět statistický profil pro každou operaci (podle služby)Podpora rozhodování pro údržbu a možnosti laděníShrnutíZ analýzy protokolů ArcGIS Enterprise byla vygenerována zpráva shrnující aktivitu požadavků a odpovědí nasazení Utility Network.Analýza a rozbor výkonu pocházely ze System Log Parser. System Log Parser je bezplatný nástroj pro Windows a je také uveden v sekci Well Architected Systems tools section.Zpráva poskytla statistická data k zodpovězení otázek o lokalitě, jako například:Která služba byla nejoblíbenějšíKteré metody byly volány těmito službamiJak si služby vedly a zda byla lokalita dobře spravovánaToto bylo možné zodpovědětVe spojení s výkonnostními cíli organizaceNa základě úsudku založeného na zkušenostech Ale i přes dokončení analýzy a úkolu...vaše práce nekončí!Nejlepší analýza lokality pochází z periodického hodnocení nasazení, protože:Trendy využití se v čase měníNěkteré služby mohou být populárnější, jiné méněPříležitost k optimalizaci konfigurací dedikovaných služebChcete si vybudovat historické znalosti o chování výkonu lokalityPochopení toho, jak funkce fungují ve službách, může pomoci identifikovat, kdy se chování a/nebo vzory jeví jako neobvyklé nebo nevhodnéToto může pomoci při řešení problémů a laděníMůže pomoci zdůraznit, kdy jsou služby a funkceOptimálníNení optimálníPravidelné spouštění System Log Parser (např. jednou za měsíc) vám může pomoci vybudovat historické porozumění výkonu vaší lokality. Tento článek se zaměřil na analýzu lokality s Utility Network službami, ale praxe a strategie by mohly být aplikovány na jakékoli GIS nasazení.
