Project Flash - Azure Resource Health gebruiken om de beschikbaarheid van virtuele Azure-machines te bewaken

Artikel
10/15/2024

Azure Resource Health is één oplossing die wordt aangeboden door Flash. Flash is de interne naam voor een project dat is toegewezen aan het bouwen van een robuust, betrouwbaar en snel mechanisme voor klanten om de status van virtuele machines (VM's) te bewaken.

In dit artikel wordt het gebruik van Azure Resource Health beschreven om de beschikbaarheid van virtuele Azure-machines te bewaken. Zie het Flash-overzicht voor een algemeen overzicht van Flash-oplossingen.

Voor documentatie die specifiek is voor de andere oplossingen die flash biedt, kiest u uit de volgende artikelen:

Azure Resource Health

Het biedt directe en gebruiksvriendelijke statuscontroles voor afzonderlijke resources via de portal. Klanten hebben snel toegang tot de blade resourcestatus in de portal en bekijken ook een historisch overzicht van statuscontroles van 30 dagen, waardoor het een uitstekend hulpprogramma is voor snelle en eenvoudige probleemoplossing. De bestaande Azure Resource Health-functie helpt u bij het vaststellen en krijgen van ondersteuning voor serviceproblemen die van invloed zijn op uw Azure-resources. Het rapporteert over de huidige en eerdere status van uw resources, met tijdsbereiken die elk van uw resources niet beschikbaar zijn.

Maar we weten dat onze klanten en partners geïnteresseerd zijn in inzicht in wat onderliggende technische problemen veroorzaakt en hoe ze communicatie over eventuele problemen kunnen ontvangen, om in te voeren op bewakingsprocessen, om problemen met andere belanghebbenden uit te leggen en uiteindelijk zakelijke beslissingen te nemen.

Hoofdoorzaken voor VM-problemen in Azure Resource Health

We hebben onlangs een verbetering verzonden naar de resourcestatuservaring waarmee de informatie die we delen met klanten over VM-fouten wordt verbeterd en verdere context biedt over de hoofdoorzaak die tot het probleem heeft geleid. Naast een snelle melding wanneer de beschikbaarheid van een VIRTUELE machine wordt beïnvloed, kunnen klanten verwachten dat er op een later moment een hoofdoorzaak wordt toegevoegd zodra ons geautomatiseerde RCA-systeem (Root Cause Analysis) het mislukte Azure-platformonderdeel identificeert dat heeft geleid tot de VM-fout. Laten we een voorbeeld bekijken om te zien hoe dit werkt in de praktijk:

Op het moment T1 gaat een serverrek offline vanwege een netwerkprobleem, waardoor VM's in het rek geen verbinding meer hebben. Recente verbeteringen in de betrouwbaarheid met betrekking tot de netwerkarchitectuur worden gedeeld in een toekomstig blogbericht over geavanceerde betrouwbaarheid . Bekijk deze ruimte!

Op het moment T2 herkent de interne bewaking van Azure dat het geen VM's in het rek kan bereiken en begint te beperken door de betrokken VM's opnieuw te implementeren in een nieuw rek. Gedurende deze tijd wordt een aantekening verzonden naar de resourcestatus die klanten informeert dat hun VM momenteel wordt beïnvloed en niet beschikbaar is.

Op het moment T3 worden platformtelemetrie van de bovenkant van de rackswitch, de hostcomputer en interne bewakingssystemen aan elkaar gecorreleerd in onze RCA-engine om de hoofdoorzaak van de fout af te leiden. Zodra de RCA is berekend, wordt de RCA weer gepubliceerd in de resourcestatus, samen met relevante aanbevelingen voor architectuurtolerantie die klanten kunnen implementeren om de kans op impact in de toekomst te minimaliseren.

Hoewel de initiële downtimemeldingsfunctionaliteit meerdere jaren oud is, is het publiceren van een hoofdoorzaakinstructie een nieuwe toevoeging. Laten we nu ingaan op de details van hoe we deze hoofdoorzaken afleiden.

Hoofdoorzaakanalyse-engine

Laten we het vorige voorbeeld nader bekijken en de details bekijken van de werking van de RCA-engine en de technologie erachter. De kern van onze RCA-engine voor VM's is Azure Data Explorer (ADX), een big data-service die is geoptimaliseerd voor telemetrieanalyses voor grote volumes. Met Azure Data Explorer kunt u eenvoudig terabytes aan logboektelemetrie parseren van apparaten en services die deel uitmaken van het Azure-platform, deze samenvoegen en de gecorreleerde informatiestromen interpreteren om een hoofdoorzaak af te leiden voor verschillende foutscenario's. Dit is uiteindelijk een multistep data engineering-proces:

Fase 1: Downtime detecteren

De eerste fase in de hoofdoorzaakanalyse is het definiëren van de trigger waaronder de analyse wordt uitgevoerd. Voor virtuele machines willen we de hoofdoorzaken bepalen wanneer een VIRTUELE machine onverwacht opnieuw wordt opgestart, dus de trigger is een VM die van een status omhoog naar een downstatus overgaat. Het identificeren van deze overgangen van platformtelemetrie is in de meeste scenario's eenvoudig, maar ingewikkelder om bepaalde soorten infrastructuurfouten waarbij platformtelemetrie verloren kan gaan vanwege apparaatstoringen of stroomverlies. Voor het afhandelen van deze klassen van fouten zijn andere technieken vereist, zoals het bijhouden van gegevensverlies als mogelijke indicatie van een vm-beschikbaarheidsovergang. Azure Data Explorer excelleert op dit moment van reeksanalyse en een gedetailleerdere kijk op technieken rond dit proces vindt u in de Microsoft Tech Community: Downtime berekenen met behulp van Vensterfuncties en Time Series-functies in Azure Data Explorer.

Fase 2: Correlatieanalyse

Zodra een triggergebeurtenis is gedefinieerd (in dit geval is een VM die overschakelt naar een beschadigde status) de volgende fase correlatieanalyse. In deze stap gebruiken we de aanwezigheid van de trigger-gebeurtenis om telemetrie te correleren vanaf punten in het Azure-platform, zoals:

Azure-host: de fysieke blade waarop VM's worden gehost.
TOR: de bovenkant van de racknetwerkswitch.
Azure Storage: de service die als host fungeert voor virtuele schijven van Azure.

Elk van deze systemen heeft zijn eigen telemetriefeeds die moeten worden geparseerd en gecorreleerd met de triggergebeurtenis voor vm-downtime. Dit proces wordt uitgevoerd door inzicht te krijgen in de afhankelijkheidsgrafiek voor een VIRTUELE machine en de onderliggende systemen die ertoe kunnen leiden dat een VIRTUELE machine mislukt en vervolgens alle statustelemetriegegevens van afhankelijke systemen samenvoegt, gefilterd op gebeurtenissen die zich dicht bij de tijd van de VM-overgang hebben voorgedaan. De intuïtieve en krachtige querytaal van Azure Data Explorer helpt door gedocumenteerde patronen zoals tijdvensterdeelname aan te bieden voor het correleren van tijdelijke telemetriestromen. Aan het einde van dit correlatieproces hebben we een gegevensset die staat voor overgangen van VM-downtime met gecorreleerde platformtelemetrie van alle afhankelijke systemen die mogelijk informatie kunnen veroorzaken of kunnen hebben om te bepalen wat tot de VM-fout heeft geleid.

Fase 3: Hoofdoorzaakvermelding

De volgende stap in het proces is toeschrijving. Nu we alle relevante gegevens in één gegevensset hebben verzameld, worden toeschrijvingsregels toegepast om de informatie te interpreteren en te vertalen in een klantgerichte hoofdoorzaakinstructie. Als u teruggaat naar ons oorspronkelijke voorbeeld van een TOR-fout, hebben we na onze correlatieanalyse mogelijk veel interessante stukjes informatie om te interpreteren. Systemen die de Azure-hosts bewaken, kunnen bijvoorbeeld logboeken bevatten die aangeven dat ze de connectiviteit met de hosts hebben verbroken gedurende deze tijd. Mogelijk hebben we ook signalen met betrekking tot connectiviteitsproblemen met virtuele schijven en expliciete signalen van het TOR-apparaat over de fout. Al deze stukjes informatie worden nu gescand en het expliciete TOR-foutsignaal wordt prioriteit gegeven aan de andere signalen als de hoofdoorzaak. Dit prioriteitsproces en de regels erachter worden samengesteld met domeinexperts en gewijzigd naarmate het Azure-platform zich ontwikkelt. Machine learning- en anomaliedetectiemechanismen bevinden zich boven op deze toegeschreven hoofdoorzaken, om mogelijkheden te identificeren om deze classificatieregels te verbeteren en patroonwijzigingen te detecteren in de snelheid van deze fouten om terug te gaan naar veilige implementatiepijplijnen.

Fase 4: RCA-publicatie

De laatste stap is het publiceren van hoofdoorzaken in Azure Resource Health, waar ze zichtbaar worden voor klanten. Publiceren wordt uitgevoerd door een eenvoudige Azure Functions-toepassing , die periodiek query's op de verwerkte hoofdoorzaakgegevens in Azure Data Explorer opvraagt en de resultaten verzendt naar de back-end van de resourcestatus. Omdat informatiestromen kunnen optreden met verschillende gegevensvertragingen, kunnen RCA's soms in dit proces worden bijgewerkt om betere bronnen van informatie weer te geven die tot een specifiekere hoofdoorzaak hebben geleid die oorspronkelijk is gepubliceerd.

Verder

Het identificeren en communiceren van de hoofdoorzaak van eventuele problemen aan onze klanten en partners is nog maar het begin. Onze klanten moeten deze RCA's mogelijk meenemen en delen met hun klanten en collega's. We willen voortbouwen op het werk hier om het gemakkelijker te maken om resource-CBA's te identificeren en bij te houden, en deze eenvoudig te delen. Hiervoor werken we aan back-endwijzigingen om unieke tracerings-id's per resource en tracerings-id's per resource te genereren die we aan u kunnen blootstellen, zodat u eenvoudig downtime kunt koppelen aan hun RCA's. We werken ook aan nieuwe functies om het eenvoudiger te maken om RCA's te e-mailen en zich uiteindelijk te abonneren op RCA's voor uw VM's. Met deze functie kunt u zich rechtstreeks registreren voor RCA's in uw Postvak IN na een gebeurtenis zonder verdere actie die u nodig hebt.

Volgende stappen

Ga verder met het bijbehorende oplossingsartikel voor meer informatie over de aangeboden oplossingen:

Voor een algemeen overzicht van het bewaken van virtuele Azure-machines raadpleegt u Virtuele Azure-machines bewaken en de naslaginformatie over virtuele Azure-machines bewaken.

Delen via