Jak funguje sběr dat v Application Insights

Řada vývojářů se mě ptá na to, jak funguje sběr dat ve službě Application Insights, jak často se data odesílají do Azure a jaký je dopad na výkonnost. Poznatky a fakta se dočtete v tomto článku.

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. Na základě jednoduchých ping testů nebo multi-step web testů si služba AI udržuje informace o dostupnosti aplikace z různých lokalit, response time a samotném obsahu odpovědi. Data z monitoringu jsou čitelná pouze 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ě grafických výstupů se s nimi dále nepracuje (pokud explicitně nechceme analyzovat syntetický provoz). Roboti bombardují aplikaci z cca 50 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í primárně v sekcích Browser a Usage.

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.

Do Application Insights se data posílají asynchronně POSTem proti endpointu dc.services.visualstudio.com/v2/track ve formátu JSON s gzip kompresí. U on-premises řešení je nutné na tento endpoint myslet v případě aktivního 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.

Veškerá tato data jsou přístupná 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 odeslaný SQL příkaz a u HTTP volání URL požadavku.

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

Performance Counters

Performance Counters sbírají zjednodušeně data o hardware: stavu CPU, operační paměti, práci disků etc. Dosavadní pravidla byla taková, že vzorek stavu paměti se pořizoval s využitím Timeru pravidelně každou 1 minutu a registrace těchto dat probíhala po 5 minutách. Data získaná z Performance Counters lze nalézt v sekci Servers. Výjimkou je scénář aplikace nasazené do Azure App Service. V tomto případě data v Application Insights přístupná nejsou (diagnostiku lze ale najít přímo v nastavení služby Azure App Service).

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 reálném čase a odesílají je do Azure kontinuálně. Tato data jsou následně viditelná v Live Stream a označována jako Near-Real-Time. Průměrně zpoždění se pohybuje kolem 2000 ms. I zde platí, že u aplikací nasazených do Azure App Service nejsou k dispozici tzv. Server Health counters (stav paměti a CPU).

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řipojí 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í enormního množství dat nebo u prerelease SDK nepatrně vyšší spotřebou operační paměti (na druhou stranu s pozitivnějším impactem na garbage collection).

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. Miroslav Holec