Loggbaserade och föraggregerade mått i Application Insights
Kommentar
Följande dokumentation förlitar sig på det klassiska API:et Application Insights. Den långsiktiga planen för Application Insights är att samla in data med OpenTelemetry. Mer information finns i Aktivera Azure Monitor OpenTelemetry för .NET-, Node.js-, Python- och Java-program och vår OpenTelemetry-översikt. Migreringsvägledning är tillgänglig för .NET, Node.js och Python.
Den här artikeln förklarar skillnaden mellan "traditionella" Application Insights-mått som baseras på loggar och föraggregerade mått. Båda typerna av mått är tillgängliga för användare av Application Insights. Var och en ger ett unikt värde för övervakning av programmets hälsa, diagnostik och analys. Utvecklare som instrumenterar program kan bestämma vilken typ av mått som passar bäst för ett visst scenario. Beslut baseras på programmets storlek, förväntad mängd telemetri och affärskrav för måttprecision och aviseringar.
Loggbaserade mått
Tidigare baserades telemetrimodellen för programövervakning i Application Insights enbart på några fördefinierade typer av händelser, till exempel begäranden, undantag, beroendeanrop och sidvisningar. Utvecklare kan använda SDK:et för att generera dessa händelser manuellt genom att skriva kod som uttryckligen anropar SDK:et. Eller så kan de förlita sig på den automatiska samlingen av händelser från autoinstrumentation. I båda fallen lagrar Application Insights-serverdelen alla insamlade händelser som loggar. Application Insights-fönsterrutorna i Azure Portal fungera som ett analys- och diagnostikverktyg för att visualisera händelsebaserade data från loggar.
Att använda loggar för att behålla en fullständig uppsättning händelser kan ge bra analys- och diagnostikvärde. Du kan till exempel få ett exakt antal begäranden till en viss URL med antalet distinkta användare som gjorde dessa anrop. Eller så kan du få detaljerade diagnostikspårningar, inklusive undantag och beroendeanrop för alla användarsessioner. Om du har den här typen av information kan du få bättre insyn i programmets hälsa och användning. Det kan också minska den tid som krävs för att diagnostisera problem med en app.
Samtidigt kan insamling av en fullständig uppsättning händelser vara opraktiskt eller till och med omöjligt för program som genererar en stor mängd telemetri. I situationer där händelsevolymen är för hög implementerar Application Insights flera tekniker för minskning av telemetrivolymer som minskar antalet insamlade och lagrade händelser. Dessa tekniker omfattar sampling och filtrering. Tyvärr minskar sänkningen av antalet lagrade händelser också noggrannheten för de mått som i bakgrunden måste utföra frågetidsaggregeringar av de händelser som lagras i loggar.
Kommentar
I Application Insights kallas mått som baseras på frågetidsaggregering av händelser och mätningar som lagras i loggar loggbaserade mått. Dessa mått har vanligtvis många dimensioner från händelseegenskaperna, vilket gör dem överlägsna för analys. Noggrannheten för dessa mått påverkas negativt av sampling och filtrering.
Föraggregerade mått
Förutom loggbaserade mått levererade Application Insights-teamet i slutet av 2018 en offentlig förhandsversion av mått som lagras på en specialiserad lagringsplats som är optimerad för tidsserier. De nya måtten behålls inte längre som enskilda händelser med många egenskaper. I stället lagras de som föraggregerade tidsserier och endast med nyckeldimensioner. Den här ändringen gör de nya måtten överlägsna vid frågetillfället. Det går snabbare att hämta data och kräver mindre beräkningskraft. Därför aktiveras nya scenarier, till exempel aviseringar i nära realtid om måttdimensioner och mer dynamiska instrumentpaneler.
Viktigt!
Både loggbaserade och föraggregerade mått samexisterar i Application Insights. För att särskilja de två kallas nu föraggregerade mått i Application Insights-användarupplevelsen standardmått. De traditionella måtten från händelserna har bytt namn till loggbaserade mått.
De nyare SDK:erna (Application Insights 2.7 SDK eller senare för .NET) föraggregerar mått under samlingen. Den här processen gäller standardmått som skickas som standard, så noggrannheten påverkas inte av sampling eller filtrering. Det gäller även anpassade mått som skickas med hjälp av GetMetric, vilket resulterar i mindre datainmatning och lägre kostnad.
För de SDK:er som inte implementerar föraggregering (dvs. äldre versioner av Application Insights SDK:er eller för webbläsarinstrumentation) fyller Application Insights-serverdelen fortfarande de nya måtten genom att aggregera de händelser som tas emot av Application Insights-händelsesamlingens slutpunkt. Även om du inte drar nytta av den minskade mängden data som överförs via kabeln kan du fortfarande använda de föraggregerade måtten och få bättre prestanda och stöd för den nästan realtidsdimensionella aviseringen med SDK:er som inte föraggregerar mått under samlingen.
Samlingens slutpunkt föraggregerar händelser före inmatningssampling. Därför påverkar inmatningssampling aldrig noggrannheten för föraggregerade mått, oavsett vilken SDK-version du använder med ditt program.
Föraggregerad måtttabell som stöds av SDK
| Aktuella SDK:er för produktion | Standardmått (SDK-föraggregering) | Anpassade mått (utan SDK-föraggregering) | Anpassade mått (med SDK-föraggregering) |
|---|---|---|---|
| .NET Core och .NET Framework | Stöds (V2.13.1+) | Stöds via TrackMetric | Stöds (V2.7.2+) via GetMetric |
| Java | Stöds inte | Stöds via TrackMetric | Stöds inte |
| Node.js | Stöds (V2.0.0+) | Stöds via TrackMetric | Stöds inte |
| Python | Stöds inte | Stöds | Stöds delvis via OpenCensus.stats |
Kommentar
Måttimplementeringen för Python med hjälp av OpenCensus.stats skiljer sig från GetMetric. Mer information finns i Python-dokumentationen om mått.
Tabell med kodlösa föraggregerade mått som stöds
| Aktuella SDK:er för produktion | Standardmått (SDK-föraggregering) | Anpassade mått (utan SDK-föraggregering) | Anpassade mått (med SDK-föraggregering) |
|---|---|---|---|
| ASP.NET | Stöds 1 | Stöds inte | Stöds inte |
| ASP.NET Core | Stöds 2 | Stöds inte | Stöds inte |
| Java | Stöds inte | Stöds inte | Stöds |
| Node.js | Stöds inte | Stöds inte | Stöds inte |
- ASP.NET autoinstrumentation på virtuella datorer/VM-skalningsuppsättningar och lokalt genererar standardmått utan dimensioner. Detsamma gäller för Azure App Service, men samlingsnivån måste anges till rekommenderad. SDK:t krävs för alla dimensioner.
- ASP.NET Core autoinstrumentation på App Service genererar standardmått utan dimensioner. SDK krävs för alla dimensioner.
Använda föraggregering med anpassade Mått för Application Insights
Du kan använda föraggregering med anpassade mått. De två främsta fördelarna är:
- Konfigurera och avisera om en dimension av ett anpassat mått
- Minska mängden data som skickas från SDK till Application Insights-samlingens slutpunkt
Det finns flera sätt att skicka anpassade mått från Application Insights SDK. Om din version av SDK erbjuder GetMetric och TrackValue är dessa metoder det bästa sättet att skicka anpassade mått. I det här fallet sker föraggregering i SDK:et. Den här metoden minskar mängden data som lagras i Azure och även mängden data som överförs från SDK till Application Insights. Annars använder du metoden trackMetric , som föraggregerar måtthändelser under datainmatning.
Anpassade måttdimensioner och föraggregering
Alla mått som du skickar med hjälp av API-anropen OpenTelemetry, trackMetric eller GetMetric och TrackValue lagras automatiskt i både loggar och måttlager. Dessa mått finns i tabellen customMetrics i Application Insights och i Metrics Explorer under namnområdet Anpassat mått med namnet "azure.applicationinsights". Även om den loggbaserade versionen av ditt anpassade mått alltid behåller alla dimensioner lagras den föraggregerade versionen av måttet som standard utan dimensioner. Att behålla dimensioner för anpassade mått är en förhandsversionsfunktion som kan aktiveras från fliken Användning och uppskattad kostnad genom att välja Med dimensioner under Skicka anpassade mått till Azure Metric Store.
Kvoter
Föraggregerade mått lagras som tidsserier i Azure Monitor. Azure Monitor-kvoter för anpassade mått gäller.
Kommentar
Att gå över kvoten kan få oavsiktliga konsekvenser. Azure Monitor kan bli otillförlitligt i din prenumeration eller region. Information om hur du undviker att överskrida kvoten finns i Designbegränsningar och överväganden.
Varför är insamling av anpassade måttdimensioner inaktiverad som standard?
Samlingen med anpassade måttdimensioner är inaktiverad som standard eftersom du i framtiden debiterar anpassade mått med dimensioner separat från Application Insights. Lagringen av de icke-dimensionella anpassade måtten är fortfarande kostnadsfri (upp till en kvot). Du kan lära dig mer om kommande ändringar av prismodellen på vår officiella prissida.
Skapa diagram och utforska loggbaserade och föraggregerade standardmått
Använd Azure Monitor Metrics Explorer för att rita diagram från föraggregerade och loggbaserade mått och för att skapa instrumentpaneler med diagram. När du har valt den Application Insights-resurs du vill använda använder du namnområdesväljaren för att växla mellan standard- och loggbaserade mått. Du kan också välja ett anpassat måttnamnområde.
Prismodeller för Application Insights-mått
Inmatning av mått i Application Insights, oavsett om de är loggbaserade eller föraggregerade, genererar kostnader baserat på storleken på inmatade data. Mer information finns i Prissättning i Azure Log Analytics. Dina anpassade mått, inklusive alla dess dimensioner, lagras alltid i Application Insights-loggarkivet. Dessutom vidarebefordras en föraggregerad version av dina anpassade mått utan dimensioner till måttarkivet som standard.
Om du väljer alternativet Aktivera aviseringar för anpassade måttdimensioner för att lagra alla dimensioner av de föraggregerade måtten i måttarkivet kan extra kostnader genereras baserat på anpassade måttpriser.