Sběr dat v Application Insights pod mikroskopem

Data přitékají ze třech zdrojů

Ve světě ASP.NET aplikací sbírá služba Application Insights data na základě třech vstupů. Platí přitom, že tyto vstupy jsou na sobě nezávislé (synergičtější je samozřejmě používat všechny níže zmíněné možnosti najednou).

1. Monitoring aplikace

Prvním zdrojem dat je monitoring aplikace. Monitoring aplikace se nastavuje přímo v Azure portálu. Na základě jednoduchých ping testů nebo multi-step web testů si služba AI udržuje informace o dostupnosti webové aplikace z různých lokalit, response time a samotný obsah odpovědi. Data z monitoringu jsou čitelná v sekci Availability a pingování probíhá dle nastavení každých 5 / 10 / 15 minut.

Všechny události vyvolané robotem pro monitoring návštěvnosti jsou později označeny jako syntetický provoz a ve většině agregovaných grafických výstupů se s nimi dále nepracuje (pokud explicitně nechceme analyzovat syntetický provoz). Roboti bombardují aplikaci pingováním z desítek IP adres, které lze najít v dokumentaci.

2. Client side JavaScript kód

Druhým zdrojem telemetrií je JavaScriptový kód, který si vývojář zkopíruje z portálu a vlepí ho do layoutu stránky (master page). Výchozí kód definuje proměnou appInsights a na samotném konci volá událost appInsights.trackPageView(); Logování událostí se v tomto případě provádí v reálném čase voláním endpointu dc.services.visualstudio.com/v2/track. Data získaná z klienta se zobrazují v sekcích Browser a Usage v Azure portálu.

Dále je možné se získanými daty pracovat v různých grafech například při filtrování. Mezi nejčastější "artefakty" zobrazené v Diagnostic Search patří:

• PageViews
• Exceptions (JavaScript)
• Dependencies (AJAX calls)

3. Application Insights SDK

Posledním a nejvydatnějším zdrojem dat je samozřejmě SDK, které si vývojář typicky instaluje přes NuGet. Toto SDK je konfigurovatelné programově nebo skrze soubor ApplicationInsights.config. Protože je SDK plně modulární, lze si vydefinovat moduly, které mají být při sbírání dat aktivní (defaultně všechny). Každý modul má pak svá vlastní pravidla co se týče sběru dat.

Základní agent

SDK dekoruje všechny assemblies v aplikaci a používá vlastní callbacky (BeginCallback, EndCallback a ExceptionCallback) pro zjištění jak dlouho vyřešení jednotlivých požadavků trvá. Stejně tak je SDK schopné při vzniku neošetřené výjimky tuto výjimku přes ExceptionCallback zalogovat.

Logování se ukládá do TelemetryBufferu, jehož výchozí velikost je 500 telemetrií. V případě developer módu se buffer nastavuje na 1 telemetrii a data se tedy odesílají rychleji. O odesílání dat se stará TelemetryTransmitter za předpokladu, že je naplněn buffer nebo je překročen Flush interval (defaultně 30 sekund). Pokud se aplikace dostane do nesnází (například se ukončuje), pak se tyto vlastnosti ignorují a odeslání proběhne bez odkladu. Explicitně si lze vyžádat okamžité odeslání telemetrií i voláním metody Flush() nad instancí třídy TelemetryClient.

Do Application Insights se data posílají asynchronně POSTem proti endpointu dc.services.visualstudio.com/v2/track nebo dc.applicationinsights.microsoft.com ve formátu JSON s gzip kompresí. U on-premises řešení je nutné na tyto endpointy myslet v případě firewallu. Velikost jedné telemetrie je různá v závislosti na množství připojených dat (properties, metriky, callstack) a začíná průměrně někde na 1 kB.

V případě, že používáte funkci Live Metrics Stream, je dále nutné povolit na firewallu rt.services.visualstudio.com a rt.applicationinsights.microsoft.com.

Veškerá data sesbíraná pomocí SDK jsou přístupná především v sekcích Failures a Performance. V Diagnostic Search pak mají prakticky jakoukoliv podobu: Event, Trace, Exception, Dependency i PageView.

Dependencies

Vedle výchozího agenta je ve výchozím nastavení aktivní DependencyCollector. Ten má za úkol sledovat

1. Volání externích služeb (HTTP volání)
2. Volání databázových služeb (ADO.NET provider)

Všechna tato volání jsou automaticky označena jako závislosti a přidána do bufferu. I v tomto případě je DependencyCollector navěšen na události OnBegin.... / OnEnd... (např.: OnBeginForExcecuteReader) a tudíž dokáže spočítat jak dlouho vyřízení takové závislosti trvalo. V případě SQL závislostí umí získat i odeslaný SQL příkaz a u HTTP volání URL požadavku.

V případě HTTP volání umí DependencyCollector na základě URL rozeznat i řadu specifických volání a oflagovat je. Jedná se zejména o:

• Azure blob / table / queue calls
• WCF / Web service calls (.svc, .asmx..)

Data získaná touto cestou se v Diagnostic Search projevují jako Dependency.

Performance Counters (PerfCounterCollector)

Performance Counters sbírají zjednodušeně data o hardware: stavu CPU, operační paměti, práci disků etc. Dosavadní pravidla jsou taková, že vzorek stavu HW se pořizuje s využitím Timeru pravidelně každou 1 minutu a registrace těchto dat probíhá po 5 minutách. Data získaná z Performance Counters lze nalézt v sekci Servers.

Performance Counters - Quick Pulse (AI > 2.1.0-beta2)

Od verze Application Insights 2.1.0-beta2 byly PerfCounterCollectors rozšířeny o Quick Pulse. Ty nově sbírají data v téměř reálném čase a odesílají je do Azure kontinuálně. Tato data jsou následně viditelná v sekci Live Metrics Stream. Průměrně zpoždění se pohybuje kolem 1500 ms.

Status Monitor

Mnoho mýtů panuje kolem Status Monitoru. Ten primárně slouží pro účely, kdy není možné sáhnout do kódu aplikace a vývojářský tým chce přesto sbírat základní set diagnostických informací. Jeho výhodou je také schopnost sbírat informace o závislostech. Status Monitor se nainstaluje na webový server a pomocí grafického rozhraní přihlásí ke službě Application Insights.

Pokud aplikace běží na .NET >= 4.6 a je nainstalováno Application Insights SDK, pak není potřeba Status Monitor používat. Pokud aplikace běží na starší verzi .NETu, pak instalací Status Monitoru lze získat informace o závislostech (které starší verze .NETu sbírat neumí).

Jinými slovy, Status Monitor nainstaluji, pokud:

• nemohu instalovat SDK do mé aplikace, nebo
• mám v aplikaci SDK < 4.6 a chci sbírat data o závislostech

Výkonnost Application Insights

Dle dostupných měření ze strany vývojářů AI je impact na výkonnost webových řešení naprosto mizivý a projevit se může viditelněji jen za předpokladu trackování skutečně enormního množství dat.

Doufám, že jsem do fungování Application Insights vnesl více světla a těším se na komentáře a dotazy v diskusi.