Vysvětlení agregace a zobrazení metrik služby Azure Monitor

Tento článek vysvětluje agregaci metrik v databázi časových řad služby Azure Monitor, která zálohuje metriky platformy Azure Monitor a vlastní metriky. Tento článek platí také pro standardní metriky Přehledy aplikací.

Toto je složité téma, které není nutné pochopit všechny informace v tomto článku, aby bylo možné efektivně používat metriky služby Azure Monitor.

Přehled a termíny

Když do grafu přidáte metriku, průzkumník metrik automaticky předem vybere výchozí agregaci. Výchozí nastavení dává smysl v základních scénářích, ale pomocí různých agregací můžete získat další přehledy o metrikě. Zobrazení různýchagch

Pojďme nejprve jasně definovat několik termínů:

  • Hodnota metriky – jedna hodnota měření shromážděná pro konkrétní prostředek.
  • Databáze Time-Series – Databáze optimalizovaná pro ukládání a načítání datových bodů, které obsahují hodnotu a odpovídající časové razítko.
  • Časové období – obecné časové období.
  • Časový interval – časové období mezi shromažďováním dvou hodnot metriky.
  • Časový rozsah – časové období zobrazené v grafu. Typická výchozí hodnota je 24 hodin. K dispozici jsou pouze konkrétní oblasti.
  • Časová členitost nebo agregační interval – časové období použité k agregaci hodnot, aby bylo možné zobrazit v grafu. K dispozici jsou pouze konkrétní oblasti. Aktuální minimum je 1 minuta. Hodnota časové intervaly by měla být menší než vybraný časový rozsah, který má být užitečný, jinak se pro celý graf zobrazí jenom jedna hodnota.
  • Typ agregace – typ statistiky vypočítaný z více hodnot metrik.
  • Agregace – proces přebírání více vstupních hodnot a jejich následné použití k vytvoření jedné výstupní hodnoty prostřednictvím pravidel definovaných typem agregace. Například s průměrem více hodnot.

Shrnutí procesu

Metriky jsou řada hodnot uložených s časovým razítkem. V Azure se většina metrik ukládá do databáze časové řady metrik Azure. Při vykreslení grafu se hodnoty vybraných metrik načtou z databáze a pak se agregují samostatně na základě zvolené časové intervaly (označované také jako agregační interval). Pomocí výběru času průzkumníka metrik vyberete velikost časové intervaly. Pokud explicitní výběr nevyberete, je časové intervaly automaticky vybrány na základě aktuálně vybraného časového rozsahu. Po výběru se hodnoty metrik zachycené během každého intervalu intervalu členitosti agregují a umístí do grafu – jeden datový bod za interval.

Typy agregace

V Průzkumníku metrik je k dispozici pět základních typů agregace. Průzkumník metrik skryje agregace, které nejsou relevantní a nelze je použít pro danou metriku.

  • Součet – součet všech hodnot zachycených v agregačním intervalu. Někdy se označuje jako celková agregace.
  • Count – počet měření zachycených v agregačním intervalu. Počet se nedívá na hodnotu měření, pouze počet záznamů.
  • Průměr – průměr hodnot metrik zachycených v agregačním intervalu U většiny metrik je tato hodnota součet/počet.
  • Min – nejmenší hodnota zachycená v agregačním intervalu.
  • Maximum – největší hodnota zachycená v agregačním intervalu.

Předpokládejme například, že graf zobrazuje metriku Celkové využití sítě pro virtuální počítač pomocí agregace SUMA za posledních 24hodinový časový rozsah. Časový rozsah a členitost lze změnit z pravého horního rohu grafu, jak je vidět na následujícím snímku obrazovky.

Screenshot showing time range and time granularity picker

Pro časové intervaly = 30 minut a časový rozsah = 24 hodin:

  • Graf je nakreslen ze 48 datových bodů. To je 24 hodin x 2 datové body za hodinu (60 minut/30min) agregované 1minutové datové body.
  • Spojnicový graf spojuje 48 bodů v oblasti grafu.
  • Každý datový bod představuje součet všech bajtů odchozí sítě odesílaných během každého z příslušných 30 minutových časových období.

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

Kliknutím na obrázky v této části zobrazíte větší verze.

Pokud přepnete časové intervaly na 15 minut, graf se nakreslí z 96 agregovaných datových bodů. To znamená, že 60min/15min = 4 datové body za hodinu x 24 hodin.

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

Pro časové intervaly 5 minut získáte 24 x (60/5) = 288 bodů.

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

Pro časové intervaly 1 minuty (nejmenší možné v grafu) získáte 24 x 60/1 = 1440 bodů.

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

Grafy vypadají pro tyto součty jinak, jak je znázorněno na předchozích snímcích obrazovky. Všimněte si, že tento virtuální počítač má v malém časovém období hodně výstupu vzhledem ke zbytku časového intervalu.

Časová členitost umožňuje upravit poměr signálu k šumu v grafu. Vyšší agregace odstraňují šum a vyhlazení špiček. Všimněte si variant v dolním 1minutovém grafu a zjistěte, jak se vyhladí při přechodu na hodnoty vyšší členitosti.

Toto chování při vyhlazování je důležité, když tato data odesíláte do jiných systémů – například výstrahy. Obvykle nechcete být upozorňování na velmi krátké špičky v čase procesoru nad 90 %. Pokud ale procesor zůstane na 90 % po dobu 5 minut, je to pravděpodobně důležité. Pokud nastavíte pravidlo upozornění na procesor (nebo libovolnou metriku), zvětšete časový interval tím, že snížíte počet upozornění, která obdržíte.

Je důležité určit, co je pro vaši úlohu "normální", abyste věděli, jaký časový interval je nejlepší. Toto je jednou z výhod dynamických upozornění, což je jiné téma, které zde není popsáno.

Jak systém shromažďuje metriky

Shromažďování dat se liší podle metrik.

Frekvence sběru měření

Existují dva typy období kolekce.

  • Regular – Metrika se shromažďuje v konzistentním časovém intervalu, který se neliší.

  • Na základě aktivity – metrika se shromažďuje na základě toho, kdy dojde k transakci určitého typu. Každá transakce má položku metriky a časové razítko. Neshromažďují se v pravidelných intervalech, takže v daném časovém období existuje různý počet záznamů.

Členitost

Minimální časová členitost je 1 minuta, ale základní systém může zaznamenávat data rychleji v závislosti na metrice. Například procento procesoru pro virtuální počítač Azure se zaznamenává v časovém intervalu 15 sekund. Vzhledem k tomu, že selhání PROTOKOLU HTTP se sledují jako transakce, můžou snadno překročit více než jednu minutu. Další metriky, jako je SQL Storage, se zaznamenávají v časovém intervalu každých 20 minut. Tato volba je až pro jednotlivého poskytovatele prostředků a typ. Většina se snaží poskytnout nejmenší možný časový interval.

Dimenze, rozdělení a filtrování

Metriky se zaznamenávají pro každý jednotlivý prostředek. Úroveň, na které se metriky shromažďují, ukládají a můžou být grafované, se ale můžou lišit. Tato úroveň je reprezentována dalšími metrikami dostupnými v dimenzích metrik. Každý jednotlivý poskytovatel prostředků definuje, jak jsou podrobná data, která shromažďují. Azure Monitor definuje, jak se mají tyto podrobnosti zobrazovat a ukládat.

Když v Průzkumníku metrik namapujete metriku, máte možnost graf rozdělit podle dimenze. Rozdělení grafu znamená, že se díváte na podkladová data, abyste se podívali na podrobnější informace a viděli, že se data v Průzkumníku metrik zobrazují nebo filtrují.

Například Microsoft.ApiManagement/serviceumístění jako dimenzi pro mnoho metrik.

  • Kapacita je jednou z těchto metrik. Dimenze Umístění znamená, že základní systém ukládá záznam metriky pro kapacitu jednotlivých umístění, a ne jen jeden pro agregovanou částku. Tyto informace pak můžete načíst nebo rozdělit v grafu metrik.

  • Když se podíváte na celkovou dobu trvání požadavků brány, jsou k dispozici 2 dimenze Umístění a název hostitele a znovu vás informuje o umístění doby trvání a názvu hostitele, ze kterého pochází.

  • Jedna z flexibilnějších metrik, Požadavky, má 7 různých dimenzí.

Podrobnosti o jednotlivých metrikách a dostupných dimenzích najdete v článku podporovaném metrikami služby Azure Monitor. Kromě toho může dokumentace pro každého poskytovatele prostředků a typ poskytnout další informace o dimenzích a o tom, co měří.

K prozkoumání problému můžete použít rozdělení a filtrování. Níže je příklad obrázku znázorňující bajty průměrného zápisu disku pro skupinu virtuálních počítačů ve skupině prostředků. Máme souhrn všech virtuálních počítačů s touto metrikou, ale můžeme se podívat, které jsou ve skutečnosti zodpovědné za špičky kolem 6:00. Jsou to stejné počítače? Kolik počítačů se týká?

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

Kliknutím na obrázky v této části zobrazíte větší verze.

Když použijeme rozdělení, uvidíme podkladová data, ale je to trochu bordel. Ukázalo se, že do výše uvedeného grafu se agreguje 20 virtuálních počítačů. V tomto případě jsme použili myš k najetí myší na velký vrchol v 6:00, což nám říká, že příčinou je CH-DCVM11. ale zbytek dat spojených s tímto virtuálním počítačem je obtížné vidět kvůli jiným virtuálním počítačům, které graf nepřehledně zahlcují.

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

Pomocí filtrování můžeme graf vyčistit, abychom viděli, co se skutečně děje. Můžete zkontrolovat nebo zrušit zaškrtnutí virtuálních počítačů, které chcete zobrazit. Všimněte si tečkovaných čar. Ty jsou zmíněny v další části.

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

Další informace o tom, jak zobrazit rozdělení dat dimenzí v grafu průzkumníka metrik, najdete v tématu Pokročilé funkce průzkumníka metrik – filtry a rozdělení.

Hodnoty NULL a nula

Pokud systém očekává data metriky z prostředku, ale neobdrží je, zaznamená hodnotu NULL. Hodnota NULL se liší od nulové hodnoty, která se stává důležitou při výpočtu agregací a grafů. Hodnoty NULL se nezapočítávají jako platné hodnoty.

V různých grafech se hodnoty NULLs zobrazují odlišně. Bodové grafy přeskočí znázorňující tečku v grafu. Pruhové grafy přeskočí s pruhem. U spojnicových grafů se null může zobrazit jako tečkované nebo přerušované čáry , jako jsou ty, které se zobrazují na snímku obrazovky v předchozí části. Při výpočtu průměrů, které zahrnují hodnoty NULLs, existuje méně datových bodů, ze kterého se má průměr vzít. Toto chování může někdy vést k neočekávanému poklesu hodnot v grafu, ale obvykle méně, než kdyby byla hodnota převedena na nulu a použita jako platný datový bod.

Vlastní metriky vždy používají hodnoty NUL, pokud nejsou přijata žádná data. U metrik platformy se každý poskytovatel prostředků rozhodne, jestli se mají používat nuly nebo nuly na základě toho, co dává smysl pro danou metriku.

Upozornění služby Azure Monitor používají hodnoty, které poskytovatel prostředků zapisuje do databáze metrik, takže je důležité vědět, jak poskytovatel prostředků zpracovává hodnoty NUL, zobrazením dat nejprve.

Jak funguje agregace

Grafy metrik v předchozím systému zobrazují různé typy agregovaných dat. Systém předem agreguje data, aby požadované grafy mohly zobrazit rychleji bez velkého množství opakovaných výpočtů.

V tomto příkladu:

  • Shromažďujeme fiktivní transakční metriku označovanou jako selhání PROTOKOLU HTTP.
  • Server je dimenze pro metriku selhání PROTOKOLU HTTP.
  • Máme 3 servery – Server A, B a C.

Abychom zjednodušili vysvětlení, začneme pouze s typem agregace SUM.

Subminutová až 1minutová agregace

První nezpracovaná data metrik se shromažďují a ukládají v databázi metrik služby Azure Monitor. V tomto případě má každý server transakční záznamy uložené s časovým razítkem, protože Server je dimenze. Vzhledem k tomu, že nejmenší časové období, které můžete zobrazit jako zákazník, je 1 minuta, jsou tato časová razítka nejprve agregována do 1minutových hodnot metrik pro každý jednotlivý server. Proces agregace pro Server B je znázorněn na obrázku níže. Servery A a C se provádějí stejným způsobem a mají různá data.

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

Výsledné 1minutové agregované hodnoty se ukládají jako nové položky v databázi metrik, aby je bylo možné shromáždit pro pozdější výpočty.

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

Agregace dimenzí

1minutové výpočty se pak sbalí podle dimenze a znovu se uloží jako jednotlivé záznamy. V tomto případě se všechna data ze všech jednotlivých serverů agregují do 1minutové metriky intervalu a ukládají se do databáze metrik pro pozdější agregace.

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

Pro přehlednost uvádí následující tabulka metodu agregace.

Period Server A Server B Server C Součet (A+B+C)
Minuta 1 1 1 1 3
Minuta 2 0 5 1 6
Minuta 3 0 5 1 6
Minuta 4 2 3 4 9
Minuta 5 0 0 3 4
Minuta 6 0 0 4 5
Minuta 7 1 2 4 7
Minuta 8 0 1 0 1
Minuta 9 1 1 4 6
Minuta 10 2 0 0 3

Výše je zobrazena pouze jedna dimenze, ale stejná agregace a proces úložiště probíhá pro všechny dimenze , které metrika podporuje.

  • Shromážděte hodnoty do 1minutové agregované sady podle dané dimenze. Tyto hodnoty uložte.
  • Sbalení dimenze do 1minutové agregované sumy Tyto hodnoty uložte.

Pojďme zavést další dimenzi selhání PROTOKOLU HTTP s názvem NetworkAdapter. Řekněme, že jsme měli různý počet adaptérů na server.

  • Server A má 1 adaptér
  • Server B má 2 adaptéry
  • Server C má 3 adaptéry

Data pro následující transakce bychom shromáždili samostatně. Označí se jako:

  • Čas
  • Hodnota
  • Server, ze které transakce pochází
  • Adaptér, ze kterého transakce pochází

Každý z těchto dílčích datových proudů by se pak agregoval do 1minutových hodnot časových řad a uložil do databáze metrik Služby Azure Monitor:

  • Server A, Adaptér 1
  • Server B, adaptér 1
  • Server B, Adaptér 2
  • Server C, Adaptér 1
  • Server C, Adaptér 2
  • Server C, Adaptér 3

Kromě toho by se uložily i následující sbalené agregace:

  • Server A, Adapter 1 (protože není nic ke sbalení, bude uložen znovu)
  • Server B, adaptér 1+2
  • Server C, adaptér 1+2+3
  • Servery ALL, adaptéry ALL

To ukazuje, že metriky s velkým počtem dimenzí mají větší počet agregací. Není důležité znát všechny permutace, jen pochopit důvod. Systém chce mít jednotlivá data i agregovaná data uložená pro rychlé načtení pro přístup k libovolnému grafu. Systém vybere buď nejrelevavantnější uloženou agregaci, nebo podkladová nezpracovaná data v závislosti na tom, co se rozhodnete zobrazit.

Agregace bez dimenzí

Vzhledem k tomu, že tato metrika má server dimenzí, můžete se dostat k podkladovým datům pro server A, B a C výše prostřednictvím rozdělení a filtrování, jak je vysvětleno výše v tomto článku. Pokud metrika neměla jako dimenzi Server , můžete jako zákazník získat přístup pouze k agregovaným 1minutovým součtům zobrazeným černou na diagramu. To znamená hodnoty 3, 6, 6, 6, 9 atd. Systém by také nezpracoval podkladovou práci k agregaci rozdělených hodnot, které by nikdy nepoužil v Průzkumníku metrik ani je neposílal prostřednictvím rozhraní REST API metrik.

Zobrazení časových intervalů nad 1 minutu

Pokud požadujete metriky s větší členitostí, použije systém 1minutové agregované součty k výpočtu součtů pro větší časové intervaly. Níže tečkované čáry zobrazují metodu součtu pro 2minutové a 5minutové časové intervaly. Znovu pro zjednodušení zobrazujeme pouze typ agregace SUM.

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

Pro 2minutové časové intervaly.

Period Částky
Minuta 1 a 2 (3 + 6) = 9
Minuta 3 a 4 (6 + 9) = 15
Minuta 4 a 5 (4 + 5) = 9
Minuta 6 a 7 (7 + 1) = 8
Minuta 8 a 9 (6 + 3) = 9

5minutové časové intervaly.

Period Částky
Minuta 1 až 5 3 + 6 + 6 + 9 + 4 = 28
Minuta 6 až 10 5 + 7 + 1 + 6 + 3 = 22

Systém používá uložená agregovaná data, která poskytují nejlepší výkon.

Níže je větší diagram pro výše uvedený 1minutový proces agregace s některými šipkami, aby se zlepšila čitelnost.

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

Složitější příklad

Následuje větší příklad použití hodnot pro fiktivní metriku s názvem Doba odezvy HTTP v milisekundách. Tady představujeme další úrovně složitosti.

  1. Zobrazíme agregaci pro součet, počet, minimum a maximum a výpočet pro průměr.
  2. Zobrazujeme hodnoty NULL a jejich vliv na výpočty.

Představte si následující příklad. Pole a šipky ukazují příklady agregace a výpočtu hodnot.

Stejný 1minutový proces předběžné agregace, jak je popsáno v předchozí části, se vyskytuje u součtů, počtu, minimálního a maximálního počtu. Průměr však není předem agregovaný. Přepočítá se pomocí agregovaných dat, aby nedocházelo k chybám výpočtu.

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

Zvažte minutu 6 pro 1minutovou agregaci, jak je zvýrazněno výše. Tato minuta je místem, kde server B přešel do offline režimu a zastavil data generování sestav, možná kvůli restartování.

Od minuty 6 výše jsou počítané 1minutové typy agregace:

Typ agregace Hodnota Notes
Sum 53+20=73
Počet 2 Zobrazuje účinek NULL. Hodnota by byla 3, kdyby server byl online.
Minimum 20
Maximum 53
Průměr 73 / 2 Vždy suma dělená počtem. Nikdy se neukládají a vždy se přepočítávají pro každou členitost pomocí agregovaných čísel pro danou členitost. Všimněte si přepočítání 5minutových a 10minutových časových intervalů, jak je zvýrazněno výše.

Červená barva textu označuje hodnoty, které se můžou považovat za mimo normální rozsah, a ukazuje, jak se šíří (nebo selžou) s tím, jak se rozroste časová členitost. Všimněte si, jak minimum a maximum značí, že existují základní anomálie, zatímco průměr a součty ztratí informace, jakmile se vaše časová členitost rozroste.

Můžete také vidět, že hodnoty NUL poskytují lepší výpočet průměru, než kdyby se místo toho použily nuly.

Poznámka:

I když ne v tomto příkladu, count se rovná součet v případech, kdy se metrika vždy zachycuje s hodnotou 1. To je běžné, když metrika sleduje výskyt transakční události – například počet selhání HTTP uvedených v předchozím příkladu v tomto článku.

Další kroky