Az Azure Monitor-metrikák aggregációjának és megjelenítésének ismertetése
Ez a cikk az Azure Monitor idősoros adatbázisában található metrikák összesítését ismerteti, amelyek az Azure Monitor platformmetrikáit és egyéni metrikáit tartalmazzák. Ez a cikk a standard alkalmazás Elemzések metrikákra is vonatkozik.
A cikk tartalma összetett jellegű, és nem szükséges megérteni az Azure Monitor-metrikák hatékony használatát.
Áttekintés és kifejezések
Amikor metrikát ad hozzá egy diagramhoz, a metrikakezelő automatikusan előre kiválasztja az alapértelmezett összesítést. Az alapforgatókönyvekben az alapértelmezettnek van értelme, de különböző összesítések használatával további elemzéseket kaphat a metrikáról. A különböző aggregációk diagramon való megtekintéséhez tisztában kell lenni azzal, hogy a Metrikák kezelője hogyan kezeli őket.
Először határozzunk meg néhány kifejezést:
- Metrikaérték – Egy adott erőforráshoz gyűjtött egyetlen mérési érték.
- Idősoros adatbázis – Az adatpontok tárolására és lekérésére optimalizált adatbázis, amely egy értéket és egy megfelelő időbélyeget tartalmaz.
- Időtartam – Általános időtartam.
- Időintervallum – Két metrikaérték összegyűjtése közötti időszak.
- Időtartomány – A diagramon megjelenített időtartam. Az alapértelmezett érték általában 24 óra. Csak bizonyos tartományok érhetők el.
- Időrészletesség vagy időfelbontás – Az értékek összesítésére használt idő, amely lehetővé teszi a diagramon való megjelenítést. Csak bizonyos tartományok érhetők el. Az aktuális minimum 1 perc. Az időrészletesség értékének kisebbnek kell lennie a kiválasztott időtartománynál, hogy hasznos legyen, ellenkező esetben csak egy érték jelenik meg a teljes diagramon.
- Összesítés típusa – Több metrikaértékből számított statisztikai típus.
- Összesítés – Több bemeneti érték beírásának folyamata, majd az összesítési típus által meghatározott szabályokon keresztül egyetlen kimeneti érték létrehozása. Például több érték átlagának figyelembe vételével.
A folyamat összefoglalása
A metrikák időbélyeggel tárolt értékek sorozatai. Az Azure-ban a legtöbb metrika az Azure Metrics idősorozat-adatbázisában van tárolva. Diagram ábrázolásakor a rendszer lekéri a kiválasztott metrikák értékeit az adatbázisból, majd külön összesíti a kiválasztott időrészletesség (más néven időfelbontás) alapján. Az időrészletesség méretét a metrikaböngésző időválasztó használatával választhatja ki. Ha nem hoz létre explicit kijelölést, a rendszer automatikusan kiválasztja az idő részletességét az aktuálisan kiválasztott időtartomány alapján. A kiválasztás után az egyes részletességi intervallumok során rögzített metrikaértékek összesítése és a diagramra kerül – intervallumonként egy adatpont.
Összesítési típusok
A metrikák kezelőjében öt alapvető összesítési típus érhető el. A Metrics Explorer elrejti azokat az összesítéseket, amelyek irrelevánsak, és nem használhatók egy adott metrika esetében.
- Összeg – az összesítési intervallumban rögzített összes érték összege. Néha total aggregációnak is nevezik.
- Darabszám – az összesítési intervallumban rögzített mérések száma. A darabszám nem a mérés értékét, csak a rekordok számát veszi figyelembe.
- Átlag – az aggregációs intervallumban rögzített metrikaértékek átlaga. A legtöbb metrika esetében ez az érték összeg/darabszám.
- Min – az összesítési időköz alatt rögzített legkisebb érték.
- Max – az összesítési időköz során rögzített legnagyobb érték.
Tegyük fel például, hogy egy diagram egy virtuális gép hálózat kiugró összegének metrikáit jeleníti meg a SZUM összesítés használatával az elmúlt 24 órás időtartam alatt. Az időtartomány és a részletesség a diagram jobb felső sarkában módosítható az alábbi képernyőképen látható módon.
Az idő részletessége = 30 perc és az időtartomány = 24 óra:
- A diagram 48 adatpontból származik. Ez óránként 24 óra x 2 adatpont (60 perc/30 perc) összesített 1 perces adatpontok.
- A vonaldiagram 48 elemet kapcsol össze a diagramdiagram területén.
- Az egyes adatpontok a vonatkozó 30 perces időszakokban kiküldött hálózati kimenő bájtok összegét jelölik.
A nagyobb verziók megtekintéséhez kattintson az ebben a szakaszban található képekre.
Ha az időrészletesség 15 percre van állítva, a diagram 96 összesített adatpontból lesz rajzolva. Vagyis 60 perc/15 perc = 4 adatpont óránként x 24 óra.
5 perces részletesség esetén 24 x (60/5) = 288 pontot kap.
Az 1 perces részletesség (a diagramon a lehető legkisebb) esetében 24 x 60/1 = 1440 pontot kap.
A diagramok az előző képernyőképeken látható módon eltérően jelennek meg ezeknél az összegzésekben. Figyelje meg, hogy ez a virtuális gép kis idő alatt számos kimenettel rendelkezik az időkeret többi részéhez képest.
Az idő részletessége lehetővé teszi a diagram "jel-zaj" arányának beállítását. A magasabb aggregációk eltávolítják a zajt és kisimítják a tüskéket. Figyelje meg az alsó 1 perces diagram variációit, és hogy hogyan simulnak ki, miközben magasabb részletességi értékeket ér el.
Ez a simítási viselkedés akkor fontos, ha ezeket az adatokat más rendszereknek küldi el , például riasztások. Általában nem szeretné, ha a processzoridő 90%-nál hosszabb rövid csúcsai figyelmeztetnek volna. Ha azonban a PROCESSZOR 5 percig 90%-nál marad, az valószínűleg fontos. Ha beállít egy riasztási szabályt a CPU-n (vagy bármely metrikán), az idő részletességének növelése csökkentheti a kapott hamis riasztások számát.
Fontos megállapítani, hogy mi a "normális" a számítási feladat számára, hogy tudja, melyik időintervallum a legjobb. Ez a dinamikus riasztások egyik előnye, amely egy másik, itt nem tárgyalt témakör.
Hogyan gyűjti a rendszer a metrikákat?
Az adatgyűjtés metrika szerint változik.
Feljegyzés
Az alábbi példákat egyszerűbben szemléltetjük, és az egyes összesítésekben szereplő tényleges metrikaadatokat a kiértékelés során rendelkezésre álló adatok befolyásolják.
Mérésgyűjtés gyakorisága
A gyűjtési időszakoknak két típusa van.
Normál – A metrika egy konzisztens időintervallumban lesz összegyűjtve, amely nem változik.
Tevékenységalapú – A metrikát az alapján gyűjti össze a rendszer, hogy mikor történik egy bizonyos típusú tranzakció. Minden tranzakcióhoz tartozik egy metrikabejegyzés és egy időbélyeg. Ezek nem rendszeres időközönként vannak összegyűjtve, így egy adott időszakban változó számú rekord van.
Részletesség
A minimális időrészletesség 1 perc, de a mögöttes rendszer a metrikától függően gyorsabban rögzítheti az adatokat. Az Azure-beli virtuális gépek processzorhasználati százalékos aránya például 15 másodperces időintervallumban lesz rögzítve. Mivel a HTTP-hibák tranzakciókként vannak nyomon követve, könnyen több mint egy percet is meghaladhatnak. Más metrikákat, például az SQL Storage-t 20 percenként rögzíti a rendszer. Ez a választás az egyéni erőforrás-szolgáltatón és típuson múlik. A legtöbben a lehető legkisebb időintervallumot próbálják megadni.
Méretek, felosztás és szűrés
A metrikákat minden egyes erőforráshoz rögzíti a rendszer. A metrikák gyűjtésének, tárolásának és diagramkészítésének szintje azonban eltérő lehet. Ezt a szintet a metrikák dimenzióiban elérhető egyéb metrikák képviselik. Minden egyes erőforrás-szolgáltatónak meg kell határoznia, hogy milyen részletes adatokat gyűjtenek. Az Azure Monitor csak az ilyen részletek bemutatását és tárolását határozza meg.
Amikor egy metrikát ábrázol a Metrikaböngészőben, lehetősége van a diagram dimenzió szerinti "felosztására". A diagramok felosztása azt jelenti, hogy a mögöttes adatokat részletesebben keresi, és az adatokat a metrikakezelőben diagramon vagy szűréssel látja.
A Microsoft.ApiManagement/servicepéldául számos metrika dimenziója a Hely.
A kapacitás egy ilyen metrika. A Hely dimenzió használata azt jelenti, hogy a mögöttes rendszer egy metrikarekordot tárol az egyes helyek kapacitásához, és nem csak egyet az összesített mennyiséghez. Ezután lekérheti vagy feloszthatja ezeket az adatokat egy metrikadiagramon.
Az átjárókérések teljes időtartamát tekintve 2 dimenzióból áll a Hely és a Gazdagépnév, amely szintén jelzi az időtartam helyét és azt, hogy melyik állomásnévből származik.
Az egyik rugalmasabb metrika, a Kérések 7 különböző dimenzióval rendelkezik.
Az egyes metrikákról és az elérhető dimenziókról az Azure Monitor által támogatott metrikákról szóló cikkben tájékozódhat. Emellett az egyes erőforrás-szolgáltatók és -típusok dokumentációja további információkat nyújthat a dimenziókról és a mértékekről.
A felosztás és a szűrés együttes használatával feltárhatja a problémát. Az alábbiakban egy ábra látható, amely egy erőforráscsoport virtuális gépcsoportjához tartozó Avg Disk Write Bytes-et mutatja. A metrika összes virtuális gépét összesítjük, de érdemes lehet megnézni, hogy melyik felelős a 6 óra körüli csúcsokért. Ugyanaz a gép? Hány gépről van szó?
A nagyobb verziók megtekintéséhez kattintson az ebben a szakaszban található képekre.
Ha felosztást alkalmazunk, láthatjuk a mögöttes adatokat, de ez egy kicsit zavaros. Kiderült, hogy a fenti diagramon 20 virtuális gép van összesítve. Ebben az esetben az egérrel rámutattunk a nagy csúcsra 6:00-kor, ami azt jelzi, hogy a CH-DCVM11 az oka. A többi, a virtuális géphez társított adat azonban nehezen látható, mert más virtuális gépek zsúfolták a diagramot.
A szűréssel megtisztíthatjuk a diagramot, hogy lássuk, mi történik valójában. Ellenőrizheti vagy törölheti a megtekinteni kívánt virtuális gépeket. Figyelje meg a pontozott vonalakat. Ezekről egy későbbi szakaszban olvashat.
Az osztott dimenzióadatok metrikaböngésző diagramon való megjelenítéséről további információt a Metrikák kezelőjének speciális funkciói – szűrők és felosztások című témakörben talál.
NULL és nulla értékek
Amikor a rendszer metrikaadatokat vár egy erőforrástól, de nem kapja meg, null értéket rögzít. A NULL érték különbözik a nulla értékétől, ami fontossá válik az összesítések és diagramok kiszámításában. A NULL értékek nem számítanak érvényes méréseknek.
A NULL-ek eltérően jelennek meg a különböző diagramokon. A pontdiagramok kihagyják a diagram egy pontjának megjelenítését. A sávdiagramok kihagyják a sáv megjelenítését. A vonaldiagramokon a NULL pontozott vagy szaggatott vonalként jelenhet meg, mint az előző szakasz képernyőképén. A NULL-eket tartalmazó átlagok kiszámításakor kevesebb adatpontot kell figyelembe venni. Ez a viselkedés néha váratlan értékcsökkenést eredményezhet egy diagramon, de kevésbé, mint ha az értéket nullává konvertálták, és érvényes adatpontként használták.
Az egyéni metrikák mindig NULL-eket használnak, ha nem érkeznek adatok. A platformmetrikák esetében az egyes erőforrás-szolgáltatók eldöntik, hogy nullákat vagy NULL-eket használnak-e az adott metrika legértelmesebb metrikái alapján.
Az Azure Monitor-riasztások az erőforrás-szolgáltató által a metrikaadatbázisba írt értékeket használják, ezért fontos tudni, hogy az erőforrás-szolgáltató hogyan kezeli a NULL-eket az adatok első megtekintésével.
Az összesítés működése
Az előző rendszer metrikadiagramjai különböző típusú összesített adatokat mutatnak. A rendszer előre összesíti az adatokat, hogy a kért diagramok gyorsabban jelenjenek meg számos ismétlődő számítás nélkül.
Ebben a példában:
- Egy fiktív tranzakciós metrikát gyűjtünk HTTP-hibáknak nevezett
- A kiszolgáló a HTTP-hibák metrikájának dimenziója .
- 3 kiszolgálónk van – A, B és C kiszolgáló.
A magyarázat egyszerűsítése érdekében csak a SZUM összesítés típusával kezdjük.
Alperc és 1 perces összesítés
Az első nyers metrikaadatok gyűjtése és tárolása az Azure Monitor metrikák adatbázisában történik. Ebben az esetben minden kiszolgáló rendelkezik időbélyeggel tárolt tranzakciórekordokkal, mivel a kiszolgáló dimenzió. Mivel az ügyfélként megtekinthető legkisebb időtartam 1 perc, az időbélyegek először 1 perces metrikaértékekké lesznek összesítve minden egyes kiszolgáló esetében. A B kiszolgáló összesítési folyamata az alábbi ábrán látható. Az A és a C kiszolgálók ugyanúgy vannak végrehajtva, és eltérő adatokkal rendelkeznek.
Az eredményül kapott 1 perces összesített értékek új bejegyzésként lesznek tárolva a metrikák adatbázisában, hogy későbbi számításokhoz gyűjthetők legyenek.
Dimenzióösszesítés
Az 1 perces számítások ezután dimenzió szerint összecsukódnak, és ismét egyedi rekordként vannak tárolva. Ebben az esetben a rendszer az összes egyes kiszolgáló összes adatát egy 1 perces időközi metriká összesíti, és a metrikák adatbázisában tárolja a későbbi összesítésekben való felhasználás céljából.
Az egyértelműség kedvéért az alábbi táblázat az összesítés módját mutatja be.
| Időszak | „A” kiszolgáló | „B” kiszolgáló | „C” kiszolgáló | Összeg (A+B+C) |
|---|---|---|---|---|
| 1. perc | 0 | 0 | 0 | 3 |
| 2. perc | 0 | 5 | 0 | 6 |
| 3. perc | 0 | 5 | 0 | 6 |
| 4. perc | 2 | 3 | 4 | 9 |
| 5. perc | 0 | 0 | 3 | 4 |
| 6. perc | 0 | 0 | 4 | 5 |
| 7. perc | 0 | 2 | 4 | 7 |
| 8. perc | 0 | 0 | 0 | 0 |
| 9. perc | 0 | 0 | 4 | 6 |
| 10. perc | 2 | 0 | 0 | 3 |
A fentiekben csak egy dimenzió jelenik meg, de ez az összesítési és tárolási folyamat minden olyan dimenzió esetében megtörténik, amelyet a metrikák támogatnak.
- Gyűjtse össze az értékeket az adott dimenzió által beállított 1 perces összesített értékre. Tárolja ezeket az értékeket.
- A dimenzió összecsukása egy 1 perces összesített SZUM-ra. Tárolja ezeket az értékeket.
Vizsgáljuk meg a NetworkAdapter nevű HTTP-hibák egy másik dimenzióját. Tegyük fel, hogy kiszolgálónként eltérő számú adaptert használtunk.
- Az A kiszolgáló 1 adapterrel rendelkezik
- A B kiszolgáló 2 adapterrel rendelkezik
- A C kiszolgáló 3 adapterrel rendelkezik
Az alábbi tranzakciók adatait külön gyűjtenénk. Ezek a következőkkel lennének megjelölve:
- Idő
- Egy érték
- A kiszolgáló, ahonnan a tranzakció származik
- Az adapter, amelyből a tranzakció származik
Az egyes alárendelt streamek ezután 1 perces idősorértékekké lesznek összesítve, és az Azure Monitor metrikaadatbázisában lesznek tárolva:
- A kiszolgáló, 1. adapter
- B kiszolgáló, 1. adapter
- B kiszolgáló, 2. adapter
- C kiszolgáló, 1. adapter
- C kiszolgáló, 2. adapter
- C kiszolgáló, 3. adapter
Emellett a következő összecsukott összesítések is tárolódnak:
- A kiszolgáló, 1. adapter (mivel nincs semmi összecsukható, a rendszer újra tárolná)
- B kiszolgáló, 1+2 adapter
- C kiszolgáló, 1+2+3 adapter
- KISZOLGÁLÓK ALL, Adapterek ALL
Ez azt mutatja, hogy a nagy méretű metrikák nagyobb számú aggregációval rendelkeznek. Nem fontos ismerni az összes permutációt, csak megérteni az érvelést. A rendszer az egyes adatokat és az összesített adatokat is tárolni szeretné a gyors lekéréshez a diagramokon való hozzáféréshez. A rendszer a leginkább releváns tárolt aggregációt vagy a mögöttes nyers adatokat választja attól függően, hogy mit szeretne megjeleníteni.
Dimenziók nélküli összesítés
Mivel ez a metrika dimenziókiszolgálóval rendelkezik, felosztással és szűréssel hozzáférhet a fenti A, B és C kiszolgáló alapjául szolgáló adatokhoz, amint azt a cikk korábbi részében ismertetjük. Ha a metrika nem rendelkezik a Kiszolgáló dimenzióval, Ön mint ügyfél csak a diagramon fekete színben megjelenített összesített 1 perces összegeket érheti el. Vagyis a 3, 6, 6, 9 stb. értékek. A rendszer emellett nem végezné el az alapul szolgáló munkát a felosztási értékek összesítéséhez, amelyet soha nem használna a metrikakezelőben, és nem küldené el őket a metrikák REST API-jában keresztül.
1 percnél hosszabb időrészletek megtekintése
Ha nagyobb részletességgel kér metrikákat, a rendszer az 1 perces összesített összegeket használja a nagyobb időrészletek összegének kiszámításához. Az alábbiakban a pontozott vonalak a 2 perces és az 5 perces időrészletek összegzési módszerét mutatják be. Az egyszerűség kedvéért ismét csak a SZUM aggregációs típust jelenítjük meg.
A 2 perces részletességért.
| Időszak | Összegeket |
|---|---|
| 1. perc és 2. perc | (3 + 6) = 9 |
| 3. perc és 4. perc | (6 + 9) = 15 |
| 4. perc és 5. perc | (4 + 5) = 9 |
| 6. perc és 7. perc | (7 + 1) = 8 |
| 8. perc és 9. perc | (6 + 3) = 9 |
5 perces részletességért.
| Időszak | Összegeket |
|---|---|
| 1–5. perc | 3 + 6 + 6 + 9 + 4 = 28 |
| 6–10. perc | 5 + 7 + 1 + 6 + 3 = 22 |
A rendszer a legjobb teljesítményt nyújtó tárolt összesített adatokat használja.
Az alábbiakban látható a fenti 1 perces összesítési folyamat nagyobb diagramja, amelyen néhány nyíl ki van hagyva az olvashatóság javítása érdekében.
Összetettebb példa
Az alábbiakban egy nagyobb példát mutatunk be, amely egy fiktív metrika, az úgynevezett HTTP-válaszidő értékeit használja ezredmásodpercben. Itt a komplexitás egyéb szintjeit mutatjuk be.
- Az Összeg, a Darabszám, a Min és a Max, valamint az Átlag számítása összesítését jelenítjük meg.
- A NULL értékeket és azok számításra gyakorolt hatását mutatjuk be.
Gondolja át a következő példát. A mezők és nyilak példákat mutatnak az értékek összesítésére és kiszámítására.
Az előző szakaszban ismertetett 1 perces összesítési folyamat az Összegek, a Darabszám, a Minimum és a Maximum értékre vonatkozik. Az átlag azonban NEM előre van összesítve. A számítási hibák elkerülése érdekében a rendszer újraszámítja az összesített adatok használatával.
Az 1 perces összesítés 6. percét vegye figyelembe a fent kiemelt módon. Ez a perc az a pont, ahol a B kiszolgáló offline állapotba került, és leállította az adatok jelentését, talán egy újraindítás miatt.
A fenti 6. perctől kezdődően a számított 1 perces összesítési típusok a következők:
| Összesítés típusa | Érték | Jegyzetek |
|---|---|---|
| Sum | 53+20=73 | |
| Count | 2 | A NULL-ek hatását jeleníti meg. Az érték 3 lett volna, ha a kiszolgáló online állapotban lett volna. |
| Minimum | 20 | |
| Maximum | 53 | |
| Átlag | 73 / 2 | Mindig a Darabszám osztva összeg. A rendszer soha nem tárolja, és mindig újraszámítja minden egyes részletességhez az adott részletesség összesített számainak használatával. Figyelje meg az 5 perces és a 10 perces részletességű újraszámítást a fent kiemelt módon. |
A piros szövegszín azokat az értékeket jelzi, amelyek a normál tartományon kívülre kerülhetnek, és az időrészletesség előrehaladtával megjeleníti a propagálási (vagy sikertelen) propagálási módját. Figyelje meg, hogy a Min és a Max jelzi, hogy vannak mögöttes anomáliák, miközben az átlag és az összegek elveszítik ezeket az információkat az időrészletesség előrehaladtával.
Azt is láthatja, hogy a NULL-ek jobb átlagszámítást adnak, mint ha a nullákat használták volna.
Feljegyzés
Bár ebben a példában nem ez a helyzet, a Darabszám egyenlő az összeggel azokban az esetekben, amikor a metrikák mindig 1 értékkel vannak rögzítve. Ez gyakori, ha egy metrika nyomon követi egy tranzakciós esemény előfordulását – például a jelen cikkben egy korábbi példában említett HTTP-hibák számát.