Monitorare i componenti della zona di destinazione della piattaforma Azure
Monitorare i componenti della zona di destinazione della piattaforma Azure per garantire disponibilità, affidabilità, sicurezza e scalabilità. Il monitoraggio dei componenti consente all'organizzazione di:
- Rilevare e risolvere tempestivamente i problemi, ottimizzare l'utilizzo delle risorse e risolvere in modo proattivo le minacce alla sicurezza.
- Monitorare continuamente le prestazioni e l'integrità, che consente all'organizzazione di ridurre al minimo i tempi di inattività, ottimizzare i costi e garantire un'operazione efficiente.
- Facilitare la pianificazione della capacità, che consente all'organizzazione di prevedere le esigenze delle risorse e ridimensionare la piattaforma di conseguenza.
Monitorare i servizi della zona di destinazione della piattaforma per mantenere un ambiente stabile e sicuro, ottimizzare le prestazioni e soddisfare in modo efficace le esigenze in continua evoluzione dell'azienda.
Il video seguente illustra la soluzione descritta in questo articolo e illustra come distribuire Monitoraggio di Azure.
Linee guida per il monitoraggio della zona di destinazione di Azure
Gli avvisi relativi alle metriche di base, al log attività e alle query di log sono disponibili per i componenti della piattaforma della zona di destinazione e altri componenti selezionati della zona di destinazione. Questi avvisi garantiscono avvisi e monitoraggio coerenti per la zona di destinazione di Azure. Si basano sulle procedure consigliate da Microsoft per il monitoraggio proattivo, ad esempio la configurazione di avvisi, soglie e notifiche per il rilevamento e la risposta tempestivi dei problemi. Usare le indicazioni seguenti per ottenere visibilità in tempo reale sulle prestazioni, l'utilizzo e la sicurezza dell'implementazione della zona di destinazione della piattaforma. Risolvere in modo proattivo i problemi, ottimizzare l'allocazione delle risorse e garantire un ambiente affidabile e sicuro.
Scaricare un file di Visio di questa architettura.
I subset seguenti dei componenti di Azure hanno uno o più avvisi definiti:
- Azure ExpressRoute
- Firewall di Azure
- Rete virtuale di Azure
- Rete WAN virtuale di Azure
- Area di lavoro Log Analytics di Monitoraggio di Azure
- Zona DNS privato di Azure
- Azure Key Vault
- Macchina virtuale di Azure
- Account di archiviazione di Azure
Per altre informazioni, vedere Dettagli degli avvisi.
Per assicurarsi che le risorse dell'organizzazione siano monitorate e protette correttamente, è anche necessario configurare correttamente gli avvisi e implementare i processi appropriati per rispondere agli avvisi. Configurare i gruppi di azioni con i canali di notifica appropriati e testare gli avvisi per assicurarsi che funzionino come previsto. In conformità al principio di democratizzazione della sottoscrizione di Cloud Adoption Framework, configurare almeno un gruppo di azioni per ogni sottoscrizione in modo che il personale pertinente riceve una notifica degli avvisi. Come forma minima di notifica, il gruppo di azioni deve includere un canale di notifica tramite posta elettronica. Se si usano le regole di elaborazione degli avvisi di Monitoraggio di Azure per instradare gli avvisi a uno o più gruppi di azioni, tenere presente che gli avvisi di integrità dei servizi non supportano le regole di elaborazione degli avvisi. Configurare gli avvisi di integrità dei servizi direttamente con il gruppo di azioni.
In conformità ai principi della zona di destinazione di Azure per la governance basata su criteri, è disponibile una soluzione framework che offre un modo semplice per ridimensionare gli avvisi usando Criteri di Azure. Questi criteri usano l'effetto DeployIfNotExists per distribuire le regole di avviso pertinenti, le regole di elaborazione degli avvisi e i gruppi di azioni quando si crea una risorsa nell'ambiente della zona di destinazione di Azure, sia nei servizi della piattaforma che nelle zone di destinazione.
Criteri di Azure fornisce una configurazione di base predefinita, ma è possibile configurare i criteri in base alle proprie esigenze. Se è necessario inviare avvisi su metriche diverse da quelle fornite dal repository, la soluzione fornisce un framework per sviluppare criteri personalizzati per la distribuzione delle regole di avviso. Per altre informazioni, vedere la guida per i collaboratori degli avvisi di base di Monitoraggio di Azure (AMBA) e Introduzione a una distribuzione di Monitoraggio di Azure. La soluzione è integrata nell'esperienza di installazione della zona di destinazione di Azure, quindi le nuove implementazioni della zona di destinazione di Azure offrono la possibilità di configurare avvisi di base in fase di installazione.
Distribuire avvisi tramite criteri per offrire flessibilità e scalabilità e garantire che gli avvisi vengano distribuiti all'interno e all'esterno dell'ambito della zona di destinazione di Azure. Gli avvisi vengono distribuiti solo quando vengono create le risorse corrispondenti, evitando costi non necessari e garantendo le configurazioni degli avvisi aggiornate in fase di distribuzione. Questa funzione coincide con il principio della zona di destinazione di Azure della governance basata su criteri.
Linee guida per Brownfield
In uno scenario brownfield, l'organizzazione ha un'implementazione esistente della zona di destinazione di Azure o l'organizzazione ha implementato Azure prima che fosse disponibile un'architettura della zona di destinazione di Azure.
Questa sezione descrive i passaggi generali per il monitoraggio della linea di base della zona di destinazione di Azure se si dispone di un footprint di Azure esistente, se allineato alle zone di destinazione di Azure o meno.
Allineato a una zona di destinazione di Azure
Usare questo processo se si dispone di un'implementazione esistente della zona di destinazione di Azure e si vuole usare l'approccio basato su criteri.
- Importare i criteri e le iniziative pertinenti dal repository AMBA.
- Assegnare i criteri necessari nell'ambiente.
- Correggere i criteri non conformi.
Per altre informazioni sui criteri rilevanti per l'ambiente e sui passaggi da applicare, vedere Determinare la gerarchia dei gruppi di gestione.
Non allineato a una zona di destinazione di Azure
Usare questo processo se si dispone di un'implementazione non allineata alla zona di destinazione di Azure e si vuole usare l'approccio basato su criteri.
- Importare i criteri e le iniziative pertinenti dal repository AMBA al gruppo di gestione più importante da cui si desidera assegnare i criteri.
- Assegnare i criteri necessari nell'ambiente.
- Correggere i criteri non conformi.
Per altre informazioni sui criteri rilevanti per l'ambiente e sui passaggi da applicare, vedere Determinare la gerarchia dei gruppi di gestione.
Testare il framework
Testare i criteri e gli avvisi prima di una distribuzione nell'ambiente di produzione in modo da poter:
- Assicurarsi che le risorse dell'organizzazione siano monitorate e protette correttamente.
- Identificare i problemi in anticipo per garantire funzionalità appropriate, ridurre i rischi e migliorare le prestazioni.
- Rilevare e risolvere i problemi prima che diventino più grandi. Evitare falsi positivi o negativi e ridurre il rischio di errori costosi.
- Ottimizzare le configurazioni per migliorare le prestazioni ed evitare problemi correlati alle prestazioni nell'ambiente di produzione.
Il test consente di assicurarsi che le configurazioni di avvisi e criteri soddisfino i requisiti dell'organizzazione e siano conformi alle normative e agli standard. Con le normative in vigore, è possibile evitare violazioni della sicurezza, violazioni della conformità e altri rischi che possono avere conseguenze per l'organizzazione.
Il test è un passaggio essenziale nello sviluppo e nella distribuzione di configurazioni di avvisi e criteri e consente di garantire la sicurezza, l'affidabilità e le prestazioni delle risorse dell'organizzazione.
Per altre informazioni, vedere Test dell'approccio per le zone di destinazione di Azure.
Nota
Se si implementa l'invio di avvisi usando un approccio diverso, ad esempio l'infrastruttura come codice (IaC), ad esempio Azure Resource Manager, Bicep o Terraform o tramite il portale, le indicazioni per avvisi, gravità e soglie presenti nel repository si applicano ancora per determinare le regole di avviso da configurare e per le notifiche.