Projekt Flash — monitorowanie dostępności maszyny wirtualnej platformy Azure przy użyciu usługi Azure Resource Health

Artykuł
08/24/2024

Usługa Azure Resource Health to jedno rozwiązanie oferowane przez program Flash. Flash to wewnętrzna nazwa projektu przeznaczona do tworzenia niezawodnego, niezawodnego i szybkiego mechanizmu monitorowania kondycji maszyny wirtualnej przez klientów.

W tym artykule opisano korzystanie z usługi Azure Resource Health do monitorowania dostępności maszyny wirtualnej platformy Azure. Aby zapoznać się z ogólnym omówieniem rozwiązań Flash, zobacz Omówienie programu Flash.

Aby uzyskać dokumentację specyficzną dla innych rozwiązań oferowanych przez program Flash, wybierz następujące artykuły:

Azure Resource Health

Oferuje natychmiastowe i przyjazne dla użytkownika kontrole kondycji poszczególnych zasobów za pośrednictwem portalu. Klienci mogą szybko uzyskać dostęp do bloku kondycji zasobów w portalu, a także przejrzeć 30-dniowy rekord historyczny kontroli kondycji, dzięki czemu jest doskonałym narzędziem do szybkiego i prostego rozwiązywania problemów. Istniejąca funkcja usługi Azure Resource Health ułatwia diagnozowanie i uzyskiwanie pomocy technicznej dotyczącej problemów z usługami, które wpływają na zasoby platformy Azure. Raportuje bieżącą i poprzednią kondycję zasobów, pokazując zakresy czasu, w których poszczególne zasoby były niedostępne.

Wiemy jednak, że nasi klienci i partnerzy są zainteresowani zrozumieniem przyczyn podstawowych problemów technicznych oraz poprawy sposobu odbierania komunikacji o wszelkich problemach — w celu uwzględnienia procesów monitorowania, wyjaśnienia czkawki innym uczestnikom projektu i ostatecznie informowania o decyzjach biznesowych.

Główne przyczyny problemów z maszyną wirtualną w usłudze Azure Resource Health

Niedawno dostarczyliśmy ulepszenia środowiska kondycji zasobów, które poprawią informacje, które udostępniamy klientom na temat awarii maszyn wirtualnych i zapewniają dalszy kontekst głównej przyczyny, która doprowadziła do problemu. Teraz, oprócz otrzymywania szybkiego powiadomienia, gdy ma to wpływ na dostępność maszyny wirtualnej, klienci mogą oczekiwać dodania głównej przyczyny w późniejszym momencie, gdy nasz zautomatyzowany system analizy głównej przyczyny (RCA) identyfikuje składnik platformy Azure, który zakończył się niepowodzeniem, co doprowadziło do awarii maszyny wirtualnej. Przyjrzyjmy się przykładowi, aby zobaczyć, jak działa ten proces w praktyce:

W czasie T1 stojak serwerowy przechodzi w tryb offline z powodu problemu z siecią, co powoduje utratę łączności maszyn wirtualnych na stojaku. Najnowsze ulepszenia niezawodności związane z architekturą sieci zostaną udostępnione w przyszłym wpisie w blogu na temat rozwoju niezawodności — obejrzyj tę przestrzeń!

W czasie T2 wewnętrzne monitorowanie platformy Azure rozpoznaje, że nie może nawiązać połączenia z maszynami wirtualnymi na stojaku i zaczyna ograniczać ryzyko ponownego wdrażania maszyn wirtualnych, których dotyczy problem, do nowego stojaka. W tym czasie adnotacja jest wysyłana do kondycji zasobów z powiadomieniem klientów, że ich maszyna wirtualna ma obecnie wpływ na tę maszynę wirtualną i jest niedostępna.

W czasie T3 dane telemetryczne platformy z górnej części przełącznika stojaka, maszyny hosta i wewnętrzne systemy monitorowania są skorelowane ze sobą w naszym aucie głównej przyczyny awarii. Po obliczeniu analiza głównej przyczyny jest następnie publikowana z powrotem w kondycji zasobów wraz z odpowiednimi zaleceniami dotyczącymi odporności architektury, które klienci mogą wdrożyć, aby zminimalizować prawdopodobieństwo wpływu w przyszłości.

Chociaż początkowa funkcja powiadamiania o przestoju ma kilka lat, publikowanie instrukcji głównej przyczyny jest nowym dodatkiem. Teraz przyjrzyjmy się szczegółom sposobu uzyskiwania tych głównych przyczyn.

Aparat analizy głównej przyczyny

Przyjrzyjmy się bliżej poprzedniego przykładowi i omówimy szczegóły działania aparatu analizy głównej przyczyny oraz technologię, która za nią stoi. Podstawowym elementem naszego aparatu analizy głównej przyczyny dla maszyn wirtualnych jest usługa Azure Data Explorer (ADX), usługa danych big data zoptymalizowana pod kątem analizy telemetrii dziennika dużego woluminu. Usługa Azure Data Explorer umożliwia łatwe analizowanie terabajtów danych telemetrycznych dziennika z urządzeń i usług składających się na platformę Azure, łączenie ich ze sobą i interpretowanie skorelowanych strumieni informacji w celu uzyskania głównej przyczyny różnych scenariuszy awarii. Kończy się to wieloetapowym procesem inżynierii danych:

Faza 1. Wykrywanie przestojów

Pierwszą fazą analizy głównej przyczyny jest zdefiniowanie wyzwalacza, w którym jest wykonywana analiza. W przypadku maszyn wirtualnych chcemy określić główne przyczyny po nieoczekiwanym ponownym uruchomieniu maszyny wirtualnej, więc wyzwalacz jest maszyną wirtualną przechodzącą ze stanu w górę do stanu w dół. Identyfikowanie tych przejść z telemetrii platformy jest proste w większości scenariuszy, ale bardziej skomplikowane w przypadku niektórych rodzajów awarii infrastruktury, w których telemetria platformy może zostać utracona z powodu awarii urządzenia lub utraty zasilania. Aby obsłużyć te klasy awarii, wymagane są inne techniki — takie jak śledzenie utraty danych jako możliwe wskazanie przejścia dostępności maszyny wirtualnej. Usługa Azure Data Explorer wyróżnia się w tej chwili analizy serii, a bardziej szczegółowe omówienie technik dotyczących tego procesu można znaleźć w witrynie Microsoft Tech Community: Obliczanie przestojów przy użyciu funkcji okien i funkcji szeregów czasowych w usłudze Azure Data Explorer.

Faza 2. Analiza korelacji

Po zdefiniowaniu zdarzenia wyzwalacza (w tym przypadku maszyna wirtualna przechodząca do stanu złej kondycji) następna faza to analiza korelacji. W tym kroku używamy obecności zdarzenia wyzwalacza do korelowania danych telemetrycznych z punktów na platformie Azure, takich jak:

Host platformy Azure: blok fizyczny hostuje maszyny wirtualne.
TOR: przełącznik sieciowy w górnej części stojaka.
Azure Storage: usługa, która hostuje dyski wirtualne dla maszyn wirtualnych platformy Azure.

Każdy z tych systemów ma własne źródła danych telemetrycznych, które muszą być analizowane i skorelowane ze zdarzeniem wyzwalacza przestoju maszyny wirtualnej. Ten proces odbywa się przez zrozumienie wykresu zależności dla maszyny wirtualnej i systemów bazowych, które mogą spowodować awarię maszyny wirtualnej, a następnie dołączenie wszystkich telemetrii kondycji tych systemów zależnych razem filtrowane pod kątem zdarzeń, które wystąpiły blisko czasu przejścia maszyny wirtualnej. Intuicyjny i zaawansowany język zapytań usługi Azure Data Explorer ułatwia oferowanie udokumentowanych wzorców, takich jak łączenie okien czasowych w celu korelowania strumieni telemetrii czasowej. Na końcu tego procesu korelacji mamy zestaw danych reprezentujący przejścia przestojów maszyny wirtualnej z skorelowanym telemetrią platformy ze wszystkich systemów zależnych, które mogą powodować lub mogą zawierać informacje przydatne podczas określania, co doprowadziło do awarii maszyny wirtualnej.

Faza 3. Przypisanie głównej przyczyny

Następnym krokiem procesu jest przypisanie. Teraz, gdy zebraliśmy wszystkie odpowiednie dane razem w jednym zestawie danych, reguły przypisywania autorstwa są stosowane do interpretowania informacji i tłumaczenia ich na instrukcję głównej przyczyny dla klienta. Jeśli wrócisz do naszego oryginalnego przykładu awarii TOR, po analizie korelacji możemy mieć wiele interesujących informacji do zinterpretowania. Na przykład systemy monitorujące hosty platformy Azure mogą mieć dzienniki wskazujące, że w tym czasie utraciły łączność z hostami. Możemy również mieć sygnały związane z problemami z łącznością dysku wirtualnego i jawne sygnały z urządzenia TOR dotyczące awarii. Wszystkie te informacje są teraz skanowane, a wyraźny sygnał awarii TOR jest priorytetem dla innych sygnałów jako głównej przyczyny. Ten proces priorytetyzacji i reguły, które za nim stoją, są tworzone z ekspertami w dziedzinie i modyfikowane w miarę rozwoju platformy Azure. Mechanizmy wykrywania uczenia maszynowego i wykrywania anomalii znajdują się na tych przypisanych głównych przyczynach, aby pomóc zidentyfikować możliwości poprawy tych reguł klasyfikacji i wykryć zmiany wzorca w tempie tych niepowodzeń, które mogą wrócić do bezpiecznych potoków wdrażania.

Faza 4. Publikowanie głównej przyczyny

Ostatnim krokiem jest opublikowanie głównych przyczyn usługi Azure Resource Health, gdzie stają się widoczne dla klientów. Publikowanie odbywa się przez prostą aplikację usługi Azure Functions , która okresowo wykonuje zapytania o przetworzone dane głównej przyczyny w usłudze Azure Data Explorer i emituje wyniki do zaplecza kondycji zasobów. Ponieważ strumienie informacji mogą występować z różnymi opóźnieniami danych, elementy RCA mogą być od czasu do czasu aktualizowane w tym procesie w celu odzwierciedlenia lepszych źródeł informacji, co prowadzi do bardziej szczegółowej głównej przyczyny, że to, co zostało pierwotnie opublikowane.

Przyszłość

Identyfikowanie i komunikowanie głównej przyczyny problemów dla naszych klientów i partnerów to dopiero początek. Nasi klienci mogą wymagać podjęcia tych umów RCA i udostępnienia ich swoim klientom i współpracownikom. Chcemy opierać się na pracy tutaj, aby ułatwić identyfikowanie i śledzenie analizy głównej zasobów oraz łatwe udostępnianie ich. W tym celu pracujemy nad zmianami zaplecza w celu wygenerowania unikatowych identyfikatorów śledzenia poszczególnych zasobów i poszczególnych przestojów, które możemy udostępnić Tobie, dzięki czemu można łatwo dopasować przestoje do ich rcas. Pracujemy również nad nowymi funkcjami, aby ułatwić wysyłanie wiadomości e-mail do umów RCA i ostatecznie subskrybować rcas dla maszyn wirtualnych. Ta funkcja umożliwi zarejestrowanie się w usłudze RCA bezpośrednio w skrzynce odbiorczej po wystąpieniu zdarzenia niedostępności bez konieczności wykonywania dalszych działań.

Następne kroki

Aby dowiedzieć się więcej o oferowanych rozwiązaniach, przejdź do odpowiedniego artykułu dotyczącego rozwiązania:

Aby zapoznać się z ogólnym omówieniem monitorowania maszyn wirtualnych platformy Azure, zobacz Monitorowanie maszyn wirtualnych platformy Azure i dokumentacja monitorowania maszyn wirtualnych platformy Azure.

Udostępnij za pośrednictwem