Project Flash – Monitorování dostupnosti virtuálních počítačů Azure pomocí služby Azure Resource Health

Článek
02/14/2024

Azure Resource Health je jedno řešení, které nabízí Flash. Flash je interní název projektu vyhrazeného pro vytvoření robustního, spolehlivého a rychlého mechanismu, který zákazníkům umožňuje monitorovat stav virtuálního počítače.

Tento článek popisuje použití služby Azure Resource Health k monitorování dostupnosti virtuálních počítačů Azure. Obecný přehled řešení Flash najdete v přehledu aplikace Flash.

Pro dokumentaci specifickou pro ostatní řešení, která flash nabízí, si vyberte z následujících článků:

Azure Resource Health

Prostřednictvím portálu nabízí okamžité a uživatelsky přívětivé kontroly stavu jednotlivých prostředků. Zákazníci můžou rychle přistupovat k okně stavu prostředků na portálu a také si prohlédnout 30denní historický záznam kontrol stavu, což představuje vynikající nástroj pro rychlé a jednoduché řešení potíží. Stávající funkce služby Azure Resource Health vám pomůže diagnostikovat a získat podporu problémů se službami, které ovlivňují vaše prostředky Azure. Hlásí aktuální a minulý stav vašich prostředků a zobrazuje všechny časové rozsahy, které byly pro každý z vašich prostředků nedostupné.

Víme ale, že naši zákazníci a partneři mají zájem pochopit, co způsobuje základní technické problémy, a zlepšit způsob, jakým můžou přijímat komunikaci o jakýchkoli problémech – za účelem podávání do monitorovacích procesů, vysvětlení hiccupů ostatním zúčastněným stranám a nakonec informování obchodních rozhodnutí.

Původní příčiny problémů s virtuálním počítačem ve službě Azure Resource Health

Nedávno jsme odeslali vylepšení prostředí stavu prostředků, které zlepší informace, které sdílíme se zákazníky o selhání virtuálních počítačů, a poskytneme další kontext původní příčiny, která vedla k problému. Kromě rychlého oznámení při ovlivnění dostupnosti virtuálního počítače můžou zákazníci očekávat přidání původní příčiny později, jakmile náš systém RCA (Automated Root Cause Analysis) identifikuje neúspěšnou komponentu platformy Azure, která vedla k selhání virtuálního počítače. Pojďme si projít příklad, jak tento proces funguje v praxi:

V době T1 serverový rack přejde kvůli problému se sítí do režimu offline, což způsobuje ztrátu připojení virtuálních počítačů v racku. Nedávná vylepšení spolehlivosti související s architekturou sítě budou sdílena v budoucím blogovém příspěvku Pro zvýšení spolehlivosti – podívejte se na tento prostor!

V době T2 interní monitorování Azure rozpozná, že se nemůže spojit s virtuálními počítači v racku a začne se zmírnit opětovným nasazením ovlivněných virtuálních počítačů do nového racku. Během této doby se do stavu prostředků odešle poznámka, která zákazníkům oznámí, že jejich virtuální počítač je aktuálně ovlivněný a nedostupný.

V době T3 se telemetrie platformy z horní části přepínače racku, hostitelského počítače a interních monitorovacích systémů korelují v našem modulu RCA a odvozují původní příčinu selhání. Po výpočtu se analýza RCA pak publikuje zpět do stavu prostředků spolu s relevantními doporučeními k odolnosti architektury, která zákazníci můžou implementovat, aby minimalizovali pravděpodobnost dopadu v budoucnu.

I když je funkce oznámení o počátečním výpadku několik let stará, publikování příkazu původní příčiny je novým doplňkem. Teď se podíváme na podrobnosti o tom, jak tyto původní příčiny odvozujeme.

Modul pro analýzu původní příčiny

Pojďme se podrobněji podívat na předchozí příklad a projít si podrobnosti o tom, jak modul RCA funguje a jaká technologie za ním stojí. Jádrem našeho modulu RCA pro virtuální počítače je Azure Data Explorer (ADX) služba pro velké objemy dat optimalizovaná pro analýzy telemetrie protokolů s velkým objemem. Azure Data Explorer umožňuje snadno analyzovat terabajty telemetrie protokolů ze zařízení a služeb, které tvoří platformu Azure, spojit je a interpretovat korelované informační proudy, aby odvozovaly původní příčinu různých scénářů selhání. Výsledkem je proces přípravy dat s více kroky:

Fáze 1: Detekce výpadků

První fází analýzy původní příčiny je definování triggeru, pod kterým se analýza provádí. U virtuálních počítačů chceme určit původní příčiny pokaždé, když se virtuální počítač neočekávaně restartuje, takže triggerem je virtuální počítač, který přechází ze stavu nahoru do stavu dolů. Identifikacetěchtoch dat z telemetrie platformy je ve většině scénářů jednoduchá, ale složitější je situace, kdy dojde ke ztrátě telemetrie platformy kvůli selhání zařízení nebo ztrátě napájení. Ke zpracování těchto tříd selhání jsou potřeba další techniky, jako je sledování ztráty dat jako možné označení přechodu dostupnosti virtuálního počítače. Azure Data Explorer v současnosti exceluje v této době analýzy řad a podrobnější pohled na techniky tohoto procesu najdete v technické komunitě Microsoftu: Výpočet výpadků pomocí funkcí okna a funkcí časové řady v Azure Data Exploreru.

Fáze 2: Analýza korelace

Jakmile je událost triggeru definovaná (v tomto případě virtuální počítač přechází do stavu není v pořádku), další fáze je analýza korelace. V tomto kroku použijeme přítomnost aktivační události ke korelaci telemetrie z bodů napříč platformou Azure, například:

Hostitel Azure: Fyzické okno hostující virtuální počítače.
TOR: horní část síťového přepínače racku.
Azure Storage: služba, která hostuje virtuální disky pro virtuální počítače Azure.

Každý z těchto systémů má vlastní informační kanály telemetrie, které je potřeba analyzovat a korelovat s událostí triggeru výpadku virtuálního počítače. Tento proces se provádí prostřednictvím pochopení grafu závislostí pro virtuální počítač a základních systémů, které můžou způsobit selhání virtuálního počítače, a následným propojením telemetrie stavu všech těchto závislých systémů a filtrováním událostí, ke kterým došlo v blízkosti doby přechodu virtuálního počítače. Intuitivní a výkonný dotazovací jazyk Azure Data Exploreru pomáhá tím, že nabízí zdokumentované vzory, jako je spojení časových intervalů pro korelaci dočasných telemetrických streamů. Na konci tohoto procesu korelace máme datovou sadu, která představuje přechody výpadků virtuálních počítačů s korelací telemetrie platformy ze všech závislých systémů, které by mohly způsobit nebo mohly mít užitečné informace při určování toho, co vedlo k selhání virtuálního počítače.

Fáze 3: Přiřazení původní příčiny

Dalším krokem v procesu je přisuzování. Teď, když jsme shromáždili všechna relevantní data v jedné datové sadě, se pravidla přisuzování použijí k interpretaci informací a jejich překladu do příkazu původní příčiny, který se vztahuje na zákazníka. Pokud se vrátíte k našemu původnímu příkladu selhání TOR, můžeme po analýze korelace mít mnoho zajímavých informací k interpretaci. Například systémy monitorující hostitele Azure můžou mít protokoly, které během této doby ztratily připojení k hostitelům. Můžeme mít také signály související s problémy s připojením k virtuálním diskům a explicitní signály ze zařízení TOR týkající se selhání. Všechny tyto informace jsou nyní zkontrolovány a explicitní signál selhání TOR je upřednostněn u ostatních signálů jako původní příčina. Tento proces stanovení priority a pravidla za ním se vytvářejí s odborníky na doménu a mění se s tím, jak se platforma Azure vyvíjí. Mechanismy strojového učení a detekce anomálií jsou nad těmito přiřazovanými hlavními příčinami, které pomáhají identifikovat příležitosti ke zlepšení těchto klasifikačních pravidel a zjišťování změn vzorů v míře těchto selhání, aby se vrátily do kanálů bezpečného nasazení.

Fáze 4: Publikování RCA

Posledním krokem je publikování původních příčin ve službě Azure Resource Health, kde se stanou viditelnými pro zákazníky. Publikování provádí jednoduchá aplikace Azure Functions , která pravidelně dotazuje zpracovaná data původní příčiny v Azure Data Exploreru a vygeneruje výsledky back-endu stavu prostředků. Vzhledem k tomu, že datové proudy informací mohou přicházet s různými zpožděními dat, můžou se v tomto procesu občas aktualizovat analýzy RCA, aby odrážely lepší zdroje informací, které byly doručeny, což vede k konkrétnější původní příčině, která byla původně publikována.

Do budoucna

Identifikace a komunikace původní příčiny jakýchkoli problémů s našimi zákazníky a partnery je teprve začátek. Naši zákazníci možná budou muset tyto analýzy RCA vzít a sdílet je se svými zákazníky a spolupracovníky. Chceme na této práci stavět, abychom usnadnili identifikaci a sledování analýzy RCA prostředků a mohli je snadno sdílet. Abychom toho dosáhli, pracujeme na změnách back-endu, abychom vygenerovali jedinečné ID sledování jednotlivých prostředků a výpadků, které můžeme vystavit vám, abyste mohli snadno odpovídat výpadkům jejich rcA. Pracujeme také na nových funkcích, abychom usnadnili posílání rcA e-mailem a nakonec se přihlásili k odběru RCA pro vaše virtuální počítače. Tato funkce vám umožní zaregistrovat se do složky RCA přímo ve složce Doručená pošta po události nedostupnosti bez nutnosti další akce na vaší straně.

Další kroky

Další informace o nabízených řešeních najdete v příslušném článku o řešení:

Obecný přehled o monitorování virtuálních počítačů Azure najdete v tématu Monitorování virtuálních počítačů Azure a referenční informace k monitorování virtuálních počítačů Azure.

Sdílet prostřednictvím