Metriky založené na protokolech a předem agregované metriky ve službě Application Insights
Poznámka:
Následující dokumentace se spoléhá na rozhraní API Přehledy Application Přehledy Classic. Dlouhodobým plánem pro application Přehledy je shromažďovat data pomocí OpenTelemetry. Další informace najdete v tématu Povolení OpenTelemetry služby Azure Monitor pro aplikace .NET, Node.js, Python a Java.
Tento článek vysvětluje rozdíl mezi "tradičními" metrikami Přehledy aplikací, které jsou založené na protokolech a předem agregovaných metrikách. Pro uživatele Přehledy aplikace jsou k dispozici oba typy metrik. Každá z nich přináší jedinečnou hodnotu při monitorování stavu aplikace, diagnostiky a analýz. Vývojáři, kteří instrumentují aplikace, se můžou rozhodnout, který typ metriky je pro konkrétní scénář nejvhodnější. Rozhodnutí vycházejí z velikosti aplikace, očekávaného objemu telemetrie a obchodních požadavků na přesnost a upozorňování metrik.
Metriky založené na protokolech
V minulosti byl datový model telemetrie monitorování aplikace v aplikačním Přehledy založen výhradně na několika předdefinovaných typech událostí, jako jsou požadavky, výjimky, volání závislostí a zobrazení stránek. Vývojáři můžou pomocí sady SDK ručně generovat tyto události napsáním kódu, který explicitně vyvolá sadu SDK. Nebo se můžou spolehnout na automatické shromažďování událostí z automatického vytváření. V obou případech aplikace Přehledy back-end ukládá všechny shromážděné události jako protokoly. Podokna Přehledy aplikace na webu Azure Portal fungují jako analytický a diagnostický nástroj pro vizualizaci dat založených na událostech z protokolů.
Použití protokolů k zachování úplné sady událostí může přinést skvělou analytickou a diagnostickou hodnotu. Můžete například získat přesný počet požadavků na konkrétní adresu URL s počtem jedinečných uživatelů, kteří tato volání provedli. Nebo můžete získat podrobné diagnostické trasování, včetně výjimek a volání závislostí pro libovolnou uživatelskou relaci. Tento typ informací může zlepšit přehled o stavu a využití aplikace. Může také zkrátit dobu potřebnou k diagnostice problémů s aplikací.
Současně může být shromažďování kompletní sady událostí nepraktické nebo dokonce nemožné pro aplikace, které generují velký objem telemetrie. V situacích, kdy je objem událostí příliš vysoký, aplikace Přehledy implementuje několik technik redukce objemu telemetrie, které snižují počet shromážděných a uložených událostí. Mezi tyto techniky patří vzorkování a filtrování. Snížení počtu uložených událostí bohužel také snižuje přesnost metrik, které na pozadí musí provádět agregace událostí uložených v protokolech v době dotazu.
Poznámka:
V Přehledy aplikace se metriky založené na agregaci událostí a měření uložených v protokolech nazývají metriky založené na protokolech. Tyto metriky obvykle mají mnoho dimenzí z vlastností událostí, což je vynikající pro analýzy. Přesnost těchto metrik je negativně ovlivněná vzorkováním a filtrováním.
Předem agregované metriky
Kromě metrik založených na protokolech odeslal tým application Přehledy na konci roku 2018 veřejnou verzi Preview metrik uložených ve specializovaném úložišti optimalizovaném pro časovou řadu. Nové metriky se už neuchovávají jako jednotlivé události s velkým množstvím vlastností. Místo toho se ukládají jako předem agregované časové řady a pouze s klíčovými dimenzemi. Díky této změně budou nové metriky v době dotazu nadřízené. Načítání dat probíhá rychleji a vyžaduje menší výpočetní výkon. V důsledku toho jsou povolené nové scénáře, například upozorňování téměř v reálném čase na dimenze metrik a responzivní řídicí panely.
Důležité
Metriky založené na protokolech i předem agregované společně existují v Přehledy aplikace. Aby se dvě metriky odlišily, v aplikačním Přehledy uživatelském prostředí se teď agregované metriky označují jako standardní metriky (Preview). Tradiční metriky z událostí byly přejmenovány na metriky založené na protokolech.
Novější sady SDK (application Přehledy 2.7 SDK nebo novější pro .NET) před agregují metriky během shromažďování. Tento proces platí pro standardní metriky odeslané ve výchozím nastavení, takže přesnost není ovlivněna vzorkováním nebo filtrováním. Týká se také vlastních metrik odesílaných pomocí GetMetric, což vede k menšímu příjmu dat a nižším nákladům.
U sad SDK, které neimplementují před agregaci (tj. starší verze sad APPLICATION Přehledy SDK nebo pro instrumentaci prohlížeče), aplikace Přehledy back-endu stále naplní nové metriky agregací událostí přijatých koncovým bodem shromažďování událostí služby Application Přehledy. I když nemáte prospěch z omezeného objemu dat přenášených přes drát, můžete stále používat předem agregované metriky a využívat lepší výkon a podporu dimenzionálního upozorňování téměř v reálném čase pomocí sad SDK, které během shromažďování předem neagregují metriky.
Koncový bod kolekce předem agreguje události před vzorkováním příjmu dat. Z tohoto důvodu vzorkování příjmu dat nikdy neovlivní přesnost předem agregovaných metrik bez ohledu na verzi sady SDK, kterou používáte s vaší aplikací.
Tabulka metrik podporovaných předem agregovanými sadami SDK
| Aktuální produkční sady SDK | Standardní metriky (předběžná agregace sady SDK) | Vlastní metriky (bez předběžné agregace sady SDK) | Vlastní metriky (s předběžnou agregací sady SDK) |
|---|---|---|---|
| .NET Core a .NET Framework | Podporováno (V2.13.1+) | Podporováno prostřednictvím TrackMetric | Podporováno (V2.7.2+) prostřednictvím GetMetric |
| Java | Nepodporováno | Podporováno prostřednictvím TrackMetric | Nepodporováno |
| Node.js | Podporováno (V2.0.0+) | Podporováno prostřednictvím TrackMetric | Nepodporováno |
| Python | Nepodporováno | Podporováno | Částečně podporovaná prostřednictvím OpenCensus.stats |
Poznámka:
Implementace metrik pro Python pomocí OpenCensus.stats se liší od GetMetric. Další informace najdete v dokumentaci k Pythonu o metrikách.
Tabulka metrik s podporou bez kódu
| Aktuální produkční sady SDK | Standardní metriky (předběžná agregace sady SDK) | Vlastní metriky (bez předběžné agregace sady SDK) | Vlastní metriky (s předběžnou agregací sady SDK) |
|---|---|---|---|
| ASP.NET | Podporováno 1 | Nepodporováno | Nepodporováno |
| ASP.NET Core | Podporováno 2 | Nepodporováno | Nepodporováno |
| Java | Nepodporováno | Nepodporováno | Podporuje se |
| Node.js | Nepodporováno | Nepodporováno | Nepodporováno |
- ASP.NET připojení bez kódu na virtuálních počítačích nebo škálovacích sadách virtuálních počítačů a místní prostředí generuje standardní metriky bez dimenzí. Totéž platí pro službu Aplikace Azure Service, ale úroveň kolekce musí být nastavená na doporučenou. Sada SDK se vyžaduje pro všechny dimenze.
- ASP.NET připojení bez kódu jádra ve službě App Service generuje standardní metriky bez dimenzí. Sada SDK se vyžaduje pro všechny dimenze.
Použití předběžné agregace s aplikačními Přehledy vlastními metrikami
Můžete použít před agregaci s vlastními metrikami. Mezi dvě hlavní výhody patří:
- Možnost konfigurovat a upozorňovat na dimenzi vlastní metriky
- Snížení objemu dat odesílaných ze sady SDK do koncového bodu kolekce Přehledy aplikace
Existuje několik způsobů odesílání vlastních metrik ze sady Application Přehledy SDK. Pokud vaše verze sady SDK nabízí GetMetric a TrackValue, jsou tyto metody upřednostňovaným způsobem odesílání vlastních metrik. V tomto případě se v sadě SDK provede předběžná agregace. Tento přístup snižuje objem dat uložených v Azure a také objem dat přenášených ze sady SDK do služby Application Přehledy. V opačném případě použijte metodu trackMetric , která předem agreguje události metrik během příjmu dat.
Vlastní dimenze metrik a před agregace
Všechny metriky, které odesíláte pomocí OpenTelemetry, trackMetric nebo GetMetric a Volání rozhraní API TrackValue, se automaticky ukládají v protokolech i úložištích metrik. Tyto metriky najdete v tabulce customMetrics v aplikaci Přehledy a v Průzkumníku metrik v části Vlastní obor názvů metrik s názvem azure.applicationinsights. I když verze vlastní metriky založená na protokolu vždy zachovává všechny dimenze, předem agregovaná verze metriky se ve výchozím nastavení ukládá bez dimenzí. Zachování dimenzí vlastních metrik je funkce Preview, která se dá zapnout na kartě Využití a odhadované náklady výběrem možnosti S dimenzemi v části Odeslat vlastní metriky do Azure Metric Store.
Kvóty
Předem agregované metriky se ukládají jako časové řady ve službě Azure Monitor. Platí kvóty služby Azure Monitor pro vlastní metriky .
Poznámka:
Přechod přes kvótu může mít nezamýšlené důsledky. Azure Monitor může být ve vašem předplatném nebo oblasti nespolehlivý. Informace o tom, jak se vyhnout překročení kvóty, najdete v tématu Omezení návrhu a důležité informace.
Proč je ve výchozím nastavení vypnutá kolekce vlastních dimenzí metrik?
Kolekce vlastních dimenzí metrik je ve výchozím nastavení vypnutá, protože v budoucnu se vlastní metriky s dimenzemi budou účtovat odděleně od Přehledy aplikace. Ukládání nedimenzionálních vlastních metrik zůstává bezplatné (až do kvóty). Informace o nadcházejících změnách cenového modelu najdete na naší oficiální stránce s cenami.
Vytváření grafů a zkoumání metrik založených na protokolech a standardních předem agregovaných metrik
Pomocí Průzkumníka metrik Služby Azure Monitor můžete vykreslit grafy z předem agregovaných metrik a metrik založených na protokolech a vytvářet řídicí panely s grafy. Po výběru požadovaného prostředku Přehledy aplikace můžete pomocí nástroje pro výběr oboru názvů přepínat mezi standardními (preview) a metrikami založenými na protokolech. Můžete také vybrat vlastní obor názvů metrik.
Cenové modely pro metriky Přehledy aplikací
Ingestování metrik do služby Application Přehledy, ať už založené na protokolech nebo předem agregované, generuje náklady na základě velikosti přijatých dat. Další informace najdete v podrobnostech o cenách protokolů služby Azure Monitor. Vaše vlastní metriky, včetně všech jeho dimenzí, se vždy ukládají v úložišti protokolů Přehledy aplikace. Ve výchozím nastavení se také do úložiště metrik předává předem agregovaná verze vlastních metrik bez dimenzí.
Výběrem možnosti Povolit upozorňování na vlastní dimenze metriky můžete uložit všechny dimenze předem agregovaných metrik v úložišti metrik, které můžou generovat další náklady na základě cen vlastních metrik.