Základy shromažďování dat ve službě Azure Monitor Application Insights
Článek
Než budete moct monitorovat aplikaci, je potřeba ji instrumentovat.
V následujících částech se zabýváme některými základy shromažďování dat služby Azure Monitor Application Insights.
Možnosti instrumentace
Na základní úrovni "instrumentace" jednoduše umožňuje aplikaci zachytit telemetrii.
Existují dvě metody instrumentace aplikace:
Automatická instrumentace (autoinstruace)
Ruční instrumentace
Automatická správa umožňuje shromažďování telemetrických dat prostřednictvím konfigurace bez zásahu do kódu aplikace. I když je pohodlnější, obvykle je méně konfigurovatelný. Není k dispozici ve všech jazycích. Viz podporovaná prostředí a jazyky pro automatickou správu. Pokud je k dispozici automatická aktivace, je nejjednodušší způsob, jak povolit Službu Application Insights služby Azure Monitor.
Ruční instrumentace se kóduje pro rozhraní Application Insights nebo OpenTelemetry API. V kontextu uživatele obvykle odkazuje na instalaci sady SDK specifické pro jazyk v aplikaci. To znamená, že aktualizace nejnovější verze balíčku musíte spravovat sami. Tuto možnost můžete použít, pokud potřebujete provádět vlastní volání závislostí nebo volání rozhraní API, která se ve výchozím nastavení nezachytí pomocí automatického vytváření. Existují dvě možnosti ruční instrumentace:
I když vidíme OpenTelemetry jako náš budoucí směr, nemáme žádné plány zastavit shromažďování dat ze starších sad SDK. Stále máme možnost, jak přejít, než naše distribuce Azure OpenTelemetry dosáhne parity funkcí s našimi sadami Application Insights SDK. V mnoha případech se zákazníci stále rozhodnou používat sady Application Insights SDK po určitou dobu.
Důležité
Ruční neznamená, že budete muset napsat složitý kód, který definuje rozsahy distribuovaných trasování, i když zůstává možností. Knihovny instrumentace zabalené do našich distribucí umožňují snadno zaznamenávat telemetrické signály napříč běžnými architekturami a knihovnami. Aktivně pracujeme na instrumentaci nejoblíbenějších sad SDK služby Azure pomocí OpenTelemetry , takže tyto signály jsou k dispozici zákazníkům, kteří používají distro OpenTelemetry služby Azure Monitor.
Typy telemetrie
Telemetrie, shromážděná data pro sledování vaší aplikace, je možné rozdělit do tří typů nebo "pilířů":
Distribuované trasování
Metriky
Protokoly
Kompletní příběh pozorovatelnosti zahrnuje všechny tři pilíře a Application Insights dále rozdělí tyto pilíře do tabulek založených na našem datovém modelu. Mezi naše sady SDK application Insights nebo distribuce OpenTelemetry pro Azure Monitor patří vše, co potřebujete k power application Sledování výkonu ing v Azure. Samotný balíček je zdarma k instalaci a platíte jenom za data, která ingestujete ve službě Azure Monitor.
Tři pilíře jsou vysvětlené v následujících zdrojích:
Existují dva způsoby, jak odesílat data do služby Azure Monitor (nebo jakéhokoli dodavatele):
Prostřednictvím přímého vývozce
Prostřednictvím agenta
Přímý exportér odesílá telemetrii v procesu (z kódu aplikace) přímo do koncového bodu příjmu dat služby Azure Monitor. Hlavní výhodou tohoto přístupu je jednoduchost připojování.
Aktuálně dostupné sady Application Insights SDK a distribuce OpenTelemetry služby Azure Monitor využívají přímý exportér.
Poznámka:
Informace o pozici služby Azure Monitor v kolekci OpenTelemetry najdete v nejčastějších dotazech k OpenTelemetry.
Tip
Pokud plánujete použít OpenTelemetry-Collector k vzorkování nebo dalšímu zpracování dat, možná budete moct získat tyto stejné funkce integrované do služby Azure Monitor. Zákazníci, kteří migrovali do Application Insights založené na pracovních prostorech, můžou těžit z transformací v čase příjmu dat. Pokud to chcete povolit, postupujte podle podrobností v kurzu a přeskočíte krok, který ukazuje, jak nastavit nastavení diagnostiky, protože u Application Insights zaměřeného na pracovní prostor je to už nakonfigurované. Pokud filtrujete méně než 50 % celkového objemu, není to žádné další náklady. Po 50 % je cena, ale mnohem menší než standardní poplatek za GB.
OpenTelemetry
Microsoft s radostí přijímá OpenTelemetry jako budoucnost instrumentace telemetrie. Vy, naši zákazníci, požádali o instrumentaci neutrální dodavatele a s radostí spolupracujeme s komunitou OpenTelemetry, abychom vytvořili konzistentní rozhraní API a sady SDK napříč jazyky.
Microsoft pracoval s účastníky projektu ze dvou dříve oblíbených opensourcových projektů telemetrie, OpenCensus a OpenTracing. Společně jsme pomohli vytvořit jeden projekt OpenTelemetry. OpenTelemetry zahrnuje příspěvky od všech hlavních dodavatelů cloudových služeb a správy výkonu aplikací (APM) a žije v rámci Cloud Native Computing Foundation (CNCF). Microsoft je platinovým členem CNCF.
Terminologii najdete v glosáři ve specifikacích OpenTelemetry.
Některé starší termíny v Application Insights jsou matoucí kvůli konvergenci průmyslu na OpenTelemetry. Následující tabulka uvádí tyto rozdíly. Termíny OpenTelemetry nahrazují termíny Application Insights.
Exportér služby Azure Monitor používá k internímu protokolování EventSource. Protokoly vývozce jsou k dispozici pro jakýkoli EventListener tím, že se přihlásí ke zdroji, který je pojmenován OpenTelemetry-AzureMonitor-Exporter. Postup řešení potíží najdete v tématu Řešení potíží s OpenTelemetry na GitHubu.
Krok 2: Testování připojení mezi hostitelem vaší aplikace a službou příjmu dat
Sady Application Insights SDK a agenti odesílají telemetrii, aby se ingestovala jako volání REST v koncových bodech příjmu dat. Pokud chcete otestovat připojení z webového serveru nebo hostitelského počítače aplikace ke koncovým bodům služby pro příjem dat, použijte příkazy cURL nebo nezpracované požadavky REST z PowerShellu. Další informace najdete v tématu Řešení potíží s chybějící telemetrií aplikací ve službě Azure Monitor Application Insights.
Známé problémy
V následujících položkách jsou známé problémy pro exportéry OpenTelemetry služby Azure Monitor:
V telemetrii závislostí chybí název operace. Chybějící název operace způsobuje selhání a nepříznivě ovlivňuje výkon karty.
V požadavku a telemetrii závislostí chybí model zařízení. Chybějící model zařízení nepříznivě ovlivňuje analýzu kohorty zařízení.
Krok 1: Povolení protokolování diagnostiky
Exportér služby Azure Monitor používá k internímu protokolování EventSource. Protokoly vývozce jsou k dispozici pro jakýkoli EventListener tím, že se přihlásí ke zdroji, který je pojmenován OpenTelemetry-AzureMonitor-Exporter. Postup řešení potíží najdete v tématu Řešení potíží s OpenTelemetry na GitHubu.
Krok 2: Testování připojení mezi hostitelem vaší aplikace a službou příjmu dat
Sady Application Insights SDK a agenti odesílají telemetrii, aby se ingestovala jako volání REST v koncových bodech příjmu dat. Pokud chcete otestovat připojení z webového serveru nebo hostitelského počítače aplikace ke koncovým bodům služby pro příjem dat, použijte příkazy cURL nebo nezpracované požadavky REST z PowerShellu. Další informace najdete v tématu Řešení potíží s chybějící telemetrií aplikací ve službě Azure Monitor Application Insights.
Známé problémy
V následujících položkách jsou známé problémy pro exportéry OpenTelemetry služby Azure Monitor:
V telemetrii závislostí chybí název operace. Chybějící název operace způsobuje selhání a nepříznivě ovlivňuje výkon karty.
V požadavku a telemetrii závislostí chybí model zařízení. Chybějící model zařízení nepříznivě ovlivňuje analýzu kohorty zařízení.
Krok 2: Testování připojení mezi hostitelem vaší aplikace a službou příjmu dat
Sady Application Insights SDK a agenti odesílají telemetrii, aby se ingestovala jako volání REST v koncových bodech příjmu dat. Pokud chcete otestovat připojení z webového serveru nebo hostitelského počítače aplikace ke koncovým bodům služby pro příjem dat, použijte příkazy cURL nebo nezpracované požadavky REST z PowerShellu. Další informace najdete v tématu Řešení potíží s chybějící telemetrií aplikací ve službě Azure Monitor Application Insights.
Známé problémy
Pokud si stáhnete klientskou knihovnu Application Insights pro instalaci z prohlížeče, někdy se stažený soubor JAR poškodí a je přibližně poloviční velikost zdrojového souboru. Pokud dojde k tomuto problému, stáhněte soubor JAR spuštěním příkazu curl nebo wget , jak je znázorněno v následujícím příkladu volání příkazů:
Ukázkové volání příkazů platí pro Application Insights pro Javu verze 3.4.11. Pokud chcete najít číslo verze a adresu URL aktuální verze Application Insights pro Javu, přečtěte si téma https://github.com/microsoft/ApplicationInsights-Java/releases.
Následující kroky platí pro nativní aplikace Spring Boot.
Krok 1: Ověření verze OpenTelemetry
Během spuštění aplikace si můžete všimnout následující zprávy:
WARN c.a.m.a.s.OpenTelemetryVersionCheckRunner - The OpenTelemetry version is not compatible with the spring-cloud-azure-starter-monitor dependency.
The OpenTelemetry version should be <version>
V tomto případě musíte importovat faktury OpenTelemetry podle dokumentace OpenTelemetry v úvodní aplikaci Spring Boot.
Krok 2: Povolení samoobslužné diagnostiky
Pokud něco nefunguje podle očekávání, můžete povolit samoobslužnou diagnostiku na DEBUG úrovni, abyste získali nějaké přehledy. Uděláte to tak, že nastavíte úroveň samoobslužné diagnostiky na ERRORhodnotu , WARNINFO, DEBUG, nebo TRACE pomocí APPLICATIONINSIGHTS_SELF_DIAGNOSTICS_LEVEL proměnné prostředí.
Pokud chcete povolit samoobslužnou diagnostiku na DEBUG úrovni při spuštění kontejneru Dockeru, spusťte následující příkaz:
docker run -e APPLICATIONINSIGHTS_SELF_DIAGNOSTICS_LEVEL=DEBUG <image-name>
Poznámka:
Odpovídajícím způsobem nahraďte <image-name> názvem image Dockeru.
Zřeknutí se odpovědnosti za informace třetích stran
Produkty třetích stran, které tento článek popisuje, pocházejí od společností, které jsou nezávislé na Microsoftu. Společnost Microsoft neposkytuje v souvislosti s výkonem a spolehlivostí těchto produktů žádnou záruku, předpokládanou ani jinou.
Krok 1: Povolení protokolování diagnostiky
Exportér služby Azure Monitor používá protokolovací nástroj rozhraní API OpenTelemetry pro interní protokoly. Pokud chcete protokolovací nástroj povolit, spusťte následující fragment kódu:
Krok 2: Testování připojení mezi hostitelem vaší aplikace a službou příjmu dat
Sady Application Insights SDK a agenti odesílají telemetrii, aby se ingestovala jako volání REST v koncových bodech příjmu dat. Pokud chcete otestovat připojení z webového serveru nebo hostitelského počítače aplikace ke koncovým bodům služby pro příjem dat, použijte příkazy cURL nebo nezpracované požadavky REST z PowerShellu. Další informace najdete v tématu Řešení potíží s chybějící telemetrií aplikací ve službě Azure Monitor Application Insights.
Známé problémy
V následujících položkách jsou známé problémy pro exportéry OpenTelemetry služby Azure Monitor:
V telemetrii závislostí chybí název operace. Chybějící název operace způsobuje selhání a nepříznivě ovlivňuje výkon karty.
V požadavku a telemetrii závislostí chybí model zařízení. Chybějící model zařízení nepříznivě ovlivňuje analýzu kohorty zařízení.
V názvu závislosti chybí název databázového serveru. Vzhledem k tomu, že název databázového serveru není zahrnutý, exportéři OpenTelemetry nesprávně agregují tabulky se stejným názvem na různé servery.
Krok 1: Povolení protokolování diagnostiky
Exportér Microsoft Azure Monitoru používá pro své interní protokolování standardní knihovnu protokolování Pythonu. Protokoly rozhraní OpenTelemetry API a exportéru služby Azure Monitor mají přiřazenou úroveň WARNING závažnosti nebo ERROR pro nepravidelnou aktivitu. Úroveň INFO závažnosti se používá pro běžnou nebo úspěšnou aktivitu.
Ve výchozím nastavení nastaví knihovna protokolování Pythonu úroveň závažnosti na WARNING. Proto je nutné změnit úroveň závažnosti, abyste viděli protokoly v tomto nastavení závažnosti. Následující příklad kódu ukazuje, jak výstupní protokoly všech úrovní závažnosti do konzoly a souboru:
Krok 2: Testování připojení mezi hostitelem vaší aplikace a službou příjmu dat
Sady Application Insights SDK a agenti odesílají telemetrii, aby se ingestovala jako volání REST v koncových bodech příjmu dat. Pokud chcete otestovat připojení z webového serveru nebo hostitelského počítače aplikace ke koncovým bodům služby pro příjem dat, použijte příkazy cURL nebo nezpracované požadavky REST z PowerShellu. Další informace najdete v tématu Řešení potíží s chybějící telemetrií aplikací ve službě Azure Monitor Application Insights.
Krok 3: Vyhněte se duplicitní telemetrii
Duplicitní telemetrie je často způsobena vytvořením více instancí procesorů nebo exportérů. Ujistěte se, že pro každý pilíř telemetrie (protokoly, metriky a distribuované trasování) spouštíte vždy jenom jeden vývozce a procesor.
Následující části popisují scénáře, které můžou způsobit duplicitní telemetrii.
Duplicitní protokoly trasování ve službě Azure Functions
Pokud se v Application Insights zobrazí dvojice položek pro každý protokol trasování, pravděpodobně jste povolili následující typy instrumentace protokolování:
Nativní instrumentace protokolování ve službě Azure Functions
Instrumentace azure-monitor-opentelemetry protokolování v rámci distribuce
Pokud chcete zabránit duplikaci, můžete protokolování distribuce zakázat, ale v Azure Functions nechte povolenou nativní instrumentaci protokolování. Uděláte to tak, že nastavíte proměnnou OTEL_LOGS_EXPORTER prostředí na Nonehodnotu .
Duplicitní telemetrie ve službě Azure Functions AlwaysOn
Pokud je nastavení AlwaysOn ve službě Azure Functions nastavené na Zapnuto, služba Azure Functions udržuje některé procesy spuštěné na pozadí po dokončení každého spuštění. Předpokládejme například, že máte pětiminutovou funkci časovače, která pokaždé volá configure_azure_monitor . Po 20 minutách můžete mít čtyři exportéry metrik, které běží současně. Tato situace může být zdrojem telemetrie duplicitních metrik.
V takovém případě buď nastavte nastavení AlwaysOn na Vypnuto, nebo zkuste ručně vypnout poskytovatele mezi jednotlivými configure_azure_monitor voláními. Pokud chcete vypnout každého zprostředkovatele, spusťte volání vypnutí pro každého aktuálního měřiče, trasování a zprostředkovatele protokolovacího nástroje, jak je znázorněno v následujícím kódu:
Azure Workbooks a Jupyter Notebooks můžou udržovat procesy exportéru spuštěné na pozadí. Pokud chcete zabránit duplicitní telemetrii, vymažte mezipaměť předtím, než budete volat configure_azure_monitorvíce .
Krok 4: Ujistěte se, že se shromažďují data žádosti Flask.
Pokud implementujete aplikaci Flask, můžete zjistit, že během používání klientské knihovny OpenTelemetry OpenTelemetry pro Python nemůžete shromažďovat data tabulky Requests z Application Insights. K tomuto problému může dojít v případě, že deklarace nespravujete import správně. Před voláním configure_azure_monitor funkce instrumentace knihovny Flask můžete naimportovat architekturu flask.Flask webové aplikace. Například následující kód úspěšně instrumentuje aplikaci Flask:
from azure.monitor.opentelemetry import configure_azure_monitor
from flask import Flask
configure_azure_monitor()
app = Flask(__name__)
Místo toho doporučujeme importovat flask modul jako celek a pak volat configure_azure_monitor konfiguraci OpenTelemetry tak, aby používala Azure Monitor před přístupem flask.Flask:
from azure.monitor.opentelemetry import configure_azure_monitor
import flask
configure_azure_monitor()
app = flask.Flask(__name__)
Alternativně můžete volat configure_azure_monitor před importem flask.Flask:
from azure.monitor.opentelemetry import configure_azure_monitor
configure_azure_monitor()
from flask import Flask
app = Flask(__name__)
Technická podpora
Vyberte kartu pro jazyk podle vašeho výběru a objevte možnosti podpory.
Připravujeme: V průběhu roku 2024 budeme postupně vyřazovat problémy z GitHub coby mechanismus zpětné vazby pro obsah a nahrazovat ho novým systémem zpětné vazby. Další informace naleznete v tématu: https://aka.ms/ContentUserFeedback.