Application Insights - FAQ 2016 - 2018

Zatěžují Application Insights nějak výrazně aplikaci?

Zátěž je naprosto zanedbatelná. Pro sběr telemetrií je minimální režie (jednotky milisekund), telemetrie se ukládají do bufferu (v paměti) a v časových intervalech nebo při dosažení velikosti bufferu se hromadně serializují a odešlou asynchronně proti App Insight API.

Proč u některých aplikací nevidím SQL dotazy v závislostech?

Může to mít několik příčin. Záleží na webovém frameworku a jeho verze, na verzi .NET Frameworku a na verzi Application Insights SDK. Ideální verze .NET Frameworku je alespoň 4.6 a k němu nejnovější verze AI SDK. Dále je nutné mít správně nastavenou verzi .NET Frameworku ve web.config. V případě ASP.NET Core aplikací doporučuji verzi ASP. NET Core 2.1 a verzi AI SDK alespoň 2.2.

Lze si nějak připojit ke všem telemetriím globální vlastnosti?

Je možné napsat si TelemetryInitializer, skrze který všechny telemetrie "protečou". Ke každé je pak možné připojit libovolné vlastnosti, které se pak zobrazují i v Azure Portálu. Více naleznete v článku:

• Filtering and preprocessing telemetry in the Application Insights SDK

Jak posílat data do App Insights, když aplikace běží na našem serveru, který běží za firewallem?

Je potřeba povolit na firewallu IP adresy pro odchozí traffic z aplikace. Seznam IP adres je dostupný v dokumentaci:

• IP addresses used by Application Insights and Log Analytics

Další řešení je změnit si tzv. EndpointUrl a posílat si telemetrie na vlastní URL (RESTové API), telemetrie sesbírat a poté je ručně přeposílat do Application Insights. Oficiálně na to není dostupný žádný nástroj a osobně neznám nikoho, kdo by toto řešení prakticky provozoval.

Dají se odhadnout náklady na provoz?

Prakticky velmi těžko, spíše vůbec. Základním měřítkem je množství místa, které zabírají odeslané telemetrie a nelze předem predikovat, kolik telemetrií bude odesláno. Lze však přímo v portálu přejít do záložky Usage and Estimated Costs a na ní se podívat na množství sesbíraných telemetrií v čase. Snadno lze tak odhadnout, zda se vejdete do kvót pro provoz zdarma nebo si spočítat, kolik dodatečného místa budete potřebovat.

Použil jsem konfiguračního průvodce ve Visual Studio a nesbírají se mi telemetrie

Konfigurační průvodce ve VS je 90% svého času zabugovaný a obvykle neprovede konfiguraci korektně. V současné době je tento problém signifikantní u ASP.NET Core aplikací. V případě ASP.NET aplikací je většinou konfigurace korektní.

U aplikací ASP.NET Core je nutné kontrolovat:

• registraci do pipeline v Program.cs hledejte UseApplicationInsights()
• přítomnost InstrumentationKey v appsettings.json
• přítomnost měřícího kódu v Layout.cshtml (něco ve smyslu JavascriptSnippet.FullScript)

U aplikací ASP.NET (MVC) je nutné kontrolovat:

• registraci HTTP modulu ve web.config
• existenci konfiguračního souboru ApplicationInsights.config
• nastavení InstrumentationKey v ApplicationInsights.config
• přítomnost měřícího kódu v Layout.cshtml (JS kód obsahující InstrumentationKey)

Je posílání dat bezpečné? Speciálně s ohledem na GDPR?

Na zabezpečení dat musíte myslet sami. Citlivá data je vhodné neposílat nebo je posílat v takové podobě, aby byla čitelná jen oprávněnou osobou. Povaha dat by měla korelovat s úrovní zabezpečení. Osobní a citlivé údaje je pokud možné vhodné neposílat vůbec (telemetrie zahazovat přímo v aplikaci).

Alternativní řešení je by default Application Insights nepoužívat k zasílání všech telemetrií a explicitně si odesílat jen to, co vyloženě potřebujete a míte pod kontrolou. Čili ručně pomocí TelemetryClient.

Nemůže být služba nějak zneužita, když je klíč k App Insights veřejně vidět?

Ano, existuje riziko, že někdo bude proti vaší službě posílat nesouvisející data. Na druhou stranu z toho "záškodník" nic moc mít nebude. V praxi jsem se nesetkal s tím, že by někdo někomu takto škodil. Princip je analogický ke službě Google Analytics.

Na přednášce jste mluvil o vlastních metrikách, ale když si je odesíláme do Azure, nikde je nevidíme

Vlastní metriky jsou vidět v sekci Search. Od jisté době custom metriky zmizely z některých dalších grafů. Je nutné se k nim dostat pomocí vlastních analytických dotazů. Dostupné jsou v rámci agregované vlastnosti customMeasurements. Příklady jsou dostupnév dokumentaci:

• Application Insights API for custom events and metrics

Lze posílání telemetrií pro různá vývojářská prostředí vypínat nebo zapínat?

Dobrá praktika je nastavovat InstrumentationKey pro každé prostředí separátně. Pokud z konkrétního prostředí nechcete data sbírat, jednoduše neuvedete žádný InstrumentationKey. Další možností je přidat si do konfigurace bool přepínátko a to následně použít v rámci Startupu aplikace nastavením

TelemetryConfiguration.Active.DisableTelemetry = true;

Jak se SDK integruje do webové aplikace?

V případě ASP.NET aplikací se používá HTTP modul, v případě ASP.NET Core pak custom middleware. V obou případech se provede registrace nezbytných služeb a následně se do paměti načte konfigurace. Pokud není k aplikaci přístup, ale použije se Status Monitor nebo rozšíření v Microsoft Azure, pak toto rozšíření zpravidla SDK stáhne a pokusí se konfiguraci provést aktualizací vhodných souborů.

Je někde v Azure AI vidět referrer URL?

Pokud vím, tak není. JavaScript SDK ale umožňuje připojit si k telemetriím vlastní properties podobně, jako je tomu u .NET SDK. V Layoutu webu (nebo masterpage) je klientský kód Application Insights zakončený voláním appInsights.trackPageView(). Toto volání je možné doplnit o property referrer:

appInsights.trackPageView(null, null, { referrer: document.referrer });

Můžu se v App Insights na Azure dívat na obsah requestu v případě POST metody na RESTovém API?

Doporučuji si napsat pro podobné scénáře vlastní Telemetry Initializer. V rámci něj se dívat na telemetrie typu Request / POST a následně si z Body requestu vytáhnout data a uložit je do speciální property nad danou request telemetrií. U větších dat bude zřejmě nutné ukládat BODY do samostatné telemetrie typu trace.

U ASP.NET Core to lze řešit elegantně vlastním middlewarem, který by pro POST requesty na API rovnou vyráběl Trace telemetrie. Ty budou automaticky svázané s aktuální Request telemetrií.

Je možné App Insights použít ve WinForm aplikaci?

Ano, byť většina zajímavých funkcí typických pro webová prostředí zde nebude mít uplatnění. V případě WinForms aplikací lze použít přímo TelemetryClient třídu pro odesílání vlastních telemetrií. V praxi bude nutné se "pověsit" na událost vzniku chyby a v rámci ní pak lze globálně odesílat telemetrie v případě vznikajících chyb. Mělo by se jednat o událost typu AppDomain.CurrentDomain.UnhandledException. Dost možná existují i hotová řešení na NuGetu.

Jsou Application Insights náhradou za Google Analytics?

Každá z těchto služeb je určená na něco jiného. Google Analytics je spíše pro marketingovou analýzu, zatímco Application Insights jsou pro pochopení toho, co se v aplikaci děje, pro identifikaci chyb a performance potíží. Součástí App Insights je kvalitní a stále se zlepšující přehled o uživatelích a jejich chováních. Je to však spíše doprovodná analýza a AI nemají ambice suplovat nebo nahrazovat Google Analytics.

Dá se zkrátit zpoždění než se objeví data v Azure portálu?

Bohužel to možné není. Z aplikace lze telemetrie odesílat relativně rychle (v debug módu se posílají automaticky jedna po druhé). V portálu ale trvá propsání i několik minut. O něco rychleji jsou telemetrie vidět ve Visual Studio Application Insights.

Je možné sledovat dotazy a závislosti do Redis?

Pokud se nic nezměnilo, tak to možné není. Modul pro sběr závislostí nepodporuje protokol RESP, který Redis používá pro komunikaci. Jediné nepraktické řešení je owrapovat klienta pro práci s Redis a posílat si telemetrie ručně pomocí Application Insights SDK.

Nechápu rozdíl mezi Exception a Failure v grafech

Pojem Exception odkazuje na skutečnou aplikační výjimku, zatímco Failure indikuje obecně selhání. Může se jednat o selhání nad operací (HTTP volání) nebo například závislostí (SQL volání). V rámci jedné operation může vzniknout několik Exceptions, avšak pokud jsou všechny ohandlované, pořád ještě může operace dopadnout úspěšně (status code 200) a nedojde k selhání (Failure). Failure většinou reflektuje slehání, které viditelně pocítí uživatel, zatímco Exception ještě nemusí mít nutně negativní projev v chování aplikace.

Lze nastavit InstrumentationKey dle konkrétních uživatelů?

Tento postup není podporování a ani jen nedoporučuji. Dotaz vzešel od vývojáře na konferenci a ukázalo se, že jeho cílem bylo jen rozlišovat uživatele (vývojáře, reálné). Pak doporčujji použít TelemetryInitializer a připojit si ke každé telemetrii speciální vlastnost indikující o jaký typ uživatele se jedná. Druhá možnost je použít TelemetryProcessor a v případě vývojáře telemetrie úplně zahazovat. Záleží na potřebě. Balancovat telemetrie do různých AI dle InstrumentationKey za běhu dopadne s jistotou špatně.

Proč nevidím v App Insights žádné informace o CPU a serveru?

Metriky typu Process CPU / Available Memory v sekci Servers se sbírají jen v závislosti na verzi .NET Frameworku a verzi Application Insights SDK. Pokud máte ASP.NET Core aplikaci, pak se tyto metriky pokud vím zatím (ve verzi ASP.NET Core 2.1) nesbírají. U ASP.NET aplikací bude problém buď ve starší verzi .NET Frameworku (např.: 3.x, 4.5) nebo vypnutím modulu PerformanceCounterCollector (měl by být vidět v ApplicationInsights.config). Dodatečným řešením může být instalace Status Monitoru na webový server nebo aktivace rozšíření Application Insights v Azure App Service.

Je možné vypnout sběr SQL závislostí?

Lze to více způsoby. Pro zahození konkrétních telemetrií je ideální TelemetryProcessor a v rámci něj se dívat na každou telemetrii, zda je typu Dependency / SQL. U klasických ASP.NET aplikací lze sáhnout do ApplicationInsights.config souboru a provést konfiguraci DependencyTrackingTelemetryModule v rámci registrace. Zda lze vypnout tímto způsobem pouze sběr SQL dependencies nemám vyzkoušeno.

Jaký je rozdíl mezi traceEvent a traceTrack? Co použít pro uložení serializovaného objektu?

Událost "event" se používá pro uložení krátkého popisu události která nastala. Události lze na mnoha místech v Azure používat pro sledování uživatelského chování. Lze například sledovat tok uživatelů mezi stránkami a událostmi. "Track" je telemetrie, která je naopak vhodná pro zmíněou serializaci objektů nebo uložení většího objemu dat. I zde jsou limity co do velikosti obsahu zprávy dané telemetrie. Více o limitech se lze dočíst v dokumentaci (která v tomto případě není úplně aktuální).

• Azure subscription and service limits, quotas, and constraints

Napadá vás další dotaz, který v článku chybí? Napište dolů do diskuze nebo mi pošlete dotaz e-mailem.