Project Flash – Az Azure Resource Health használata az Azure-beli virtuális gépek rendelkezésre állásának monitorozásához

Cikk
02/12/2024

Az Azure Resource Health a Flash egyik megoldása. A Flash egy olyan projekt belső neve, amelynek célja egy robusztus, megbízható és gyors mechanizmus létrehozása az ügyfelek számára a virtuális gép (VM) állapotának figyelésére.

Ez a cikk az Azure Resource Health azure-beli virtuális gépek rendelkezésre állásának figyelésére való használatát ismerteti. A Flash-megoldások általános áttekintését a Flash áttekintésében találja.

A Flash által kínált egyéb megoldásokra vonatkozó dokumentációt az alábbi cikkekből választhatja ki:

Azure Resource Health

A portálon keresztül azonnali és felhasználóbarát állapot-ellenőrzéseket biztosít az egyes erőforrásokhoz. Az ügyfelek gyorsan hozzáférhetnek az erőforrás-állapot panelhez a portálon, és áttekinthetik az állapotellenőrzések 30 napos előzményrekordját is, így kiváló eszköz a gyors és egyszerű hibaelhárításhoz. A meglévő Azure Resource Health szolgáltatás segít diagnosztizálni és támogatást kapni az Azure-erőforrásokat érintő szolgáltatásproblémákhoz. Jelentéseket készít az erőforrások aktuális és múltbeli állapotáról, és megjeleníti azokat az időtartományokat, amelyeken az egyes erőforrások nem érhetők el.

Tudjuk azonban, hogy ügyfeleinket és partnereinket érdekli, hogy mi okozza a mögöttes technikai problémákat, és javítani szeretné, hogyan kaphatnak kommunikációt bármilyen problémáról – hogy beépüljenek a monitorozási folyamatokba, elmagyarázzák a csuklásokat más érdekelt feleknek, és végül tájékoztassák az üzleti döntéseket.

Az Azure Resource Health virtuálisgép-problémáinak alapvető okai

Nemrég javítottuk az erőforrás-állapotot, amely javítja az ügyfelekkel a virtuális gépek hibáival kapcsolatos információkat, és további kontextust biztosít a probléma kiváltó okával kapcsolatban. Amellett, hogy gyors értesítést kap a virtuális gép rendelkezésre állásáról, az ügyfelek egy későbbi időpontban számíthatnak a kiváltó ok hozzáadására, miután az automatikus kiváltó okelemzési (RCA) rendszer azonosítja a virtuális gép meghibásodásához vezető sikertelen Azure-platformösszetevőt. Tekintsünk át egy példát, amelyből megtudhatja, hogyan működik ez a folyamat a gyakorlatban:

A T1 időpontban a kiszolgálóállvány hálózatkezelési probléma miatt offline állapotba kerül, ami miatt az állványon lévő virtuális gépek megszakadnak a kapcsolatuk. A hálózati architektúra legutóbbi megbízhatósági fejlesztései meg lesznek osztva egy jövőbeli , előrehaladt megbízhatósági blogbejegyzésben – tekintse meg ezt a helyet!

A T2 időpontban az Azure belső monitorozása felismeri, hogy nem éri el az állványon lévő virtuális gépeket, és úgy kezd enyhíteni, hogy az érintett virtuális gépeket egy új állványra helyezi át. Ez idő alatt a rendszer egy megjegyzést küld az erőforrás-állapotnak, amely értesíti az ügyfeleket arról, hogy a virtuális gép jelenleg érintett, és nem érhető el.

A T3 időpontban az állványkapcsoló tetejéről, a gazdagépről és a belső monitorozási rendszerekről származó platformtelemetria az RCA motorban össze van kapcsolva a hiba kiváltó okának kinyerése érdekében. A számítást követően az RCA újra közzé lesz téve az erőforrás-állapotban, valamint a vonatkozó architekturális rugalmassági javaslatokat, amelyeket az ügyfelek a jövőben a hatás valószínűségének minimalizálása érdekében implementálhatnak.

Bár a kezdeti állásidő-értesítési funkció több éves, a kiváltó okokra vonatkozó utasítás közzététele új kiegészítés. Most vizsgáljuk meg, hogyan származtatjuk ezeket a kiváltó okokat.

Alapvető okok elemzési motorja

Tekintsük meg közelebbről az előző példát, és tekintsük át az RCA motor működésének és a mögöttes technológiának a részleteit. A virtuális gépekhez készült RCA motor középpontjában az Azure Data Explorer (ADX) áll, amely egy nagy mennyiségű naplótelemetria-elemzésre optimalizált big data szolgáltatás. Az Azure Data Explorer lehetővé teszi a naplótelemetria terabájtjainak egyszerű elemzését az Azure-platformot alkotó eszközökről és szolgáltatásokról, összekapcsolhatja őket, és értelmezheti a korrelált információstreameket a különböző hibaforgatókönyvek kiváltó okának kinyerése érdekében. Ez egy többhelyes adatfeldolgozási folyamat lesz:

1. fázis: Állásidő észlelése

A kiváltó okok elemzésének első fázisa annak a triggernek a meghatározása, amely alatt az elemzés végrehajtásra kerül. A virtuális gépek esetében meg szeretnénk határozni a kiváltó okokat, amikor egy virtuális gép váratlanul újraindul, ezért az eseményindító egy virtuális gép, amely egy felfelé irányuló állapotról lefelé vált. A platformtelemetriaváltások azonosítása a legtöbb forgatókönyvben egyszerű, de bonyolultabb bizonyos típusú infrastruktúra-hibák esetén, ahol a platform telemetriai adatai elveszhetnek eszközhiba vagy áramkimaradás miatt. A hibák ezen osztályainak kezeléséhez más technikákra is szükség van– például az adatvesztés nyomon követése a virtuális gépek rendelkezésre állási átmenetének lehetséges jelzéseként. Az Azure Data Explorer a sorozatelemzés ezen időszakában kiválóan működik, és részletesebben is áttekintheti a folyamathoz kapcsolódó technikákat a Microsoft Tech Communityben: Az állásidő kiszámítása az Azure Data Explorer ablakfüggvényeivel és idősorfüggvényeivel.

2. fázis: Korrelációs elemzés

Az eseményindító esemény definiálása után (ebben az esetben egy nem kifogástalan állapotba áttűnő virtuális gép) a következő fázis a korrelációs elemzés. Ebben a lépésben az eseményindító esemény jelenlétével korreláljuk a telemetriát az Azure-platform különböző pontjairól, például:

Azure-gazdagép: a virtuális gépeket üzemeltető fizikai panel.
TOR: az állvány hálózati kapcsolójának felső része.
Azure Storage: az Azure-beli virtuális gépek virtuális lemezeit üzemeltető szolgáltatás.

Mindegyik rendszer saját telemetriai hírcsatornákkal rendelkezik, amelyeket elemezni és korrelálni kell a virtuális gép állásidejű eseményindító eseményével. Ez a folyamat a virtuális gép függőségi gráfjának és a mögöttes rendszereknek a megismerésével történik, amelyek a virtuális gép meghibásodását okozhatják, majd összekapcsolják a függő rendszerek állapottelemetriainak összes elemét, szűrve azokat az eseményeket, amelyek a virtuális gép áttűnésének idejének közelében történtek. Az Azure Data Explorer intuitív és hatékony lekérdezési nyelve olyan dokumentált mintákat kínál, mint például az időablak-illesztés az időbeli telemetriai adatfolyamok korrelációjához. Ennek a korrelációs folyamatnak a végén van egy adatkészletünk, amely a virtuális gépek állásidejű áttűnését jelöli az összes függő rendszer korrelált platform telemetriájával, amely a virtuális gép meghibásodásához vezethet, vagy hasznos információkkal rendelkezhet.

3. fázis: Kiváltó ok hozzárendelése

A folyamat következő lépése a hozzárendelés. Most, hogy az összes releváns adatot egyetlen adathalmazban gyűjtöttük össze, a hozzárendelési szabályok érvényesek lesznek az információk értelmezésére és egy ügyfél által elérhető kiváltó ok-megállapításra való lefordítására. Ha visszatér egy TOR-hiba eredeti példájához, a korrelációs elemzés után számos érdekes információval rendelkezünk. Előfordulhat például, hogy az Azure-gazdagépeket figyelő rendszerek naplói azt jelzik, hogy ez idő alatt megszakadt a kapcsolatuk a gazdagépekkel. A virtuális lemez csatlakozási problémáival kapcsolatos jelek, valamint a TOR-eszköz kifejezett jelzései is lehetnek a hibával kapcsolatban. Ezeket az információkat most átolvasjuk, és az explicit TOR hibajelzés a többi jel fölé kerül, mint a kiváltó ok. Ez a rangsorolási folyamat és a mögöttes szabályok tartományi szakértőkkel vannak létrehozva, és az Azure-platform fejlődésével együtt módosulnak. A gépi tanulási és anomáliadetektálási mechanizmusok ezen attribútumokkal kapcsolatos alapvető okokra támaszkodnak, amelyek segítenek azonosítani a besorolási szabályok fejlesztésének lehetőségeit, és észlelni a hibák gyakoriságának változását a biztonságos üzembehelyezési folyamatokba való visszacsatolás érdekében.

4. fázis: RCA-közzététel

Az utolsó lépés a kiváltó okok közzététele az Azure Resource Health-ben, ahol azok láthatóvá válnak az ügyfelek számára. A közzétételt egy egyszerű Azure Functions-alkalmazás végzi, amely rendszeresen lekérdezi a feldolgozott kiváltó ok adatait az Azure Data Explorerben, és kibocsátja az eredményeket az erőforrás-állapot háttérrendszerében. Mivel az adatfolyamok különböző adatkésésekkel járhatnak, az RCA-k időnként frissíthetők ebben a folyamatban, hogy jobban tükrözzék az eredetileg közzétett információforrásokat.

Tovább

Az ügyfelekkel és partnerekkel kapcsolatos problémák kiváltó okának azonosítása és közlése még csak a kezdet. Előfordulhat, hogy ügyfeleinknek át kell venniük ezeket az RCA-kat, és meg kell osztaniuk őket az ügyfeleikkel és munkatársaikkal. Az itt található munkára szeretnénk építeni, hogy könnyebben azonosíthatók és nyomon követhetők legyenek az erőforrás-hitelesítésszolgáltatók, és könnyen megosszuk őket. Ennek érdekében dolgozunk a háttérbeli módosításokon, hogy egyedi erőforrásonkénti és állásidőnkénti nyomon követési azonosítókat hozhassunk létre, amelyeket elérhetővé tehetünk Önnek, így könnyedén egyeztetheti az állásidőket az RCA-kkal. Dolgozunk az új funkciókon is, hogy megkönnyítsük az rca-k e-mail-küldéséhez szükséges e-maileket, és végül előfizessünk az RCA-kra a virtuális gépekre. Ez a funkció lehetővé teszi, hogy közvetlenül a Beérkezett üzenetek mappában regisztráljon az RCA-kra egy elérhetetlenségi esemény után, és nincs szükség további műveletre az Ön részéről.

Következő lépések

Ha többet szeretne megtudni a kínált megoldásokról, folytassa a megfelelő megoldási cikkel:

Az Azure-beli virtuális gépek monitorozásának általános áttekintéséért tekintse meg az Azure-beli virtuális gépek monitorozását és az Azure-beli virtuális gépek monitorozását ismertető referenciát.

Megosztás a következőn keresztül: