Project Flash : usare Azure Integrità risorse per monitorare la disponibilità delle macchine virtuali di Azure

Articolo
02/21/2024

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

Questo articolo illustra l'uso di Azure Integrità risorse 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à 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à di Integrità risorse di Azure esistente 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 cause sono i problemi tecnici sottostanti e a migliorare come possono ricevere comunicazioni su qualsiasi problema, per alimentare i processi di monitoraggio, per spiegare gli soccorsi ad altri stakeholder e infine per informare le decisioni aziendali.

Cause radice dei problemi delle macchine virtuali in Azure Integrità risorse

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 recenti miglioramenti dell'affidabilità correlati all'architettura di rete verranno condivisi in un post di blog Di avanzamento dell'affidabilità: guardare 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 all'integrità delle risorse per informare i clienti che la macchina virtuale è attualmente interessata 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 del tempo di inattività iniziale è di diversi anni, la pubblicazione di un'istruzione della causa radice è 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 Esplora dati (ADX), un servizio Big Data ottimizzato per l'analisi dei dati di telemetria dei log con volumi elevati. Azure Esplora dati consente di analizzare facilmente terabyte di dati di telemetria dei log da dispositivi e servizi che comprendono la piattaforma Azure, aggiungerli insieme e 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 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. Azure Esplora dati eccelle in questo momento dell'analisi delle serie e un'analisi più dettagliata di questo processo è disponibile in Microsoft Tech Community: Calcolo dei tempi di inattività usando le funzioni Window e Time Series in Azure Esplora dati.

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: il servizio che ospita dischi virtuali per Azure Macchine virtuali.

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 Azure Esplora dati 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 anomalie si trovano sopra queste cause radice con attributi, per identificare le opportunità di migliorare queste regole di classificazione e rilevare le modifiche dei modelli nella frequenza di questi errori da inserire nelle pipeline di distribuzione sicure.

Fase 4: pubblicazione RCA

L'ultimo passaggio consiste nel pubblicare le cause radice in Azure Integrità risorse, in cui diventano visibili ai clienti. La pubblicazione viene eseguita da una semplice applicazione Funzioni di Azure, che esegue periodicamente query sui dati della causa radice elaborata in Azure Esplora dati e genera 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.

Operazioni successive

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 clienti e i 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 sulle nuove funzionalità per semplificare la posta elettronica degli RCA e infine sottoscrivere rca per le macchine virtuali. Questa funzionalità consentirà di iscriversi direttamente agli RCA nella posta in arrivo dopo un evento di indisponibilità senza ulteriori azioni necessarie.

Passaggi successivi

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

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

Condividi tramite