Aggregera och visa Azure Monitor-mått

Den här artikeln beskriver sammanställningen av mått i Azure Monitor-tidsseriedatabasen som stöder Azure Monitor-plattformsmått och anpassade mått. Den här artikeln gäller även standardmått för Application Insights.

Det här är ett komplext ämne och inte nödvändigt för att förstå all information i den här artikeln för att använda Azure Monitor-mått på ett effektivt sätt.

Översikt och villkor

När du lägger till ett mått i ett diagram förväljer Metrics Explorer automatiskt sin standardaggregering. Standardvärdet är meningsfullt i de grundläggande scenarierna, men du kan använda olika sammansättningar för att få fler insikter om måttet. Om du visar olika aggregeringar i ett diagram måste du förstå hur Metrics Explorer hanterar dem.

Nu ska vi definiera några termer tydligt först:

  • Måttvärde – ett enda måttvärde som samlats in för en specifik resurs.
  • Tidsseriedatabas – en databas som är optimerad för lagring och hämtning av datapunkter som alla innehåller ett värde och en motsvarande tidsstämpel.
  • Tidsperiod – en allmän tidsperiod.
  • Tidsintervall – tidsperioden mellan insamlingen av två måttvärden.
  • Tidsintervall – Tidsperioden som visas i ett diagram. Standardvärdet är 24 timmar. Endast specifika intervall är tillgängliga.
  • Tidskornighet eller tidsintervall – tidsperioden som används för att sammanställa värden för att tillåta visning i ett diagram. Endast specifika intervall är tillgängliga. Aktuellt minimum är 1 minut. Tidskornighetsvärdet bör vara mindre än det valda tidsintervallet för att vara användbart, annars visas bara ett värde för hela diagrammet.
  • Sammansättningstyp – en typ av statistik som beräknas från flera måttvärden.
  • Aggregering – processen att ta flera indatavärden och sedan använda dem för att skapa ett enda utdatavärde via de regler som definieras av aggregeringstypen. Till exempel att ta ett genomsnitt av flera värden.

Sammanfattning av processen

Mått är en serie värden som lagras med en tidsstämpel. I Azure lagras de flesta mått i tidsseriedatabasen för Azure Metrics. När du ritar ett diagram hämtas värdena för de valda måtten från databasen och aggregeras sedan separat baserat på den valda tidskornigheten (kallas även tidsintervall). Du väljer storleken på tidskornigheten med hjälp av tidsväljaren för Metrics Explorer. Om du inte gör ett explicit val väljs tidskornigheten automatiskt baserat på det valda tidsintervallet. När det har valts aggregeras de måttvärden som hämtades under varje tids kornighetsintervall och placeras på diagrammet – en datapunkt per intervall.

Sammansättningstyper

Det finns fem grundläggande aggregeringstyper som är tillgängliga i metrics Explorer. Metrics Explorer döljer de aggregeringar som är irrelevanta och inte kan användas för ett visst mått.

  • Summa – summan av alla värden som samlas in under aggregeringsintervallet. Kallas ibland total aggregering.
  • Count – antalet mätningar som samlats in under aggregeringsintervallet. Antal tittar inte på måttets värde, bara antalet poster.
  • Genomsnitt – medelvärdet av de måttvärden som samlas in under aggregeringsintervallet. För de flesta mått är det här värdet Summa/Antal.
  • Min – det minsta värdet som samlas in under aggregeringsintervallet.
  • Max – det största värdet som samlats in under aggregeringsintervallet.

Anta till exempel att ett diagram visar måttet Network Out Total för en virtuell dator med sum-aggregeringen under det senaste 24-timmarsintervallet. Tidsintervallet och kornigheten kan ändras från det övre högra hörnet av diagrammet enligt följande skärmbild.

Screenshot showing time range and time granularity picker

För tidskornighet = 30 minuter och tidsintervallet = 24 timmar:

  • Diagrammet ritas från 48 datapunkter. Det är 24 timmar x 2 datapunkter per timme (60min/30min) aggregerade 1-minuters datapunkter.
  • Linjediagrammet ansluter 48 punkter i diagramritningsområdet.
  • Varje datapunkt representerar summan av alla utskickade byte i nätverket under var och en av de relevanta tidsperioderna på 30 minuter.

Screenshot showing data on a line graph set to 24-hour time range and 30-minute time granularity

Klicka på bilderna i det här avsnittet för att se större versioner.

Om du växlar tidskornigheten till 15 minuter ritas diagrammet från 96 aggregerade datapunkter. Det vill: 60min/15min = 4 datapunkter per timme x 24 timmar.

Screenshot showing data on a line graph set to 24-hour time range and 15-minute time granularity

För tidskornighet på 5 minuter får du 24 x (60/5) = 288 poäng.

Screenshot showing data on a line graph set to 24-hour time range and 5-minute time granularity

För tidskornighet på 1 minut (det minsta möjliga i diagrammet) får du 24 x 60/1 = 1 440 poäng.

Screenshot showing data on a line graph set to 24-hour time range and 1-minute time granularity

Diagrammen ser annorlunda ut för dessa sammanfattningar enligt föregående skärmbilder. Observera att den här virtuella datorn har mycket utdata under en liten tidsperiod i förhållande till resten av tidsperioden.

Med tidskornigheten kan du justera förhållandet "signal till brus" i ett diagram. Högre sammansättningar tar bort brus och jämnar ut toppar. Observera variationerna i det nedre diagrammet på 1 minut och hur de jämnas ut när du går till högre kornighetsvärden.

Det här utjämningsbeteendet är viktigt när du skickar dessa data till andra system, till exempel aviseringar. Vanligtvis vill du vanligtvis inte bli varnad av mycket korta toppar i CPU-tid över 90 %. Men om processorn ligger kvar på 90 % i 5 minuter är det troligtvis viktigt. Om du konfigurerar en aviseringsregel för CPU (eller något mått) kan tidskornigheten minska antalet falska aviseringar som du får.

Det är viktigt att fastställa vad som är "normalt" för din arbetsbelastning för att veta vilket tidsintervall som är bäst. Detta är en av fördelarna med dynamiska aviseringar, vilket är ett annat ämne som inte beskrivs här.

Hur systemet samlar in mått

Datainsamlingen varierar beroende på mått.

Frekvens för mätningsinsamling

Det finns två typer av samlingsperioder.

  • Regular – Måttet samlas in med ett konsekvent tidsintervall som inte varierar.

  • Aktivitetsbaserad – Måttet samlas in baserat på när en transaktion av en viss typ inträffar. Varje transaktion har en måttpost och en tidsstämpel. De samlas inte in med jämna mellanrum, så det finns ett varierande antal poster under en viss tidsperiod.

Precision

Minsta tidskornighet är 1 minut, men det underliggande systemet kan samla in data snabbare beroende på måttet. Processorprocent för en virtuell Azure-dator samlas till exempel in med ett tidsintervall på 15 sekunder. Eftersom HTTP-fel spåras som transaktioner kan de enkelt överskrida många fler än en minut. Andra mått som SQL Storage samlas in med ett tidsintervall på var 20:e minut. Det här valet är upp till den enskilda resursprovidern och typen. De flesta försöker ange det minsta möjliga tidsintervallet.

Dimensioner, delning och filtrering

Mått samlas in för varje enskild resurs. Nivån på vilken måtten samlas in, lagras och kan diagramtas kan dock variera. Den här nivån representeras av ytterligare mått som är tillgängliga i måttdimensioner. Varje enskild resursprovider får definiera hur detaljerade data de samlar in är. Azure Monitor definierar bara hur sådan information ska visas och lagras.

När du kartlägger ett mått i Metric Explorer kan du "dela" diagrammet efter en dimension. Att dela upp ett diagram innebär att du tittar på underliggande data för mer information och ser dessa data diagram eller filtrerade i Metric Explorer.

Till exempel har Microsoft.ApiManagement/service Plats som en dimension för många mått.

  • Kapacitet är ett sådant mått. Att ha platsdimensionen innebär att det underliggande systemet lagrar en måttpost för kapaciteten på varje plats, i stället för bara en för den aggregerade mängden. Du kan sedan hämta eller dela upp informationen i ett måttdiagram.

  • Om du tittar på Den övergripande varaktigheten för gatewaybegäranden finns det 2 dimensioner plats och värdnamn, vilket återigen låter dig veta platsen för en varaktighet och vilket värdnamn det kom från.

  • Ett av de mer flexibla måtten, Requests, har 7 olika dimensioner.

I artikeln Azure Monitor-mått som stöds finns information om varje mått och vilka dimensioner som är tillgängliga. Dessutom kan dokumentationen för varje resursprovider och typ ge ytterligare information om dimensionerna och vad de mäter.

Du kan använda delning och filtrering tillsammans för att gräva i ett problem. Nedan visas ett exempel på en bild som visar genomsnittlig diskskrivningsbyte för en grupp virtuella datorer i en resursgrupp. Vi har en sammanslagning av alla virtuella datorer med det här måttet, men vi kanske vill ta reda på vilka som faktiskt är ansvariga för topparna runt 06.00. Är de samma dator? Hur många datorer är inblandade?

Screenshot showing total Disk Write Bytes for all virtual machines in Contoso Hotels resource group

Klicka på bilderna i det här avsnittet för att se större versioner.

När vi tillämpar delning kan vi se underliggande data, men det är lite rörigt. Det visar sig att det finns 20 virtuella datorer som aggregeras i diagrammet ovan. I det här fallet har vi använt musen för att hovra över den stora toppen klockan 06.00 som anger att CH-DCVM11 är orsaken. men det är svårt att se resten av de data som är associerade med den virtuella datorn på grund av att andra virtuella datorer belamrar diagrammet.

Screenshot showing Disk Write Bytes for all virtual machines in Contoso Hotels resource group split by virtual machine name

Med filtrering kan vi rensa diagrammet för att se vad som verkligen händer. Du kan kontrollera eller avmarkera de virtuella datorer som du vill se. Lägg märke till de streckade linjerna. De nämns i ett senare avsnitt.

Screenshot showing Disk Write Bytes for all virtual machines in Contoso Hotels resource group split and filtered by virtual machine name

Mer information om hur du visar delade dimensionsdata i ett måttutforskarediagram finns i Avancerade funktioner i metrics explorer- filter och delning.

NULL- och nollvärden

När systemet förväntar sig måttdata från en resurs men inte tar emot dem registrerar det ett NULL-värde. NULL skiljer sig från ett nollvärde, vilket blir viktigt vid beräkningen av sammansättningar och diagram. NULL-värden räknas inte som giltiga mått.

NULL:er visas på olika sätt i olika diagram. Punktdiagram hoppar över att visa en punkt i diagrammet. Stapeldiagram hoppar över att visa fältet. I linjediagram kan NULL visas som streckade eller streckade linjer som de som visas i skärmbilden i föregående avsnitt. När du beräknar medelvärden som innehåller NULL:er finns det färre datapunkter att ta medelvärdet från. Det här beteendet kan ibland resultera i en oväntad minskning av värden i ett diagram, men vanligtvis mindre än om värdet konverterades till en nolla och användes som en giltig datapunkt.

Anpassade mått använder alltid NULL:er när inga data tas emot. Med plattformsmått bestämmer varje resursprovider om de ska använda nollor eller NULL:er baserat på vad som är mest meningsfullt för ett visst mått.

Azure Monitor-aviseringar använder de värden som resursprovidern skriver till måttdatabasen, så det är viktigt att veta hur resursprovidern hanterar NULL:er genom att visa data först.

Så här fungerar aggregering

Måttdiagrammen i föregående system visar olika typer av aggregerade data. Systemet föraggregerar data så att de begärda diagrammen kan visas snabbare utan mycket upprepad beräkning.

I det här exemplet:

  • Vi samlar in ett fiktivt transaktionsmått som kallas HTTP-fel
  • Servern är en dimension för HTTP-felmåttet .
  • Vi har 3 servrar – Server A, B och C.

För att förenkla förklaringen börjar vi med aggregeringstypen SUM.

Aggregering under minut till 1 minut

Första rådata samlas in och lagras i Azure Monitor-måttdatabasen. I det här fallet har varje server transaktionsposter lagrade med en tidsstämpel eftersom Servern är en dimension. Med tanke på att den minsta tidsperiod som du kan visa som kund är 1 minut aggregeras dessa tidsstämplar först till måttvärden på 1 minut för varje enskild server. Aggregeringsprocessen för Server B visas i bilden nedan. Servrarna A och C görs på samma sätt och har olika data.

Screenshot showing sub minute transactional entries into 1-minute aggregations.

De resulterande aggregerade värdena på 1 minut lagras som nya poster i måttdatabasen så att de kan samlas in för senare beräkningar.

Screenshot showing multiple 1-minute aggregated entries across dimension of server. Server A, B, and C shown individually

Dimensionsaggregering

1-minutersberäkningarna komprimeras sedan av dimensionen och lagras igen som enskilda poster. I det här fallet aggregeras alla data från alla enskilda servrar till ett intervallmått på 1 minut och lagras i måttdatabasen för användning i senare sammansättningar.

Screenshot showing multiple 1-minute aggregated entries of Server A, B, and C aggregated into 1-minute All Servers entires

För tydlighetens skull visar följande tabell aggregeringsmetoden.

Period Server A Server B Server C Summa (A+B+C)
Minut 1 1 1 1 3
Minut 2 0 5 1 6
Minut 3 0 5 1 6
Minut 4 2 3 4 9
Minut 5 1 0 3 4
Minut 6 1 0 4 5
Minut 7 1 2 4 7
Minut 8 0 1 0 1
Minut 9 1 1 4 6
Minut 10 2 1 0 3

Endast en dimension visas ovan, men samma aggregerings- och lagringsprocess sker för alla dimensioner som ett mått stöder.

  • Samla in värden i en minuts aggregerad uppsättning av den dimensionen. Lagra dessa värden.
  • Komprimera dimensionen till en aggregerad summa på 1 minut. Lagra dessa värden.

Nu ska vi introducera en annan dimension av HTTP-fel som kallas NetworkAdapter. Anta att vi hade ett varierande antal kort per server.

  • Server A har ett kort
  • Server B har 2 kort
  • Server C har tre kort

Vi samlar in data för följande transaktioner separat. De skulle markeras med:

  • En tid
  • Ett värde
  • Servern som transaktionen kom från
  • Kortet som transaktionen kom från

Var och en av dessa underminute-strömmar aggregeras sedan till 1 minuts tidsserievärden och lagras i Azure Monitor-måttdatabasen:

  • Server A, adapter 1
  • Server B, adapter 1
  • Server B, adapter 2
  • Server C, adapter 1
  • Server C, adapter 2
  • Server C, adapter 3

Dessutom lagras följande komprimerade aggregeringar:

  • Server A, Adapter 1 (eftersom det inte finns något att dölja, skulle den lagras igen)
  • Server B, adapter 1+2
  • Server C, Adapter 1+2+3
  • Servrar ALLA, Alla kort

Detta visar att mått med ett stort antal dimensioner har ett större antal sammansättningar. Det är inte viktigt att känna till alla permutationer, bara förstå resonemanget. Systemet vill ha både enskilda data och aggregerade data lagrade för snabb hämtning för åtkomst i alla diagram. Systemet väljer antingen den mest relevanta lagrade aggregeringen eller underliggande rådata beroende på vad du väljer att visa.

Sammansättning utan dimensioner

Eftersom det här måttet har en dimensionsserver kan du komma till underliggande data för server A, B och C ovan via delning och filtrering, enligt beskrivningen tidigare i den här artikeln. Om måttet inte hade Server som dimension kunde du som kund bara komma åt de aggregerade 1-minuterssummorna som visas i svart i diagrammet. Det vill: värdena för 3, 6, 6, 9 osv. Systemet skulle inte heller utföra det underliggande arbetet för att aggregera delade värden, det skulle aldrig använda dem i Metric Explorer eller skicka ut dem via MÅTT REST API.

Visa tidskornigheter över 1 minut

Om du frågar efter mått med större kornighet använder systemet de aggregerade summorna på 1 minut för att beräkna summorna för de större tidskornigheterna. Nedan visar streckade rader sammanfattningsmetoden för tidskornigheterna på 2 minuter och 5 minuter. Återigen visar vi bara sum-aggregeringstypen för enkelhetens skull.

Screenshot showing multiple 1-minute aggregated entries across dimension of server aggregated into 2-min and 5-min time periods.

För tidskornigheten på 2 minuter.

Period Summor
Minut 1 och 2 (3 + 6) = 9
Minut 3 och 4 (6 + 9) = 15
Minut 4 och 5 (4 + 5) = 9
Minut 6 och 7 (7 + 1) = 8
Minut 8 och 9 (6 + 3) = 9

För 5 minuters tidskornighet.

Period Summor
Minut 1 till 5 3 + 6 + 6 + 9 + 4 = 28
Minut 6 till 10 5 + 7 + 1 + 6 + 3 = 22

Systemet använder lagrade aggregerade data som ger bästa prestanda.

Nedan visas det större diagrammet för aggregeringsprocessen ovan på 1 minut, där några av pilarna utelämnas för att förbättra läsbarheten.

Screenshot showing consolidation of previous 3 screenshots. Multiple 1-minute aggregated entries across dimension of server aggregated in 1-minute, 2-minute, and 5-minute intervals. Server A, B, and C shown individually

Mer komplext exempel

Följande är ett större exempel med värden för ett fiktivt mått som kallas HTTP-svarstid i millisekunder. Här introducerar vi ytterligare komplexitetsnivåer.

  1. Vi visar aggregering för Sum, Count, Min och Max och beräkningen för Average.
  2. Vi visar NULL-värden och hur de påverkar beräkningar.

Betänk följande exempel. Rutorna och pilarna visar exempel på hur värdena aggregeras och beräknas.

Samma föraggregeringsprocess på 1 minut som beskrivs i föregående avsnitt sker för Sums, Count, Minimum och Maximum. Medelvärdet är dock INTE föraggregerat. Den beräknas om med aggregerade data för att undvika beräkningsfel.

Screenshot showing complex example of aggregation and calculation of sum, count, min, max and average from 1 minute to 10 minutes.

Överväg minut 6 för aggregering på 1 minut enligt ovan. Den här minuten är den punkt där Server B gick offline och slutade rapportera data, kanske på grund av en omstart.

Från minut 6 ovan är de beräknade aggregeringstyperna på 1 minut:

Sammansättningstyp Värde Kommentar
Sum 53+20=73
Antal 2 Visar effekten av NULLs. Värdet skulle ha varit 3 om servern hade varit online.
Minimal 20
Högsta 53
Genomsnitt 73 / 2 Alltid summan dividerad med antal. Den lagras aldrig och beräknas alltid om för varje tidskornighet med hjälp av de aggregerade talen för den kornigheten. Observera omberäkningen för 5-minuters- och 10-minuters tidskornigheterna enligt ovan.

Den röda textfärgen anger värden som kan anses ligga inom det normala intervallet och visar hur de sprids (eller misslyckas) när tidskornigheten ökar. Observera hur Min och Max anger att det finns underliggande avvikelser medan medelvärdet och summorna förlorar den informationen när tidskornigheten ökar.

Du kan också se att NULL:er ger en bättre beräkning av medelvärdet än om nollor användes i stället.

Kommentar

Även om det inte är fallet i det här exemplet är Count lika med Sum i fall där ett mått alltid registreras med värdet 1. Detta är vanligt när ett mått spårar förekomsten av en transaktionshändelse, till exempel antalet HTTP-fel som nämns i ett tidigare exempel i den här artikeln.

Nästa steg