Raccomandazioni per la progettazione e la creazione di un sistema di monitoraggio

Articolo
11/15/2023

Si applica a questo elenco di controllo di Eccellenza operativa di Azure Well-Architected Framework:

OE:07	Progettare e implementare un sistema di monitoraggio per convalidare le scelte di progettazione e informare le future decisioni di progettazione e business. Questo sistema acquisisce ed espone i dati di telemetria, le metriche e i log operativi che emettono dall'infrastruttura e dal codice del carico di lavoro.

Guida correlata: Raccomandazioni per la strumentazione di un'applicazione

Questa guida descrive i consigli per la progettazione e la creazione di un sistema di monitoraggio. Per monitorare efficacemente il carico di lavoro per la sicurezza, le prestazioni e l'affidabilità, è necessario un sistema completo con il proprio stack che fornisce la base per tutte le funzioni di monitoraggio, rilevamento e avviso.

Definizioni

Termine	Definizione
Log	Eventi di sistema registrati. I log possono contenere diversi tipi di dati in un formato di testo strutturato o libero. Contengono un timestamp.
Metriche	Valori numerici raccolti a intervalli regolari. Le metriche descrivono alcuni aspetti di un sistema in un determinato momento.

Strategie di progettazione chiave

Per implementare una progettazione completa del sistema di monitoraggio per il carico di lavoro, seguire questi set di base:

Ogni volta che è pratico, sfruttare gli strumenti di monitoraggio forniti dalla piattaforma, che in genere richiedono una configurazione molto piccola e possono fornire informazioni dettagliate sul carico di lavoro che potrebbero altrimenti essere difficili da eseguire.
Raccogliere log e metriche dall'intero stack del carico di lavoro. Tutte le risorse dell'infrastruttura e le funzioni dell'applicazione devono essere configurate per produrre dati standardizzati, significativi e che i dati devono essere raccolti.
Archiviare i dati raccolti in una soluzione di archiviazione standardizzata, affidabile e sicura.
Elaborare i dati archiviati in modo che possa essere gestito da soluzioni di analisi e visualizzazione.
Analizzare i dati elaborati per determinare con precisione lo stato del carico di lavoro.
Visualizzare lo stato del carico di lavoro in dashboard o report significativi per i team del carico di lavoro e altri stakeholder.
Configurare avvisi utilizzabili e altre risposte automatiche alle soglie definite in modo intelligente per notificare ai team del carico di lavoro quando si verificano problemi.
Includere sistemi di monitoraggio e avviso nelle procedure di test generali del carico di lavoro.
Assicurarsi che i sistemi di monitoraggio e avviso siano nell'ambito del miglioramento continuo. Il comportamento dell'applicazione e dell'infrastruttura nell'ambiente di produzione offre opportunità di apprendimento continuo. Incorporare tali lezioni nei progetti di monitoraggio e avviso.
Collegare i dati di monitoraggio raccolti e analizzare nuovamente al sistema e ai flussi utente per correlare l'integrità dei flussi con i dati oltre all'integrità complessiva del carico di lavoro. L'analisi dei dati in termini di flussi consente di allineare la strategia di osservabilità al modello di integrità.

È consigliabile automatizzare tutte le funzioni del sistema di monitoraggio il più possibile e devono essere eseguite in modo continuo, ogni giorno.

Questa pipeline del flusso di lavoro illustra il sistema di monitoraggio:

Raccolta

Nota

È necessario instrumentare l'applicazione per abilitare la registrazione. Per altre informazioni, vedere la guida alla strumentazione.

È necessario configurare tutti i componenti del carico di lavoro, indipendentemente dal fatto che siano risorse dell'infrastruttura o funzioni dell'applicazione, per acquisire dati di telemetria e/o eventi come log e metriche.

I log sono principalmente utili per rilevare e analizzare le anomalie. In genere, i log vengono generati dal componente del carico di lavoro e quindi inviati alla piattaforma di monitoraggio o estratti dalla piattaforma di monitoraggio tramite automazione.

Le metriche sono principalmente utili per la creazione di un modello di integrità e l'identificazione delle tendenze nelle prestazioni e nell'affidabilità del carico di lavoro. Le metriche sono utili anche per identificare le tendenze nel comportamento di utilizzo dei clienti. Queste tendenze possono aiutare a guidare le decisioni sui miglioramenti dal punto di vista del cliente. In genere, le metriche sono definite nella piattaforma di monitoraggio e la piattaforma di monitoraggio e altri strumenti esegue il polling del carico di lavoro per acquisire le metriche.

Dati dell'applicazione

Per le applicazioni, il servizio di raccolta può essere uno strumento di gestione delle prestazioni dell'applicazione (APM) che può essere eseguito autonomamente dall'applicazione che genera i dati di strumentazione. Dopo l'abilitazione di APM, si ha una chiara visibilità sulle metriche importanti, in tempo reale e storicamente. Usare un livello appropriato di registrazione. La registrazione dettagliata può avere costi significativi. Impostare i livelli di log in base all'ambiente. Gli ambienti inferiori non necessitano dello stesso livello di verbosità dell'ambiente di produzione, ad esempio.

I registri applicazioni supportano il ciclo di vita delle applicazioni end-to-end. La registrazione è essenziale per comprendere il funzionamento dell'applicazione in vari ambienti, gli eventi che si verificano e le condizioni in cui si verificano.

È consigliabile raccogliere i log e gli eventi delle applicazioni in tutti gli ambienti principali. Separare i dati tra ambienti il più possibile usando archivi dati diversi per ogni ambiente, se necessario. Usare filtri per assicurarsi che gli ambienti non critici non complicano l'interpretazione dei log di produzione. Infine, le voci di log corrispondenti nell'applicazione devono acquisire un ID di correlazione per le rispettive transazioni.

È necessario acquisire gli eventi dell'applicazione nei tipi di dati strutturati con punti dati leggibili dal computer anziché tipi di stringa non strutturati. Un formato strutturato che usa uno schema noto può semplificare l'analisi e l'analisi dei log. Inoltre, i dati strutturati possono essere facilmente indicizzati e cercati e la creazione di report può essere notevolmente semplificata.

I dati devono essere in un formato agnostico indipendente dal computer, dal sistema operativo o dal protocollo di rete. Ad esempio, genera informazioni in un formato autodescrizione come JSON, MessagePack o Protobuf anziché ETL/ETW. Un formato standard consente al sistema di costruire pipeline di elaborazione. I componenti che leggono, trasformano e inviano dati nel formato standard possono essere facilmente integrati.

Dati dell'infrastruttura

Per le risorse dell'infrastruttura nel carico di lavoro, assicurarsi di raccogliere sia log che metriche. Per i sistemi IaaS (infrastructure as a service), acquisire sistema operativo, livello applicazione e log di diagnostica oltre alle metriche correlate all'integrità del carico di lavoro. Per le risorse PaaS (Platform as a Service), è possibile limitare la possibilità di acquisire i log correlati all'infrastruttura sottostante, ma assicurarsi di poter acquisire i log di diagnostica oltre alle metriche correlate all'integrità del carico di lavoro.

Il più possibile, raccogliere i log dalla piattaforma cloud. Potrebbe essere possibile raccogliere i log attività per la sottoscrizione e i log di diagnostica per il piano di gestione.

Strategie di raccolta

Evitare di recuperare manualmente i dati di telemetria da ogni componente. Spostare i dati in una posizione centrale e consolidarla. Per una soluzione multi-area, è consigliabile raccogliere, consolidare e archiviare i dati in base all'area e quindi aggregare i dati a livello di area in un singolo sistema centrale.

Compromesso: tenere presente che ci sono implicazioni sul costo per avere archivi dati regionali e centralizzati.

Per ottimizzare l'uso della larghezza di banda, assegnare la priorità in base all'importanza dei dati. È possibile trasferire dati meno urgenti in batch. Tuttavia, questi dati non devono essere ritardati indefiniti, soprattutto se contengono informazioni sensibili al tempo.

Esistono due modelli principali che il servizio di raccolta può usare per raccogliere i dati di strumentazione:

Modello pull: recupera attivamente i dati dai vari log e altre origini per ogni istanza dell'applicazione.
Modello push: attende passivamente l'invio dei dati dai componenti che costituiscono ogni istanza dell'applicazione.

Agenti di monitoraggio

È possibile usare gli agenti di monitoraggio nel modello pull. Gli agenti vengono eseguiti localmente in un processo separato con ogni istanza dell'applicazione, eseguendo periodicamente il pull dei dati e scrivendo le informazioni direttamente nell'archiviazione comune condivisa da tutte le istanze dell'applicazione.

Nota

L'uso di un agente di monitoraggio è particolarmente indicato per l'acquisizione dei dati di strumentazione estratti in modo naturale da un'origine dati. È appropriato per un'applicazione su larga scala che viene eseguita in un numero limitato di nodi in una singola posizione. Alcuni esempi includono informazioni provenienti da SQL Server viste di gestione dinamica o dalla lunghezza di una coda di bus di servizio di Azure.

Considerazioni sulle prestazioni

Un'applicazione complessa e altamente scalabile potrebbe generare grandi volumi di dati. La quantità di dati può facilmente sovraccaricare la larghezza di banda di I/O disponibile per una singola posizione centrale. La soluzione di telemetria non deve fungere da collo di bottiglia e deve essere scalabile quando il sistema si espande. Idealmente, la soluzione deve incorporare un grado di ridondanza per ridurre i rischi di perdita di informazioni di monitoraggio importanti (come il controllo o i dati di fatturazione) se parte del sistema ha esito negativo.

Un modo per memorizzare nel buffer i dati di strumentazione consiste nell'usare l'accodamento:

In questa architettura, il servizio di raccolta dati inserisce i dati in una coda. Una coda di messaggi è adatta perché fornisce semantica "almeno una volta" che consente di garantire che i dati in coda non andranno persi dopo la pubblicazione. È possibile implementare il servizio di scrittura archiviazione usando un ruolo di lavoro separato. È possibile usare il modello di coda priorità per implementare questa architettura.

Per la scalabilità, è possibile eseguire più istanze del servizio di scrittura archiviazione. Se viene monitorato un volume elevato di eventi o un numero elevato di punti dati, è possibile usare Hub eventi di Azure per inviare i dati a un'istanza di calcolo diversa per l'elaborazione e l'archiviazione.

Strategie di consolidamento

I dati raccolti da una singola istanza di un'applicazione forniscono una visualizzazione localizzata dell'integrità e delle prestazioni di tale istanza. Per valutare l'integrità complessiva del sistema, è necessario consolidare alcuni aspetti dei dati dalle viste locali. È possibile eseguire questa operazione dopo l'archiviazione dei dati, ma, in alcuni casi, è possibile farlo quando vengono raccolti i dati.

I dati di strumentazione possono passare attraverso un servizio di consolidamento separato che combina i dati e funge da processo di filtro e pulizia. Ad esempio, è possibile amalgamate dati di strumentazione che includono le stesse informazioni di correlazione, ad esempio un ID attività. Un utente potrebbe avviare un'operazione aziendale in un nodo e quindi essere trasferito a un altro nodo se il primo nodo ha esito negativo o a causa della configurazione del bilanciamento del carico. Questo processo può anche rilevare e rimuovere tutti i dati duplicati. La duplicazione può verificarsi se il servizio di telemetria usa code di messaggi per eseguire il push dei dati di strumentazione nell'archiviazione.

Archiviazione

Quando si sceglie una soluzione di archiviazione, considerare il tipo di dati, il modo in cui vengono usati e quanto è necessario.

Nota

Usare soluzioni di archiviazione separate per ambienti non di produzione e di produzione per garantire che i dati di ogni ambiente siano facili da identificare e gestire.

Tecnologie di archiviazione

Si consideri un approccio di persistenza poliglotta, in cui diversi tipi di informazioni vengono archiviati in tecnologie più appropriate per il modo in cui è probabile che venga usato ogni tipo.

Ad esempio, Archiviazione BLOB di Azure e Archiviazione tabelle di Azure sono accessibili in modi simili. Tuttavia, le operazioni che è possibile eseguire su di esse differiscono, in quanto la granularità dei dati che contengono. Se è necessario eseguire altre operazioni di analisi o servono funzionalità di ricerca full-text sui dati, è preferibile usare l'archiviazione dei dati che fornisce funzionalità ottimizzate per specifici tipi di query e accesso ai dati. Ad esempio:

I dati dei contatori delle prestazioni possono essere archiviati in un database SQL per abilitare l'analisi ad hoc.
Potrebbe essere preferibile archiviare i log di traccia nei log di Monitoraggio di Azure o in Azure Esplora dati.
È possibile archiviare le informazioni di sicurezza in una soluzione HDFS.

Gli stessi dati di strumentazione potrebbero essere necessari per più scopi. Ad esempio, è possibile usare i contatori delle prestazioni per fornire una visualizzazione cronologica delle prestazioni del sistema nel tempo. Queste informazioni potrebbero essere combinate con altri dati sull'utilizzo per generare informazioni di fatturazione clienti. In queste situazioni, gli stessi dati possono essere inviati a più di una destinazione, ad esempio a un database di documenti che può essere un archivio a lungo termine per la conservazione delle informazioni di fatturazione e a un archivio multidimensionale per la gestione di analisi delle prestazioni complesse.

Assicurarsi di abilitare la funzionalità per proteggere i dati dall'eliminazione accidentale, ad esempio blocchi delle risorse ed eliminazione temporanea.

Assicurarsi inoltre di proteggere l'accesso all'archiviazione usando il controllo degli accessi in base al ruolo per garantire che solo gli utenti che devono accedere ai dati possano farlo.

Servizio di consolidamento

È possibile implementare un altro servizio che recupera periodicamente i dati dall'archiviazione condivisa, dalle partizioni e li filtra in base allo scopo e quindi li scrive in un set appropriato di archivi dati.

Un approccio alternativo consiste nell'includere questa funzionalità nel processo di consolidamento e pulizia e nello scrivere i dati direttamente in questi archivi man mano che vengono recuperati, piuttosto che salvarli in un'area di archiviazione intermedia condivisa.

Ogni approccio presenta vantaggi e svantaggi. L'implementazione di un servizio di partizionamento separato riduce il carico sul servizio di consolidamento e pulizia e consente di rigenerare almeno alcuni dei dati partizionati, se necessario ,a seconda della quantità di dati conservati nell'archiviazione condivisa. Tuttavia, questo approccio usa risorse aggiuntive. Potrebbe anche verificarsi un ritardo tra la ricezione dei dati di strumentazione da ogni istanza dell'applicazione e la conversione dei dati in informazioni di utilità operativa.

Considerazioni sull'esecuzione di query

Considerare l'urgenza con cui vengono richiesti i dati. È indispensabile accedere rapidamente ai dati che generano avvisi, pertanto questi dati devono essere mantenuti all'interno di risorse di archiviazione rapide e indicizzati o strutturati in modo da ottimizzare le query eseguite dal sistema di avvisi. In alcuni casi, potrebbe essere necessario che il servizio di raccolta formatti e salvi i dati in locale in modo che un'istanza locale del sistema di avvisi possa inviare rapidamente le notifiche. Gli stessi dati possono essere inviati al servizio di scrittura nell'archivio visualizzato nei diagrammi precedenti e archiviati in modo centralizzato, se necessari anche per altri scopi.

Considerazioni sulla conservazione dei dati

In alcuni casi, dopo l'elaborazione e il trasferimento dei dati, è possibile rimuovere i dati di origine non elaborati originali archiviati in locale. In altri casi, potrebbe essere necessario o utile salvare le informazioni non elaborate. Ad esempio, è possibile mantenere i dati generati per il debug disponibili nel formato non elaborato, ma eliminarli rapidamente dopo la risoluzione di eventuali bug.

I dati sulle prestazioni hanno spesso una durata più lunga, in modo da poterli usare per individuare le tendenze delle prestazioni e per la pianificazione della capacità. La visualizzazione consolidata di questi dati viene generalmente mantenuta online per un periodo limitato, per consentirne l'accesso rapido. In seguito, questi dati possono essere archiviati o eliminati.

Archiviare dati cronologici è utile per individuare le tendenze a lungo termine. Invece di salvare i dati obsoleti nel suo complesso, è possibile eseguire il down-sample dei dati per ridurre la risoluzione e risparmiare sui costi di archiviazione. Ad esempio, invece di risparmiare indicatori di prestazioni minuti per minuto, è possibile consolidare i dati che hanno più di un mese prima per formare una visualizzazione oraria.

I dati raccolti per la misurazione e la fatturazione ai clienti potrebbero dover essere salvati a tempo indeterminato. Inoltre, i requisiti normativi potrebbero determinare che le informazioni raccolte per il controllo e la sicurezza devono essere archiviate e salvate. Anche questi dati sono riservati e potrebbe essere necessario crittografarli o proteggerli in altro modo per evitare manomissioni. È consigliabile non registrare mai password utente o altre informazioni che potrebbero essere usate per commettere frodi di identità. È consigliabile rimuovere questi dettagli dai dati prima che vengano archiviati.

Per garantire la conformità alle leggi e alle normative, ridurre al minimo l'archiviazione di eventuali informazioni identificabili. Se è necessario archiviare informazioni identificabili, assicurarsi che, quando si progetta la soluzione, tenere conto dei requisiti che consentono agli utenti di richiedere l'eliminazione delle informazioni.

Analisi

Dopo aver raccolto i dati da varie origini dati, analizzarli per valutare il benessere complessivo del sistema. Per questa analisi, avere una chiara comprensione di:

Come strutturare i dati in base agli indicatori KPI e alle metriche delle prestazioni definiti.
Come correlare i dati acquisiti in diverse metriche e file di log. Questa correlazione è importante quando si monitora una sequenza di eventi e consente di diagnosticare i problemi.

Nella maggior parte dei casi, i dati per ogni componente dell'architettura vengono acquisiti in locale e quindi combinati in modo accurato con i dati generati da altri componenti.

Ad esempio, un'applicazione a tre livelli potrebbe avere:

Livello presentazione che consente a un utente di connettersi a un sito Web.
Livello intermedio che ospita un set di microservizi che elabora la logica di business.
Livello di database che archivia i dati associati all'operazione.

I dati di utilizzo per una singola operazione aziendale possono estendersi a tutti e tre i livelli. Queste informazioni devono essere correlate per fornire una panoramica sull'utilizzo delle risorse e dell'elaborazione per l'operazione. La correlazione potrebbe comportare alcune operazioni di pre-elaborazione e filtro dei dati a livello di database. Nel livello intermedio, l'aggregazione e la formattazione sono attività comuni.

Consigli

Correlare i log a livello di applicazione e a livello di risorsa. Valutare i dati a entrambi i livelli per ottimizzare il rilevamento dei problemi e la risoluzione di tali problemi. È possibile aggregare i dati in un singolo sink di dati o sfruttare i metodi che eseguono query sugli eventi in entrambi i livelli. È consigliabile una soluzione unificata, ad esempio Azure Log Analytics, per aggregare ed eseguire query sui log a livello di applicazione e a livello di risorsa.
Definire tempi di conservazione chiari nell'archiviazione per l'analisi a freddo. È consigliabile usare questa procedura per abilitare l'analisi cronologica in un periodo specifico. Può anche aiutare a controllare i costi di archiviazione. Implementare processi che assicurano che i dati vengano archiviati in un archivio più economico e aggregano i dati per l'analisi delle tendenze a lungo termine.
Analizzare le tendenze a lungo termine per stimare i problemi operativi. Valutare i dati a lungo termine per formare strategie operative e anche per prevedere quali problemi operativi potrebbero verificarsi e quando. Ad esempio, è possibile notare che i tempi medi di risposta aumentano lentamente nel tempo e si avvicinano alla destinazione massima.

Per indicazioni dettagliate su queste raccomandazioni, vedere Analizzare i dati di monitoraggio per le applicazioni cloud.

Visualizzazione

Dashboard

Il modo più comune per visualizzare i dati consiste nell'usare dashboard che possono visualizzare le informazioni come una serie di grafici o grafici o in un altro modulo visivo. Questi elementi possono essere parametrizzati e un analista può selezionare i parametri importanti, ad esempio il periodo di tempo, per qualsiasi situazione specifica.

Allineare i dashboard al modello di integrità in modo che indichino quando il carico di lavoro o i componenti del carico di lavoro sono integri, degradati o non integri.

Affinché un sistema del dashboard funzioni in modo efficace, deve essere significativo per il team del carico di lavoro. Visualizzare le informazioni correlate all'integrità del carico di lavoro ed è possibile intervenire. Quando il carico di lavoro o un componente è danneggiato o non integro, i membri del team del carico di lavoro devono essere in grado di identificare facilmente dove ha origine il problema e avviare le azioni correttive o le indagini. Viceversa, incluse le informazioni che non sono utilizzabili o che non sono correlate all'integrità del carico di lavoro, possono rendere il dashboard inutilmente complesso e frustrante per i membri del team che tentano di distinguere il rumore di fondo dai dati interattivi.

È possibile che siano presenti dashboard per stakeholder o sviluppatori personalizzati per visualizzare solo i dati relativi al carico di lavoro che trovano pertinenti. Assicurarsi che il team del carico di lavoro comprenda i tipi di punti dati a cui altri team sono interessati a visualizzare e visualizzare in anteprima i dashboard prima di condividerli per verificare la chiarezza. Fornire dashboard sul carico di lavoro per gli stakeholder è un buon modo per mantenerli soddisfatti dell'integrità del carico di lavoro, ma comporta un rischio di controproducente se gli stakeholder non comprendono chiaramente i dati visualizzati.

Un dashboard valido non visualizza solo le informazioni. Consente inoltre a un analista di porre domande improvvisate su tali informazioni. Alcuni sistemi forniscono strumenti di gestione che l’operatore può utilizzare per completare queste attività ed esplorare i dati sottostanti. Invece, a seconda del repository usato per contenere le informazioni, potrebbe essere possibile eseguire query sui dati direttamente o importarli in strumenti come Excel per ulteriori analisi e report.

Nota

Limitare l'accesso al dashboard al personale autorizzato. Le informazioni sui dashboard potrebbero essere sensibili a livello commerciale. È anche consigliabile proteggere i dati sottostanti per impedire agli utenti di modificarli.

Report

La creazione di report viene usata per generare una visualizzazione complessiva del sistema. Può incorporare dati cronologici e informazioni correnti. I requisiti per la creazione di report sono suddivisi in due categorie ampie: creazione di report operativi e creazione di report di sicurezza.

La creazione di report operativi include in genere quanto segue:

Aggregazione di statistiche che è possibile usare per comprendere l'utilizzo delle risorse del sistema nel suo complesso o di sottosistemi specifici durante un intervallo di tempo specificato.
Identificazione delle tendenze nell'utilizzo delle risorse per l'intero sistema o sottosistemi specifici durante un periodo di tempo specificato.
Monitoraggio delle eccezioni che si sono verificate in tutto il sistema o in sottosistemi specifici in un periodo di tempo specificato.
Determinare l'efficienza dell'applicazione per le risorse distribuite e capire se il volume di risorse e i relativi costi associati possono essere ridotti senza influire inutilmente sulle prestazioni.

La creazione di report sulla sicurezza tiene traccia dell'uso del sistema da parte dei clienti. Può includere:

Controllo delle operazioni eseguite dall'utente. Questa attività richiede la registrazione delle singole richieste completate da ogni utente, insieme a date e ore. I dati devono essere strutturati per consentire a un amministratore di ricostruire rapidamente la sequenza di operazioni completate da un utente durante un periodo specificato.
Rilevamento dell'uso delle risorse per utente. Questa attività richiede la registrazione del modo in cui ogni richiesta da un utente accede alle varie risorse che compongono il sistema e per quanto tempo. Un amministratore può usare questi dati per generare un report di utilizzo, da parte dell'utente, per un periodo specificato, possibilmente per la fatturazione.

In molti casi, i processi batch possono generare report in base a una pianificazione definita. La latenza in genere non costituisce un problema. È anche necessario disporre di processi batch in grado di generare report su base spontanea, in base alle esigenze. Ad esempio, se si archiviano dati in un database relazionale come Azure SQL Database, è possibile usare uno strumento come SQL Server Reporting Services per estrarre e formattare i dati e presentarli come set di report.

Avvisi

Per garantire che il sistema rimanga integro, reattivo e sicuro, impostare avvisi in modo che gli operatori possano rispondere tempestivamente. Un avviso può contenere informazioni contestuali sufficienti per facilitare l'avvio rapido delle attività di diagnostica. Gli avvisi possono essere usati per richiamare funzioni di correzione, ad esempio la scalabilità automatica o altri meccanismi di riparazione automatica. Gli avvisi possono anche abilitare la consapevolezza dei costi fornendo visibilità su budget e limiti.

Consigli

Definire un processo di risposta agli avvisi che ne identifichi i responsabili e le azioni necessarie.
Configurare gli avvisi per un ambito ben definito (tipi e gruppi di risorse) e regolare il livello di dettaglio per ridurre al minimo il rumore.
Usare una soluzione di avviso automatizzata, ad esempio Splunk o Monitoraggio di Azure, invece di richiedere agli utenti di cercare attivamente i problemi.
Usare gli avvisi per rendere operativi i processi di correzione. Ad esempio, creare automaticamente i ticket per tenere traccia di problemi e soluzioni.
Tenere traccia dell'integrità dei servizi della piattaforma cloud nelle aree, comunicare sulle interruzioni, sulle attività di manutenzione pianificata e su altri avvisi di integrità.

Soglie

Gli avvisi vengono generati quando vengono superate le soglie, come rilevato dal sistema di monitoraggio. Assicurarsi che le soglie impostate in genere consentano di implementare le modifiche necessarie al carico di lavoro per evitare la riduzione delle prestazioni o le interruzioni. Ad esempio, impostare la soglia di ridimensionamento automatico per avviare il ridimensionamento prima che uno dei sistemi in esecuzione venga sovraccaricato fino al punto di un'esperienza utente danneggiata. Basare i valori soglia assegnati nell'esperienza precedente nella gestione dell'infrastruttura e convalidarli tramite i test eseguiti come parte delle procedure di test.

Per indicazioni dettagliate sui casi d'uso degli avvisi e altre considerazioni, vedere Progettazione di una strategia di monitoraggio e avviso affidabile.

Facilitazione di Azure

Monitoraggio di Azure è una soluzione di monitoraggio completa per la raccolta, l'analisi e la risposta ai dati di monitoraggio dagli ambienti cloud e locali.
Log Analytics è uno strumento nella portale di Azure che è possibile usare per modificare ed eseguire query di log sui dati nell'area di lavoro Log Analytics.

Se si usano più aree di lavoro, vedere la guida all'architettura dell'area di lavoro Log Analytics per le procedure consigliate.
Application Insights è un'estensione di Monitoraggio di Azure. Fornisce funzionalità di APM.
Informazioni dettagliate su Monitoraggio di Azure sono strumenti di analisi avanzati per tecnologie di Azure specifiche, ad esempio macchine virtuali, servizi app e contenitori. Questi strumenti fanno parte di Monitoraggio di Azure e Log Analytics.
Monitoraggio di Azure per soluzioni SAP è uno strumento di monitoraggio di Azure per gli scenari SAP eseguiti in Azure.
Criteri di Azure consente di applicare gli standard dell'organizzazione e valutare la conformità su larga scala.

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'eccellenza operativa

Fare riferimento al set completo di raccomandazioni.

Elenco di controllo per l'eccellenza operativa

Raccomandazioni per la progettazione e la creazione di un sistema di monitoraggio