Project Flash – Använda Azure Resource Health för att övervaka tillgängligheten för virtuella Azure-datorer

Artikel
08/24/2024

Azure Resource Health är en lösning som erbjuds av Flash. Flash är det interna namnet på ett projekt som är avsett för att skapa en robust, tillförlitlig och snabb mekanism för kunder att övervaka den virtuella datorns hälsotillstånd.

Den här artikeln beskriver användningen av Azure Resource Health för att övervaka tillgängligheten för virtuella Azure-datorer. En allmän översikt över Flash-lösningar finns i Översikt över Flash.

För dokumentation som är specifik för de andra lösningarna som erbjuds av Flash kan du välja mellan följande artiklar:

Azure Resource Health

Den erbjuder omedelbara och användarvänliga hälsokontroller för enskilda resurser via portalen. Kunder kan snabbt komma åt resurshälsobladet på portalen och även granska en 30-dagars historisk post med hälsokontroller, vilket gör det till ett utmärkt verktyg för snabb och enkel felsökning. Den befintliga Azure Resource Health-funktionen hjälper dig att diagnostisera och få support för tjänstproblem som påverkar dina Azure-resurser. Den rapporterar om resursernas aktuella och tidigare hälsotillstånd och visar alla tidsintervall som var och en av dina resurser har varit otillgängliga.

Men vi vet att våra kunder och partner är intresserade av att förstå vad som orsakar underliggande tekniska problem och att förbättra hur de kan ta emot kommunikation om eventuella problem – att bidra till övervakningsprocesser, att förklara hicka för andra intressenter och slutligen att informera affärsbeslut.

Rotorsaker till vm-problem i Azure Resource Health

Vi levererade nyligen en förbättring av resurshälsoupplevelsen som förbättrar den information vi delar med kunder om vm-fel och ger ytterligare kontext om den rotorsak som ledde till problemet. Förutom att få ett snabbt meddelande när en virtuell dators tillgänglighet påverkas kan kunderna förvänta sig att en rotorsak läggs till vid ett senare tillfälle när vårt automatiserade RCA-system (Root Cause Analysis) identifierar den misslyckade Azure-plattformskomponenten som ledde till vm-felet. Nu ska vi gå igenom ett exempel för att se hur detta fungerar i praktiken:

Vid tidpunkten för T1 går ett serverrack offline på grund av ett nätverksproblem, vilket gör att virtuella datorer i racket förlorar anslutningen. De senaste tillförlitlighetsförbättringarna som rör nätverksarkitektur delas i ett framtida blogginlägg om avancerad tillförlitlighet – titta på det här utrymmet!

Vid tidpunkten för T2 ser Azures interna övervakning att den inte kan nå virtuella datorer i racket och börjar minimera genom att distribuera om de berörda virtuella datorerna till ett nytt rack. Under den här tiden skickas en kommentar till resurshälsa som meddelar kunderna att deras virtuella dator för närvarande påverkas och inte är tillgänglig.

Vid tidpunkten för T3 korreleras plattformstelemetri från toppen av rackbrytaren, värddatorn och interna övervakningssystem tillsammans i vår RCA-motor för att härleda rotorsaken till felet. När rca har beräknats publiceras den sedan tillbaka till resurshälsan tillsammans med relevanta rekommendationer för arkitekturåterhämtning som kunderna kan implementera för att minimera sannolikheten för påverkan i framtiden.

Även om den inledande funktionen för stilleståndstidsmeddelanden är flera år gammal är publiceringen av en rotorsaksinstruktion ett nytt tillägg. Nu ska vi titta närmare på hur vi härleder dessa rotorsaker.

Motorn för rotorsaksanalys

Låt oss ta en närmare titt på föregående exempel och gå igenom detaljerna om hur RCA-motorn fungerar och tekniken bakom den. Kärnan i vår RCA-motor för virtuella datorer är Azure Data Explorer (ADX), en stordatatjänst som är optimerad för telemetrianalys för högvolymloggar. Med Azure Data Explorer kan du enkelt parsa terabyte loggtelemetri från enheter och tjänster som utgör Azure-plattformen, koppla ihop dem och tolka korrelerade informationsströmmar för att härleda en rotorsak till olika felscenarier. Det här blir en datateknikprocess med flera steg:

Fas 1: Identifiera stilleståndstid

Den första fasen i rotorsaksanalysen är att definiera utlösaren under vilken analysen körs. För virtuella datorer vill vi fastställa rotorsaker när en virtuell dator oväntat startas om, så utlösaren är en virtuell dator som övergår från ett upp-tillstånd till ett nedtillstånd. Att identifiera dessa övergångar från plattformstelemetri är enkelt i de flesta scenarier, men mer komplicerat kring vissa typer av infrastrukturfel där plattformstelemetri kan gå förlorad på grund av enhetsfel eller strömavbrott. För att hantera dessa felklasser krävs andra tekniker, till exempel spårning av dataförlust som en möjlig indikation på en övergång till vm-tillgänglighet. Azure Data Explorer utmärker sig vid den här tiden av serieanalys, och en mer detaljerad titt på tekniker kring den här processen finns i Microsoft Tech Community: Beräkna stilleståndstid med hjälp av fönsterfunktioner och tidsseriefunktioner i Azure Data Explorer.

Fas 2: Korrelationsanalys

När en utlösarhändelse har definierats (i det här fallet en virtuell dator som övergår till ett feltillstånd) är nästa fas korrelationsanalys. I det här steget använder vi förekomsten av utlösarhändelsen för att korrelera telemetri från punkter på Azure-plattformen, till exempel:

Azure-värd: det fysiska bladet som är värd för virtuella datorer.
TOR: toppen av racknätverksväxeln.
Azure Storage: den tjänst som är värd för virtuella diskar för virtuella Azure-datorer.

Vart och ett av dessa system har egna telemetriflöden som måste parsas och korreleras med utlösarhändelsen för vm-stilleståndstid. Den här processen görs genom att förstå beroendediagrammet för en virtuell dator och de underliggande system som kan orsaka att en virtuell dator misslyckas och sedan koppla samman alla dessa beroende systems hälsotelemetri, filtrerade efter händelser som inträffade nära tidpunkten för övergången till den virtuella datorn. Azure Data Explorers intuitiva och kraftfulla frågespråk hjälper till genom att erbjuda dokumenterade mönster som tidsfönsterkoppling för att korrelera tidstelemetriströmmar tillsammans. I slutet av den här korrelationsprocessen har vi en datauppsättning som representerar vm-avbrottstidsövergångar med korrelerad plattformstelemetri från alla beroende system som kan orsaka eller kan ha information som är användbar för att avgöra vad som ledde till vm-felet.

Fas 3: Rotorsaks-attribution

Nästa steg i processen är attribution. Nu när vi har samlat in alla relevanta data i en enda datauppsättning tillämpas attributionsregler för att tolka informationen och översätta den till en kundriktad rotorsaksinstruktion. Om du går tillbaka till vårt ursprungliga exempel på ett TOR-fel kan vi efter korrelationsanalysen ha många intressanta uppgifter att tolka. System som övervakar Azure-värdarna kan till exempel ha loggar som anger att de förlorade anslutningen till värdarna under den här tiden. Vi kan också ha signaler som rör anslutningsproblem med virtuella diskar och explicita signaler från TOR-enheten om felet. Alla dessa uppgifter genomsöks nu och den explicita TOR-felsignalen prioriteras framför de andra signalerna som rotorsak. Den här prioriteringsprocessen, och reglerna bakom den, konstrueras med domänexperter och ändras när Azure-plattformen utvecklas. Mekanismer för maskininlärning och avvikelseidentifiering ligger ovanpå dessa tillskrivna rotorsaker för att hjälpa till att identifiera möjligheter att förbättra dessa klassificeringsregler och identifiera mönsterändringar i hastigheten för dessa fel för att mata tillbaka till säkra distributionspipelines.

Fas 4: RCA-publicering

Det sista steget är att publicera rotorsaker till Azure Resource Health, där de blir synliga för kunderna. Publiceringen görs av ett enkelt Azure Functions-program som regelbundet frågar efter bearbetade rotorsaksdata i Azure Data Explorer och genererar resultatet till resurshälsoserverdelen. Eftersom informationsströmmar kan komma in med olika datafördröjningar kan rcas ibland uppdateras i den här processen för att återspegla bättre informationskällor som har anlänt, vilket leder till en mer specifik rotorsak till att det som ursprungligen publicerades.

Framöver

Att identifiera och kommunicera grundorsaken till eventuella problem med våra kunder och partner är bara början. Våra kunder kan behöva ta dessa RCA:er och dela dem med sina kunder och medarbetare. Vi vill bygga vidare på arbetet här för att göra det enklare att identifiera och spåra resurs-RCA:er och enkelt dela ut dem. För att åstadkomma detta arbetar vi med serverdelsändringar för att generera unika spårnings-ID:n per resurs och per stilleståndstid som vi kan exponera för dig, så att du enkelt kan matcha stilleståndstider till deras RCA:er. Vi arbetar också med nya funktioner för att göra det enklare att skicka e-post till RCA:er och så småningom prenumerera på RCA:er för dina virtuella datorer. Den här funktionen gör det möjligt att registrera sig för RCA:er direkt i inkorgen efter en otillgänglighetshändelse utan ytterligare åtgärder från din sida.

Nästa steg

Om du vill veta mer om de lösningar som erbjuds går du vidare till motsvarande lösningsartikel:

En allmän översikt över hur du övervakar virtuella Azure-datorer finns i Övervaka virtuella Azure-datorer och referensen Övervaka virtuella Azure-datorer.

Dela via