Strategie di architettura per il monitoraggio delle prestazioni del carico di lavoro

Questa raccomandazione della checklist sull'efficienza delle prestazioni del Framework Azure Well-Architected si applica a:

Senza dati sulle prestazioni, i problemi sottostanti e le opportunità di ottimizzazione non vengono rilevati, causando un calo dell'esperienza utente.

Questo articolo descrive le strategie di progettazione per l'implementazione di misurazioni delle prestazioni a più livelli che acquisiscono la latenza, la velocità effettiva e il comportamento delle risorse per stabilire le linee di base e identificare la riduzione delle prestazioni nel carico di lavoro.

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. Le raccomandazioni contenute in questa guida sono mirate alle prestazioni. Per informazioni sull'affidabilità, vedere Strategie di architettura RE:10 per la progettazione di una strategia di monitoraggio e avviso affidabile.

Definizioni

Usare le metriche basate su percentile

Misurare le metriche delle prestazioni, ad esempio la latenza, il tempo di risposta o i tempi di caricamento, con percentili (p50, p95, p99), non medie. Le medie possono essere fuorvianti. Se la maggior parte delle richieste è veloce ma alcune sono estremamente lente, la media nasconderà l'esperienza negativa.

I percentili mostrano il comportamento della coda, che è importante per comprendere l'esperienza utente. p50 rappresenta le prestazioni tipiche, p95 mostra l'esperienza della maggior parte degli utenti sotto carico e p99 acquisisce le prestazioni peggiori o gli outlier.

Raccogliere i dati sulle prestazioni usando gli strumenti di monitoraggio e rappresentarli come percentili in finestre temporali definite. Usarli come baseline per il monitoraggio, gli avvisi e l'analisi delle prestazioni.

Definire i limiti di miglioramento delle prestazioni

Definire limiti di prestazioni chiari in modo da sapere esattamente cosa è incluso nelle misurazioni. Suddividere la latenza nel sistema anziché considerarla come un singolo numero. Per esempio, attribuire tempo a ogni livello in cui si trovano servizi perimetrali, gateway, elaborazione e dipendenze, per vedere dove si verificano effettivamente ritardi.

Separare ciò che si controlla da ciò che non si esegue: il codice, i servizi, l'infrastruttura e le dipendenze dirette rispetto a fattori esterni, ad esempio condizioni lato client, risoluzione DNS, latenza ISP o vincoli del dispositivo. Questa distinzione impedisce la distribuzione errata e mantiene l'ottimizzazione incentrata sulle aree in cui è possibile apportare modifiche, riflettendo comunque l'esperienza utente end-to-end completa.

Valutare quando e dove i problemi di prestazioni influiscono sull'esperienza utente. Compensare quella degradazione attraverso la progettazione o mitigare tramite miglioramenti nelle parti controllabili del sistema.

Segmentare i segnali per ambiente e scopo

Segmentare i dati sulle prestazioni in modo che ogni segnale rifletta un contesto chiaro. Separare per ambiente e per scopo per evitare di mescolare segnali che si comportano in modo diverso o portano a decisioni differenti.

Mantenere separati i dati di produzione e non di produzione. I dati di produzione riflettono l'impatto reale dell'utente e devono guidare il monitoraggio e gli avvisi. I dati non di produzione sono utili per i test e l'ottimizzazione, ma mescolarli con i dati di produzione distorce i risultati e nasconde i problemi reali.

Separare le metriche delle prestazioni dalle metriche aziendali. Le metriche delle prestazioni tengono traccia del comportamento del sistema e dell'integrità del carico di lavoro, mentre le metriche aziendali tengono traccia dei risultati. Anche quando si sovrappongono, mantenerli in flussi distinti in modo che ognuno possa essere analizzato e usato in modo indipendente.

Creare avvisi sulle prestazioni mirati e attuabili

L'obiettivo dell'invio di avvisi è il rilevamento anticipato della riduzione delle prestazioni prima che diventi visibile all'utente o che influisca sull'azienda. Creare avvisi a due livelli: esperienza utente end-to-end e transazioni interne principali che rappresentano percorsi di sistema critici sotto carico.

Usare un singolo set di dati coerente all'interno di ogni ambiente sia per le destinazioni che per gli avvisi. Se gli avvisi sono basati su dati diversi rispetto agli obiettivi di prestazioni, diventano inaffidabili e difficili da considerare attendibili.

Creare avvisi interattivi e chiaramente legati ai risultati delle prestazioni. Ogni avviso deve indicare quale soglia ha avuto una violazione sostenuta, il potenziale impatto e i componenti coinvolti, in modo che sia chiaro dove analizzare e cosa è interessato. Iniziare con soglie standard e note, quindi perfezionarle nel tempo in base al comportamento del sistema osservato e alle caratteristiche del carico di lavoro.

Quando non è possibile inviare avvisi diretti su una dipendenza esterna, usare segnali indiretti, ad esempio durata delle chiamate di dipendenza, tassi di errore o comportamento di timeout per approssimarne l'impatto sulle prestazioni del sistema.

Monitorare l'elasticità

Misurare il modo in cui il sistema risponde alle modifiche apportate agli eventi di domanda e ridimensionamento.

Tenere traccia della latenza di avvio a freddo e inizializzazione per comprendere in che modo il sovraccarico di avvio influisce sulla velocità di risposta, soprattutto durante gli eventi di scalabilità orizzontale. Monitorare il comportamento di scalabilità verso l'esterno e scalabilità verso l'interno per valutare la velocità con cui il sistema si adatta alle modifiche del carico e se le azioni di ridimensionamento soddisfano la domanda.

Tenere traccia delle prestazioni nel tempo

Tenere traccia dell'evoluzione delle prestazioni con le modifiche apportate alla progettazione e ai fattori esterni.

Stabilire linee di base che rappresentano le prestazioni previste del sistema, quindi confrontare il comportamento corrente con essi per rilevare la deriva, incluse le regressioni e i miglioramenti.

Connettere le modifiche delle prestazioni agli eventi operativi, ad esempio distribuzioni, aggiornamenti della configurazione e azioni di ridimensionamento. Annotare le sequenze temporali con questi eventi in modo che i cambiamenti nel comportamento abbiano un contesto chiaro e possano essere ricontracciati a cause probabili.

Usare questa visibilità continua come ciclo di feedback per le decisioni di progettazione. Inserire informazioni dettagliate sulle prestazioni per la pianificazione e la definizione delle priorità e considerarle come input per il lavoro normale anziché solo per la risposta agli eventi imprevisti.

Perfezionare continuamente gli obiettivi di prestazioni man mano che il sistema si evolve. Regolare gli SLO, le soglie e le aspettative in base ai modelli di utilizzo osservati e al comportamento osservato, in modo che gli obiettivi rimangano realistici e allineati all'effettiva esperienza utente.

Raccogliere dati sulle prestazioni dell'applicazione

È necessario disporre delle metriche delle prestazioni dell'applicazione, ad esempio velocità effettiva, latenza e tempi di completamento, raccolti principalmente tramite il codice di strumentazione.

Strumentare i percorsi critici di esecuzione in cui le prestazioni sono più evidenti: flussi di richieste chiave, operazioni con un intenso utilizzo di risorse e punti in cui si verificano dipendenze esterne o tentativi di ripetizione. Assicurarsi che la visibilità delle transazioni end-to-end consenta di misurare il tempo di esecuzione totale e i relativi passaggi di contributo.

Acquisire tre tipi di base di segnali di prestazioni:

• Metriche per il comportamento aggregato delle prestazioni (distribuzioni di latenza, velocità effettiva, velocità di errore)
• Tracce per comprendere il modo in cui il tempo viene distribuito tra i percorsi delle richieste e i componenti di sistema
• Log per un contesto di esecuzione dettagliato in passaggi o eventi specifici

Usare metadati coerenti tra questi segnali in modo che i dati sulle prestazioni possano essere correlati tra i livelli del sistema e tra i servizi.

Evitare di duplicare i segnali di prestazioni di livello inferiore già esposti dalla piattaforma, a meno che non sia necessaria una granularità aggiuntiva per spiegare i colli di bottiglia o il comportamento specifico del carico di lavoro.

Raccogliere dati sulle prestazioni delle risorse

Raccogliere dati sulle prestazioni a livello di risorsa per comprendere il comportamento dei componenti dell'infrastruttura sotto carico e come contribuiscono alle prestazioni complessive del carico di lavoro.

Ogni servizio espone metriche specifiche della piattaforma che riflettono le relative caratteristiche di integrità e prestazioni. Usare l'impostazione di diagnostica per esportare questi dati in modo che sia possibile accedervi per avvisi, dashboard e analisi a lungo termine, oltre i limiti di conservazione temporanea della piattaforma.

Raccogliere metriche e log per tutte le risorse. Monitorare l'utilizzo del calcolo e della archiviazione rispetto agli intervalli previsti per assicurarsi che il sotto-provisionamento non introduca latenza e non degradi le prestazioni sotto carico. L'overprovisioning è rilevabile anche con questi dati esaminando l'utilizzo di P99 e confrontando le risorse rimanenti.

Monitorare il traffico di rete come parte delle prestazioni delle risorse. Analizzare il flusso del traffico tra subnet e limiti del servizio per comprendere i modelli di latenza, congestione e trasferimento dei dati che possono influire sulle prestazioni del carico di lavoro.

Raccogliere dati di archiviazione e di database

I sistemi di database e di archiviazione generano segnali di prestazioni altamente specializzati per identificare i colli di bottiglia, convalidare la capacità e comprendere il comportamento del carico di lavoro. Questi segnali provengono in genere da strumenti di monitoraggio predefiniti e log generati dal sistema.

Concentrarsi sulle dimensioni principali delle prestazioni:

Per i database, estendere il monitoraggio al comportamento specifico del carico di lavoro:

Usare questi segnali insieme per distinguere meglio tra query rallentate, saturazione delle risorse e inefficienze strutturali. Ciò consente l'ottimizzazione mirata sia nei sistemi di archiviazione che nei carichi di lavoro del database.

Raccogliere i dati sulle prestazioni del sistema operativo

Per i carichi di lavoro basati sull'infrastruttura, raccogliere le metriche a livello di sistema operativo per comprendere come vengono usate le risorse di calcolo e dove possono verificarsi vincoli di risorse.

Contatori delle prestazioni del sistema operativo di esempio a intervalli regolari per acquisire il comportamento basato sul tempo del sistema sotto carico.

Usare questi segnali per identificare la saturazione delle risorse a livello di sistema operativo e distinguere tra inefficienze a livello di applicazione e vincoli di infrastruttura.

Generare dati sintetici, quando necessario

Se il sistema non viene usato in modo coerente, è difficile stabilire se avrà prestazioni buone quando il traffico viene restituito.

Per risolvere questo problema, usare transazioni sintetiche che inviano richieste automatizzate tramite il sistema. Questi simulano l'utilizzo reale senza influire sugli utenti o sui dati effettivi. Ciò consente di mantenere attive parti del sistema, generare metriche di prestazioni coerenti e rivelare modelli (ad esempio problemi di tempo del giorno) che l'utilizzo irregolare potrebbe nascondere.

Facilitazione di Azure

Azure Monitor offre una piattaforma unificata per la raccolta, l'analisi e la risposta ai dati sulle prestazioni nell'intero carico di lavoro. Aggrega i dati dalle applicazioni, dall'infrastruttura e dalle origini esterne in una piattaforma dati comune.

Raccolta e archiviazione dei dati: usare le aree di lavoro Log Analytics per centralizzare i dati sulle prestazioni con criteri di conservazione configurabili. Creare più aree di lavoro per segmentare i dati in base ai requisiti di ambiente o conformità.

Monitoraggio delle applicazioni: Application Insights raccoglie i dati di telemetria a livello di applicazione, inclusi i tassi di richiesta, i tempi di risposta e le eccezioni. Abilitare la traccia distribuita per correlare le prestazioni tra i componenti distribuiti.

Monitoraggio dell'infrastruttura: abilitare le impostazioni di diagnostica in tutti i servizi di Azure per raccogliere i log e le metriche della piattaforma. Usare l'estensione Diagnostica di Azure per dati dettagliati sulle prestazioni delle macchine virtuali. Esplorare le opzioni di telemetria per la piattaforma specifica. Ad esempio, i cluster Kubernetes generano dati di telemetria avanzati sulle prestazioni tramite le integrazioni di Prometheus .

Database e archiviazione: Azure Monitor offre il monitoraggio predefinito per Azure SQL Database, MySQL, PostgreSQL e servizi di archiviazione. Analisi di Azure Storage tiene traccia degli indicatori chiave di prestazione, come velocità effettiva e latenza, su Storage Blob, tabelle e code di archiviazione.

Avvisi e analisi: creare regole di avviso con soglie personalizzabili, finestre temporali e azioni (posta elettronica, webhook, Funzioni di Azure). Usare i log di Monitoraggio di Azure per eseguire query incrociate e correlare i dati sulle prestazioni. Per informazioni dettagliate sui prezzi, vedere Prezzi di Monitoraggio di Azure.

Esempi

• Applicazione Web dei servizi applicativi di base con ridondanza di zona e alta disponibilità
• Monitorare un'applicazione di microservizi in Azure Kubernetes Service (AKS)
• Monitorare i componenti della zona di destinazione delle piattaforme di Azure

Collegamenti correlati

• Metriche della piattaforma
• Impostazioni di diagnostica
• Log di controllo

Elenco di controllo dell'efficienza prestazionale

Fare riferimento al set completo di raccomandazioni.