Project Flash - Usare Azure Resource Health per monitorare la disponibilità delle Macchine Virtuali di Azure

2025-05-03

Integrità risorse di Azure è una soluzione offerta da Flash. Flash è il nome interno di un progetto dedicato alla creazione di un meccanismo resistente, affidabile e rapido per consentire ai clienti di monitorare l'integrità delle macchine virtuali.

Questo articolo illustra l'uso di Integrità risorse di Azure per monitorare la disponibilità delle macchine virtuali di Azure. Per una panoramica generale delle soluzioni Flash, vedere la panoramica di Flash.

Per la documentazione specifica per le altre soluzioni offerte da Flash, scegliere tra gli articoli seguenti:

Integrità delle risorse di Azure

Offre controlli di integrità immediati e descrittivi per le singole risorse tramite il portale. I clienti possono accedere rapidamente al pannello integrità delle risorse nel portale ed esaminare anche un record cronologico di 30 giorni di controlli di integrità, rendendolo uno strumento eccellente per la risoluzione dei problemi rapida e semplice. La funzionalità esistente di Integrità risorse di Azure consente di diagnosticare e ottenere supporto per i problemi del servizio che interessano le risorse di Azure. Segnala l'integrità corrente e precedente delle risorse, mostrando gli intervalli di tempo che ognuna delle risorse non è stata disponibile.

Tuttavia, sappiamo che i nostri clienti e partner sono interessati a comprendere quali sono le cause dei problemi tecnici sottostanti e a migliorare la ricezione delle comunicazioni su qualsiasi problema, per alimentare i processi di monitoraggio, per spiegare i problemi ad altri stakeholder e infine per informare le decisioni aziendali.

Cause principali dei problemi delle macchine virtuali in Azure Resource Health

Di recente è stato fornito un miglioramento all'esperienza di integrità delle risorse che migliorerà le informazioni condivise con i clienti sugli errori delle macchine virtuali e fornire ulteriore contesto sulla causa radice che ha causato il problema. Ora, oltre a ricevere una notifica rapida quando la disponibilità di una macchina virtuale è interessata, i clienti possono prevedere l'aggiunta di una causa radice in un secondo momento dopo che il sistema di analisi della causa radice automatizzata identifica il componente della piattaforma Azure che ha causato l'errore della macchina virtuale. Di seguito viene illustrato un esempio per vedere come funziona questo processo in pratica:

Al momento T1, un rack del server passa offline a causa di un problema di rete, causando la perdita della connettività delle macchine virtuali nel rack. I miglioramenti relativi all'affidabilità correlati all'architettura di rete verranno condivisi in un futuro post del blog Avanzamento dell'affidabilità—tenete d'occhio questo spazio!

Al momento T2, il monitoraggio interno di Azure riconosce che non è in grado di raggiungere le macchine virtuali nel rack e inizia a mitigare ridistribuendo le macchine virtuali interessate a un nuovo rack. Durante questo periodo, un'annotazione viene inviata allo stato di integrità delle risorse per informare i clienti che la VM è attualmente influenzata e non disponibile.

Al momento T3, i dati di telemetria della piattaforma dalla parte superiore del commutatore rack, il computer host e i sistemi di monitoraggio interni vengono correlati insieme nel motore RCA per derivare la causa radice dell'errore. Una volta calcolata, l'RCA viene quindi pubblicata nuovamente nell'integrità delle risorse insieme alle raccomandazioni pertinenti sulla resilienza dell'architettura che i clienti possono implementare per ridurre al minimo la probabilità di impatto in futuro.

Mentre la funzionalità di notifica dell'iniziale tempo di inattività esiste da diversi anni, la pubblicazione di un resoconto della causa principale è una nuova aggiunta. Verranno ora fornite informazioni dettagliate su come derivare queste cause radice.

Motore di analisi della causa radice

Esaminiamo più in dettaglio l'esempio precedente e esaminiamo i dettagli del funzionamento del motore RCA e della tecnologia sottostante. Al centro del motore RCA per le macchine virtuali è Azure Data Explorer (ADX), un servizio Big Data ottimizzato per l'analisi dei dati di telemetria dei log con volumi elevati. Esplora dati di Azure consente di analizzare facilmente terabyte di dati di telemetria dei log da dispositivi e servizi che comprendono la piattaforma Azure, di unirli insieme e di interpretare i flussi di informazioni correlati per derivare una causa radice per diversi scenari di errore. Questo finisce per essere un processo di progettazione dei dati a più passaggi:

Fase 1: Rilevamento dei tempi di inattività

La prima fase dell'analisi della causa radice consiste nel definire il trigger in cui viene eseguita l'analisi. Per le macchine virtuali, è necessario determinare le cause radice ogni volta che una macchina virtuale viene riavviata in modo imprevisto, quindi il trigger è una macchina virtuale che passa da uno stato attivo a uno stato inattivo. L'identificazione di queste transizioni dai dati di telemetria della piattaforma è semplice nella maggior parte degli scenari, ma più complicata per alcuni tipi di errore dell'infrastruttura in cui i dati di telemetria della piattaforma potrebbero andare persi a causa di un guasto del dispositivo o di una perdita di alimentazione. Per gestire queste classi di errori, sono necessarie altre tecniche, ad esempio il rilevamento della perdita di dati come possibile indicazione di una transizione di disponibilità della macchina virtuale. Esplora dati di Azure è un'ottima soluzione al momento dell'analisi delle serie e un'analisi più dettagliata delle tecniche relative a questo processo è disponibile in Microsoft Tech Community: calcolo dei tempi di inattività usando le funzioni Window e Time Series in Esplora dati di Azure.

Fase 2: Analisi della correlazione

Dopo aver definito un evento trigger (in questo caso, una macchina virtuale che passa a uno stato non integro) la fase successiva è l'analisi della correlazione. In questo passaggio viene usata la presenza dell'evento trigger per correlare i dati di telemetria dai punti nella piattaforma Azure, ad esempio:

Host di Azure: il pannello fisico che ospita le macchine virtuali.
TOR: il commutatore di rete top of rack.
Archiviazione di Azure: servizio che ospita dischi virtuali per macchine virtuali di Azure.

Ognuno di questi sistemi ha feed di telemetria personalizzati che devono essere analizzati e correlati all'evento trigger di tempo di inattività della macchina virtuale. Questo processo viene eseguito attraverso la comprensione del grafico delle dipendenze per una macchina virtuale e dei sistemi sottostanti che possono causare un errore di una macchina virtuale e quindi l'unione di tutti i dati di telemetria dell'integrità dei sistemi dipendenti, filtrati in base agli eventi che si sono verificati vicino al momento della transizione della macchina virtuale. Il linguaggio di query intuitivo e potente di Esplora dati di Azure consente di offrire modelli documentati come join di intervalli temporali per correlare i flussi di telemetria temporali insieme. Al termine di questo processo di correlazione, è disponibile un set di dati che rappresenta le transizioni di tempo di inattività delle macchine virtuali con dati di telemetria della piattaforma correlati da tutti i sistemi dipendenti che potrebbero causare o che potrebbero avere informazioni utili per determinare cosa ha causato l'errore della macchina virtuale.

Fase 3: Attribuzione della causa radice

Il passaggio successivo del processo è l'attribuzione. Ora che tutti i dati pertinenti sono stati raccolti insieme in un singolo set di dati, le regole di attribuzione vengono applicate per interpretare le informazioni e convertirli in un'istruzione della causa radice rivolta al cliente. Se si torna all'esempio originale di un errore TOR, dopo l'analisi della correlazione potrebbero essere presenti molte informazioni interessanti da interpretare. Ad esempio, i sistemi che monitorano gli host di Azure potrebbero avere log che indicano la perdita di connettività agli host durante questo periodo. Potrebbero anche essere presenti segnali correlati a problemi di connettività del disco virtuale e segnali espliciti provenienti dal dispositivo TOR in merito all'errore. Tutte queste informazioni vengono ora analizzate e il segnale di errore TOR esplicito è prioritario rispetto agli altri segnali come causa radice. Questo processo di definizione delle priorità e le regole sottostanti vengono costruiti con esperti di dominio e modificati man mano che la piattaforma Azure evolve. I meccanismi di machine learning e rilevamento delle anomalie si basano su queste cause profonde attribuite, per aiutare a identificare le opportunità di migliorare le regole di classificazione e rilevare cambiamenti nei modelli del tasso di questi fallimenti da reinserire nelle pipeline di distribuzione sicure.

Fase 4: Pubblicazione RCA

L'ultimo passaggio consiste nel pubblicare le cause profonde in Integrità risorse di Azure, dove diventano visibili ai clienti. La pubblicazione viene eseguita da una semplice applicazione di Funzioni di Azure, che esegue periodicamente query sui dati sulla causa principale elaborati in Esplora dati di Azure e emette i risultati nel back-end di integrità delle risorse. Poiché i flussi di informazioni possono venire in arrivo con vari ritardi nei dati, le RCA possono occasionalmente essere aggiornate in questo processo per riflettere fonti migliori di informazioni che hanno portato a una causa radice più specifica che ciò che è stato originariamente pubblicato.

Da qui in avanti

L'identificazione e la comunicazione della causa principale di eventuali problemi con i clienti e i partner è solo l'inizio. I nostri clienti potrebbero dover prendere queste RCA e condividerle con i loro clienti e colleghi. Vogliamo sviluppare il lavoro qui per semplificare l'identificazione e il monitoraggio delle RCA delle risorse e condividerli facilmente. A tale scopo, stiamo lavorando alle modifiche back-end per generare ID univoci per risorsa e rilevamento per tempo di inattività che possiamo esporre all'utente, in modo da poter associare facilmente i tempi di inattività alle relative RCA. Stiamo lavorando anche su nuove funzionalità per facilitare l'invio tramite email degli RCA e, infine, sottoscrivere gli RCA per le tue macchine virtuali. Questa funzionalità consentirà di iscriversi direttamente agli RCA nella tua casella di posta elettronica dopo un evento di indisponibilità, senza che sia necessaria alcuna ulteriore azione da parte tua.

Passaggi successivi

Per altre informazioni sulle soluzioni offerte, passare all'articolo della soluzione corrispondente:

Per una panoramica generale su come monitorare le macchine virtuali di Azure, vedere Monitorare le macchine virtuali di Azure e le informazioni di riferimento su Monitoraggio delle macchine virtuali di Azure.