Strategie di architettura per il monitoraggio dell'affidabilità del carico di lavoro

Si applica alla seguente raccomandazione della check-list di Affidabilità del framework Azure Well-Architected:

Il monitoraggio dell'affidabilità è la pratica di misurare quanto un sistema soddisfi i requisiti aziendali nel tempo, in relazione alla resilienza e alla recuperabilità. Un sistema di monitoraggio ben progettato offre una visualizzazione in tempo reale e le tendenze del comportamento del sistema stabilendo visibilità tra livelli di piattaforma, infrastruttura e carico di lavoro.

Correlando questi segnali tra componenti e nel tempo, il monitoraggio consente un'analisi rapida e sicura degli eventi imprevisti e delle interruzioni. Creare un approccio strutturato affinché le intuizioni siano significative, gli avvisi guidino le giuste azioni e le esperienze si reintegrino nell'architettura e nelle operazioni.

Le strategie chiave di questo articolo si basano sulla pratica operativa di base dell'osservabilità, descritta in OE:07 Strategie di architettura per la progettazione di un sistema di monitoraggio. Le indicazioni sull'implementazione della procedura di monitoraggio sono disponibili nella Guida alla progettazione del monitoraggio. È consigliabile prima esaminare tali risorse.

Definizioni

Monitorare la funzionalità del carico di lavoro

Monitorare il risultato effettivo del sistema. Iniziare verificando se i flussi di lavoro critici vengono completati correttamente e producono risultati validi. Un sistema può apparire integro pur producendo output non corretti o incompleti, quindi l'esecuzione da sola non è sufficiente.

Ad esempio, se un carico di lavoro genera report ogni sei ore, il monitoraggio deve confermare due elementi: che il processo è stato eseguito come pianificato e che ha generato un risultato valido, ad esempio un report non vuoto con contenuto e dimensioni previsti. Questo tipo di convalida consente di garantire che il sistema non solo sia in esecuzione, ma anche fornire funzionalità progettate per.

Monitorare l'esperienza utente

Monitorare l'affidabilità dal punto di vista aziendale e dell'utente. Nell'ambito dell'analisi della modalità di errore (FMA), è necessario aver già identificato i flussi utente chiave. Per ogni flusso, tenere traccia del modo in cui gli errori in qualsiasi componente o dipendenza influiscono sull'esperienza utente e sul risultato previsto. Ad esempio, in un flusso di pagamento tramite e-commerce, un'interruzione del servizio o un sovraccarico nei sistemi di pagamento o inventario può impedire ai clienti di completare gli acquisti.

L'affidabilità riflette anche la qualità del servizio. In un flusso di checkout, gli utenti devono essere in grado di completare gli acquisti end-to-end senza interruzioni. Usare metriche di latenza basate su percentile, ad esempio p50, p95 e p99 per comprendere l'esperienza utente reale, con particolare attenzione alla latenza della coda in cui i problemi di prestazioni spesso si presentano per primi.

Tenere traccia degli obiettivi di disponibilità

Tenere traccia del modo in cui il sistema soddisfa le destinazioni definite per la disponibilità, la velocità effettiva e i tempi di risposta. Questi obiettivi vengono spesso formalizzati come contratti di servizio e obiettivi del livello di servizio (SLO) e riflettono le aspettative stabilite con gli utenti. Il monitoraggio su di essi mantiene l'affidabilità allineata ai risultati aziendali reali. Per altre informazioni, vedere Obiettivi di affidabilità e contratti di servizio.

Concentrarsi sugli indicatori chiave che contribuiscono a tali obiettivi e monitorarli nel tempo. Quando si verifica una deviazione, è necessario approfondire nei componenti o nei sottosistemi specifici coinvolti. Acquisire tutti i segnali rilevanti, inclusi i problemi mascherati dalla ridondanza o dal failover, in modo da comprendere cosa è accaduto e impedirne il ripetersi.

Combinare la consapevolezza in tempo reale con il contesto storico. I segnali in tempo reale consentono di rispondere rapidamente quando gli obiettivi sono a rischio, mentre le tendenze nel tempo rivelano modelli e problemi ricorrenti. La classificazione delle cause dei mancati riscontri di destinazione e l'aggregazione di queste metriche supportano anche la creazione di report chiari del contratto di servizio e consentono di guidare i miglioramenti continui.

Monitorare i contratti di servizio principali forniti dai fornitori e dai servizi della piattaforma (da Microsoft e altri). È necessario effettuare le operazioni seguenti:

• Tenere traccia degli indicatori di potenziali violazioni del contratto di servizio in tempo reale
• Acquisire e conservare le prove necessarie per supportare un'attestazione del contratto di servizio in caso di violazione

Tenere traccia degli obiettivi di recuperabilità

Tenere traccia della recuperabilità trattando ogni test e un evento imprevisto reale come evento misurabile. Usare i dati di monitoraggio per verificare che il sistema e il team possano soddisfare gli obiettivi di ripristino definiti in condizioni reali.

Misurare i segnali chiave, ad esempio il tempo necessario per rilevare, rispondere e recuperare (RTO), insieme all'esposizione alla perdita di dati (RPO). Includere indicatori come prontezza e capacità del failover, tasso di riuscita del failover e tempo di esecuzione del failover, successo del backup e del ripristino, ritardo della replica, e grado di intervento manuale richiesto.

Queste metriche evidenziano anche lacune operative, ad esempio procedure poco chiare, ritardi delle decisioni o documentazione difficile da accedere, che possono influire sulle prestazioni di ripristino. Usare queste informazioni dettagliate per rafforzare sia la progettazione del sistema che le procedure di risposta agli eventi imprevisti.

Rendere gli avvisi attuabili con un modello di salute

Progettare avvisi in modo che puntino chiaramente a qualcosa su cui vale la pena intervenire e basarli in un modello di salute che rappresenta il sistema usando stati semplici come sano, degradato e non sano.

Strutturare il modello di salute in modo gerarchico, dai singoli componenti fino al sistema completo, in modo da poter tracciare rapidamente i problemi alla loro origine. Definire le soglie usando gli obiettivi del livello di servizio e combinare segnali come metriche, log, tracce e controlli sintetici per creare un quadro affidabile dell'integrità del sistema. In questo modo gli operatori hanno una visione chiara di ciò che funziona, ciò che non funziona e su dove intervenire senza analizzare i dati grezzi. Per ulteriori informazioni, consultare la guida alla progettazione sulla modellazione della salute.

Ottimizzare gli avvisi per le condizioni reali concentrandosi sull'esperienza end-to-end e sulle transazioni critiche, in modo che riflettano l'impatto effettivo dell'utente. Ridurre il rumore tenendo conto delle fluttuazioni transitorie e innescando cambiamenti significativi dello stato di salute anziché scatti isolati o picchi. Combinare avvisi in tempo reale con informazioni dettagliate sulle tendenze per rilevare problemi immediati e ridurre gradualmente le prestazioni, aiutando i team a rispondere rapidamente e rimanere concentrati.

Rischio: la modellazione della salute richiede la raccolta di segnali significativi attraverso il sistema. Basarsi solo su metriche semplici come CPU o memoria può perdere ciò che conta effettivamente. Includere i dati dell'esperienza utente e i controlli sintetici per ottenere una visualizzazione completa. La definizione di "sano" richiede un allineamento, e soglie mal regolate possono creare rumore e ridurre l'efficacia.

Monitorare tutti i livelli del sistema

Monitorare ogni livello del sistema, dell'applicazione, dei dati/archiviazione e della rete per mantenere una visualizzazione completa dei segnali di affidabilità.

A livello di applicazione, tenere traccia dell'esito positivo, dell'errore e della latenza usando log, metriche e probe di integrità. Usare gli ID di correlazione per seguire le richieste tra i servizi e semplificare la risoluzione dei problemi. Raccogliere i log in modo asincrono in modo da non influire sulle prestazioni delle richieste e mantenere separati i log di diagnostica e di controllo per maggiore chiarezza. Aggiungere transazioni sintetiche e probe di endpoint per confermare l'esperienza effettiva dei clienti.

Compromesso. La scelta tra la registrazione asincrona e sincrona comporta un equilibrio tra prestazioni e affidabilità dei dati di telemetria.

• La registrazione asincrona dei log tiene il log fuori dal percorso critico, riducendo la latenza e migliorando le prestazioni del sistema. Tuttavia, introduce un rischio di perdita di dati di telemetria, soprattutto se si verifica un errore prima che i log vengano scaricati o salvati in modo permanente.

• La registrazione sincrona garantisce che i log vengano scritti prima che l'elaborazione continui, migliorando la durabilità e la verificabilità dei dati. Il compromesso è maggiore latenza e un accoppiamento più stretto tra le prestazioni dell'applicazione e il sistema di registrazione.

Nella maggior parte degli scenari, la registrazione asincrona è l'approccio preferito a causa dell'impatto minimo sulle prestazioni. Tuttavia, in ambienti fortemente regolamentati o sensibili al controllo, la registrazione sincrona può essere necessaria per garantire che gli eventi critici vengano acquisiti in modo affidabile.

A livello di dati e archiviazione, concentrarsi sulla disponibilità, sulla velocità di riuscita della scrittura, sulla latenza delle query, sui timeout, sui blocchi e sulla pressione delle risorse. Esaminare le tendenze nel corso del tempo per identificare i colli di bottiglia crescenti e distinguere i problemi di breve durata dal degrado prolungato.

A livello di rete, monitorare la connettività, latenza, perdita di pacchetti, larghezza di banda e modelli di traffico. Combinare log di flusso, controlli degli endpoint e test sintetici per individuare problemi di routing, anomalie o comportamenti correlati alla sicurezza. Connettere questi segnali ai dati dell'applicazione e della piattaforma per capire dove hanno origine i problemi.

I log operativi consentono di diagnosticare i problemi, tenere traccia delle prestazioni e comprendere il comportamento del sistema. Non sono progettati per fungere da fonte di verità per eventi aziendali, controllo o report normativi, che in genere richiedono una tracciabilità più forte.

Cosa monitorare in dettaglio per ogni livello è illustrato nella Guida alla progettazione del monitoraggio.

Definire e monitorare la capacità di stampa

Definire limiti di capacità chiari per ogni unità di distribuzione, o modulo, e monitorarli attentamente. Ogni stamp opera entro un limite massimo, indipendentemente dal fatto che si tratti di limiti massimi di utenti simultanei, velocità effettiva o soglie di utilizzo delle risorse. Pertanto, rendere espliciti questi limiti fornirà una baseline affidabile per il processo decisionale.

Questa visibilità consente di identificare quando un timbro si avvicina alla saturazione, ben prima che influisca sull'affidabilità. Supporta anche decisioni tempestive di espansione, come l'aggiunta di nuove istanze o la ridistribuzione del carico, e conferma che il traffico fluisce secondo il design.

La definizione di questi limiti non è sempre semplice. La capacità può essere difficile da misurare, soprattutto quando dipende da più servizi sottostanti con caratteristiche di ridimensionamento diverse. È consigliabile usare le linee guida per la piattaforma, ad esempio quote e limiti di Microsoft Azure, come punto di partenza. In pratica, la capacità viene spesso determinata tramite test di carico, osservazione e ottimizzazione iterativa anziché una modellazione iniziale precisa.

Monitorare la distribuzione del carico tra istanze ridondanti

Quando si esegue il carico di lavoro tra più istanze ridondanti, tra cui quando si distribuiscono istanze tra aree o zone diverse, il traffico e l'utilizzo delle risorse devono rimanere bilanciati tra tali istanze.

Si vogliono individuare squilibri che spesso puntano a problemi di routing, problemi di configurazione o vincoli di dipendenza. Garantisce inoltre che le destinazioni di failover abbiano capacità sufficiente per assorbire il traffico quando necessario e conferma che i meccanismi di ridondanza si comportano come previsto durante gli scenari di funzionamento a stato stabile e di errore.

Rilevare le modalità di errore

Nell'ambito dell'esercizio di analisi della modalità di errore (FMA), è necessario aver identificato i potenziali punti di errore.

Nella pratica di monitoraggio dell'affidabilità, mantenere un controllo continuo su tali punti. Iniziare concentrandosi su segnali più semplici, ad esempio errori temporanei. Monitorare il comportamento dei tentativi e i tassi di errore transitori per comprendere l'operato delle dipendenze e dei servizi sottostanti in condizioni operative reali. Questi segnali forniscono una visione preliminare dell'instabilità emergente. Consentono di riconoscere quando i pattern di ritentativi si allontanano dalla norma prevista, forniscono un'indicazione sullo stato di salute del sistema sotto carico e identificano quando una dipendenza o un servizio esterno inizia a degradare prima che influisca sull'esperienza dell'utente.

Includere anche errori di impatto maggiore, come interruzioni delle zone di disponibilità che influenzano un sottogruppo di infrastruttura, interruzioni del servizio o interruzioni regionali che mettono offline un'intera area di Azure. Anche controllare gli scenari di sicurezza, ad esempio DDoS o altre attività dannose, errori di configurazione dei componenti e problemi di prestazioni, perché ognuno di essi può influire sull'affidabilità complessiva della soluzione.

Per informazioni su FMA, vedere Strategie di architettura per l'analisi della modalità di errore.

Essere informati sullo stato di affidabilità della piattaforma

Sono necessarie informazioni chiare sull'integrità della piattaforma per gestire in modo efficace l'affidabilità. Questa consapevolezza consente di determinare rapidamente se un problema ha origine nel carico di lavoro o nella piattaforma cloud sottostante.

Integrità dei servizi di Azure offre visibilità sullo stato di Azure. Configurare gli avvisi sull'integrità dei servizi in modo da ricevere notifiche quando cambiano le condizioni della piattaforma. Si ricevono aggiornamenti in caso di interruzioni attive che interessano le risorse, gli eventi di manutenzione pianificata che possono introdurre interruzioni e riduzione delle prestazioni specifiche del servizio o a livello di area.

Facilitazione di Azure

• Incorporare i servizi di monitoraggio e avviso della piattaforma cloud, tra cui:

  • Integrità a livello di piattaforma, ad esempio Integrità dei servizi di Azure.

  • Integrità delle risorse, come Azure Resource Health.

• Monitoraggio di Azure è una soluzione di monitoraggio completa usata per raccogliere, analizzare e rispondere ai dati di monitoraggio dagli ambienti cloud e locali.

• Log Analytics è uno strumento nel portale di Azure usato per modificare ed eseguire query di log sui dati nell'area di lavoro Log Analytics.

• Application Insights è un'estensione di Azure Monitor. Fornisce funzionalità di monitoraggio delle prestazioni dell'applicazione (APM).

• Approfondimenti di Azure Monitor sono strumenti di analisi avanzati che consentono di monitorare i servizi di Azure, ad esempio macchine virtuali, servizi applicativi e contenitori. Le informazioni dettagliate si basano su Azure Monitor e Log Analytics.

• Azure Monitor per le soluzioni SAP è un prodotto di monitoraggio nativo di Azure per ambienti SAP che operano in Azure.

• Monitoraggio connessione è uno strumento per monitorare continuamente la connettività di rete e le prestazioni tra le risorse di Azure. Esegue test sintetici e fornisce avvisi e diagnostica in tempo reale per rilevare gli errori in anticipo. È possibile creare cartelle di lavoro personalizzate per visualizzare l'integrità della connettività e le metriche delle prestazioni aggregate.

• I log dei flussi di rete virtuale possono essere abilitati tra carichi di lavoro per monitorare il traffico di rete. L'analisi del traffico può essere usata per analizzare e arricchire questi log di flusso per visualizzare informazioni dettagliate, ad esempio il traffico bloccato, i flussi dannosi e le porte attive esposte a Internet. La creazione di cartelle di lavoro consente ai team di monitorare il comportamento del traffico live e ricevere avvisi. Usare visualizzazioni della sequenza temporale e visualizzazioni della topologia per monitorare facilmente i modelli di traffico che potrebbero indicare una riduzione delle prestazioni o minacce alla sicurezza.

• Per le procedure consigliate per più aree di lavoro, vedere Progettare un'architettura dell'area di lavoro Log Analytics.

Esempio

Per esempi di soluzioni di monitoraggio reali, vedere Monitoraggio delle applicazioni Web in Azure e Architettura di base per un cluster servizio Azure Kubernetes.

Collegamenti della community

• Gli avvisi di base di Monitoraggio di Azure (AMBA) sono un repository centrale di definizioni di avviso che i clienti e i partner possono usare per migliorare l'esperienza di osservabilità tramite l'adozione di Monitoraggio di Azure.

Elenco di controllo per l'affidabilità

Fare riferimento al set completo di raccomandazioni.