Condividi tramite

Procedure consigliate per l'eccellenza operativa in Monitoraggio di Azure

  • Articolo

L'eccellenza operativa si riferisce ai processi operativi necessari per mantenere un servizio in esecuzione in modo affidabile nell'ambiente di produzione. Usare le informazioni seguenti per ridurre al minimo i requisiti operativi del monitoraggio delle macchine virtuali.

Questo articolo descrive l’eccellenza operativa per Monitoraggio di Azure Monitor come parte di Well-Architected Framework di Azure. Azure Well-Architected Framework è una serie di principi guida utilizzabili per migliorare la qualità dei carichi di lavoro. Il framework è costituito da cinque pilastri di eccellenza dell'architettura:

  • Affidabilità
  • Sicurezza
  • Ottimizzazione dei costi
  • Eccellenza operativa
  • Efficienza delle prestazioni

Log di Monitoraggio di Azure

Elenco di controllo della progettazione

  • Progettare un'architettura dell'area di lavoro con il numero minimo di aree di lavoro per soddisfare i requisiti aziendali.
  • Usare Infrastructure as Code (IaC) quando si gestiscono più aree di lavoro.
  • Usare le informazioni dettagliate sull'area di lavoro Log Analytics per tenere traccia dell'integrità e delle prestazioni delle aree di lavoro Log Analytics.
  • Creare regole di avviso per ricevere notifiche proattive sui problemi operativi nell'area di lavoro.
  • Assicurarsi di disporre di un processo operativo ben definito per la separazione dei dati.

Raccomandazioni per la configurazione

Elemento consigliato Vantaggio
Progettare una strategia dell'area di lavoro per soddisfare i requisiti aziendali. Vedere Progettare un'architettura dell'area di lavoro Log Analytics per indicazioni sulla progettazione di una strategia per le aree di lavoro Log Analytics, tra cui quante crearne e dove inserirle.

Una singola area di lavoro o almeno un numero minimo di aree di lavoro ottimizzano l'efficienza operativa perché limitano la distribuzione dei dati operativi e di sicurezza, aumentando la visibilità su potenziali problemi, semplificando l'identificazione dei modelli e riducendo al minimo i requisiti di manutenzione.

Potrebbero essere previsti requisiti per più aree di lavoro, ad esempio più tenant, oppure potrebbero essere necessarie aree di lavoro in più aree per supportare i requisiti di disponibilità. In questi casi, assicurarsi di disporre di processi appropriati per gestire questa maggiore complessità.
Usare Infrastructure as Code (IaC) quando si gestiscono più aree di lavoro. Usare Infrastructure as Code (IaC) per definire i dettagli delle aree di lavoro in ARM, BICEPo Terraform. In questo modo è possibile sfruttare i processi DevOps esistenti per distribuire nuove aree di lavoro e Criteri di Azure per applicare la configurazione.
Usare le informazioni dettagliate sull'area di lavoro Log Analytics per tenere traccia dell'integrità e delle prestazioni delle aree di lavoro Log Analytics. Le informazioni dettagliate sull'area di lavoro Log Analytics offrono una visualizzazione unificata dell'utilizzo, delle prestazioni, dell'integrità, degli agenti, delle query e del log delle modifiche per tutte le aree di lavoro. Esaminare queste informazioni a intervalli regolari per tenere traccia dell'integrità e del funzionamento di ognuna delle aree di lavoro.
Creare regole di avviso per ricevere notifiche proattive sui problemi operativi nell'area di lavoro. Ogni area di lavoro include una tabella delle operazioni che registra attività importanti che interessano l'area di lavoro. Creare regole di avviso basate su questa tabella per ricevere una notifica proattiva quando si verifica un problema operativo. È possibile usare gli avvisi consigliati per l'area di lavoro per semplificare la creazione delle regole di avviso più critiche.
Assicurarsi di disporre di un processo operativo ben definito per la separazione dei dati. Potrebbero essere previsti requisiti diversi per i diversi tipi di dati archiviati nell'area di lavoro. Assicurarsi di comprendere chiaramente tali requisiti, ad esempio la conservazione dei dati e la sicurezza quando si progetta la strategia dell'area di lavoro e si configurano impostazioni come le autorizzazioni e la conservazione a lungo termine. È inoltre necessario disporre di un processo chiaramente definito per l'eliminazione occasionale dei dati con informazioni personali raccolti accidentalmente.

Avvisi

Elenco di controllo della progettazione

  • Usare soglie dinamiche nelle regole di avviso delle metriche, se appropriato.
  • Quando possibile, usare una regola di avviso per monitorare più risorse.
  • Per controllare il comportamento su larga scala, usare le regole di elaborazione degli avvisi.
  • Sfruttare le proprietà personalizzate per migliorare la diagnostica
  • Sfruttare le app per la logica per personalizzare, arricchire e integrare con un'ampia gamma di sistemi

Raccomandazioni per la configurazione

Elemento consigliato Vantaggio
Usare soglie dinamiche nelle regole di avviso delle metriche, se appropriato. È possibile che non si sia certi dei numeri corretti da usare come soglie per le regole di avviso. Le soglie dinamiche usano l'apprendimento automatico e usano un set di algoritmi e metodi per determinare le soglie corrette in base alle tendenze, quindi non è necessario conoscere la soglia predefinita corretta in anticipo. Le soglie dinamiche sono utili anche per le regole che monitorano più risorse e quando non è possibile configurare una singola soglia per tutte le risorse. Vedere Soglie dinamiche negli avvisi delle metriche.
Quando possibile, usare una regola di avviso per monitorare più risorse. L'uso di regole di avviso che monitorano più risorse riduce il sovraccarico di gestione, consentendo di gestire una regola per monitorare un numero elevato di risorse.
Per controllare il comportamento su larga scala, usare le regole di elaborazione degli avvisi. Le regole di elaborazione degli avvisi possono essere usate per ridurre il numero di regole di avviso da creare e gestire.
Usare proprietà personalizzate per migliorare la diagnostica. Se la regola di avviso usa gruppi di azioni, è possibile aggiungere proprietà personalizzate da includere nel payload della notifica di avviso. È possibile usare queste proprietà nelle azioni chiamate dal gruppo di azioni, ad esempio da un webhook, una funzione di Azure o azioni dell'app per la logica.
Usare App per la logica per personalizzare il flusso di lavoro di notifica e integrarsi con vari sistemi. È possibile usare App per la logica di Azure per creare e personalizzare i flussi di lavoro per l'integrazione. Usare App per la logica per personalizzare le notifiche degli avvisi. È possibile:
- Personalizzare l'e-mail degli avvisi usando il proprio oggetto e il formato del corpo dell'e-mail.
- Personalizzare i metadati dell'avviso cercando i tag per le risorse interessate o recuperando un risultato della ricerca di query di log.
- Eseguire l'integrazione con i servizi esterni usando connettori esistenti come Outlook, Microsoft Teams, Slack e PagerDuty. È anche possibile configurare l'app per la logica per i propri servizi.

Macchine virtuali

Elenco di controllo della progettazione

  • Eseguire la migrazione dagli agenti legacy all'agente di Monitoraggio di Azure.
  • Usare Azure Arc per monitorare le macchine virtuali all'esterno di Azure.
  • Usare Criteri di Azure per distribuire agenti e assegnare regole di raccolta dati.
  • Definire una strategia per la struttura delle regole di raccolta dati.
  • Prendere in considerazione la migrazione dei Management Pack client System Center Operations Manager (SCOM) al Monitoraggio di Azure.

Raccomandazioni per la configurazione

Suggerimento Descrizione
Eseguire la migrazione dagli agenti legacy all'agente di Monitoraggio di Azure. L'agente di Monitoraggio di Azure è più semplice da gestire rispetto all'agente di Log Analytics legacy e consente una maggiore flessibilità di Progettazione dell'area di lavoro Log Analytics. Sia gli agenti Windows, sia Linux, consentono il multihoming, ciò significa che possono connettersi a più aree di lavoro. Le regole di raccolta dati consentono di gestire le impostazioni di raccolta dati su larga scala e di definire configurazioni univoche e con ambito per subset di computer. Per considerazioni e per i metodi di migrazione, vedere Eseguire la migrazione all'agente di Monitoraggio di Azure dall'agente di Log Analytics.
Usare Azure Arc per monitorare le macchine virtuali all'esterno di Azure. Azure Arc per server consente di gestire i server fisici e le macchine virtuali ospitate all'esterno di Azure, nella rete aziendale o in un altro provider di servizi cloud. Se è presente l'Agente di Azure Connected Machine, è possibile distribuire l'agente di Monitoraggio di Azure in queste VM usando lo stesso metodo che si esegue per le VM di Azure, quindi monitorare l'intera raccolta di macchine virtuali usando gli stessi strumenti di Monitoraggio di Azure.
Usare Criteri di Azure per distribuire agenti e assegnare regole di raccolta dati. Criteri di Azure consente di distribuire automaticamente gli agenti in set di macchine virtuali esistenti ed eventuali nuove macchine virtuali create. In questo modo tutte le VM vengono monitorate con un intervento minimo da parte degli amministratori. Se si usano informazioni dettagliate sulle VM, vedere Abilitare le informazioni dettagliate sulle macchine virtuali con Criteri di Azure. Per gestire l'agente di Monitoraggio di Azure senza informazioni dettagliate sulle macchine virtuali, vedere Abilitare l'agente di Monitoraggio di Azure usando Criteri di Azure. Vedere [Gestire le associazioni delle regole di raccolta dati in Monitoraggio di Azure](.. /essentials/data-collection-rule-associations.md#create-new-association per un modello per creare un'associazione di regole di raccolta dati.
Definire una strategia per la struttura delle regole di raccolta dati. Le regole di raccolta dati definiscono i dati da raccogliere dalle macchine virtuali con l'agente di Monitoraggio di Azure oltre che dove inviare tali dati. Ogni DCR può includere più scenari di raccolta ed essere associato a un numero qualsiasi di macchine virtuali. Definire una strategia per configurare i DCR in modo tale che raccolgano solo i dati necessari per diversi gruppi di macchine virtuali, riducendo al minimo il numero di DCR richiesti per la gestione.
Prendere in considerazione la migrazione dei Management Pack client SCOM al Monitoraggio di Azure. Se si dispone di un ambiente SCOM esistente per il monitoraggio dei carichi di lavoro client, si potrebbe eseguire la migrazione di una quantità sufficiente della logica del Management Pack a Monitoraggio di Azure, per consentire di ritirare l'ambiente SCOM o almeno di ritirare determinati Management Pack. Vedere Eseguire la migrazione da System Center Operations Manager (SCOM) a Monitoraggio di Azure.

Contenitori

Elenco di controllo della progettazione

  • Esaminare le indicazioni per il monitoraggio di tutti i livelli dell'ambiente Kubernetes.
  • Usare Kubernetes abilitato per Azure Arc per monitorare i cluster all'esterno di Azure.
  • Usare i servizi gestiti di Azure per gli strumenti nativi del cloud.
  • Integrare i cluster del servizio Azure Kubernetes agli strumenti di monitoraggio esistenti.
  • Usare Criteri di Azure per abilitare la raccolta dati dal cluster Kubernetes.

Raccomandazioni per la configurazione

Elemento consigliato Vantaggio
Esaminare le indicazioni per il monitoraggio di tutti i livelli dell'ambiente Kubernetes. Monitorare le prestazioni del cluster Kubernetes con informazioni dettagliate sui contenitori include indicazioni e procedure consigliate per il monitoraggio dell'intero ambiente Kubernetes dai livelli di rete, cluster e applicazione.
Usare Kubernetes abilitato per Azure Arc per monitorare i cluster all'esterno di Azure. Kubernetes abilitato per Azure Arc consente di monitorare i cluster Kubernetes in esecuzione in altri cloud usando gli stessi strumenti dei cluster del servizio Azure Kubernetes, tra cui Informazioni dettagliate sui contenitori e il servizio gestito di Monitoraggio di Azure per Prometheus.
Usare i servizi gestiti di Azure per gli strumenti nativi del cloud. Servizio gestito di Monitoraggio di Azure per Prometheus e Grafana gestito di Azure supporta tutte le funzionalità degli strumenti nativi del cloud Prometheus e Grafana senza dover gestire l'infrastruttura sottostante. È possibile effettuare rapidamente il provisioning di questi strumenti ed eseguire l'onboarding dei cluster Kubernetes con un sovraccarico minimo. Questi servizi consentono di accedere a una vasta libreria di regole e dashboard della community per monitorare l'ambiente Kubernetes.
Integrare i cluster del servizio Azure Kubernetes agli strumenti di monitoraggio esistenti. Se si dispone di un investimento esistente in Prometheus e Grafana, integrare i cluster del servizio Azure Kubernetes e i servizi gestiti di Azure nell'ambiente esistente usando le indicazioni contenute in Monitorare i cluster Kubernetes usando i servizi di Azure e gli strumenti nativi del cloud.
Usare Criteri di Azure per abilitare la raccolta dati dal cluster Kubernetes. Usare Criteri di Azure per abilitare la raccolta dei dati e le metriche di Prometheus, Informazioni dettagliate contenitore e Impostazioni di diagnostica. In questo modo, tutti i nuovi cluster vengono monitorati automaticamente e applicano la propria configurazione di monitoraggio.

Passaggio successivo