Procedure consigliate per la creazione e la gestione delle regole di raccolta dati in Monitoraggio di Azure
Le regole di raccolta dati (DCR) determinano come raccogliere ed elaborare i dati di telemetria inviati ad Azure. Alcune regole di raccolta dati vengono create e gestite da Monitoraggio di Azure, mentre è possibile creare altre per personalizzare la raccolta dati per i requisiti specifici. Questo articolo illustra alcune procedure consigliate da applicare durante la creazione di DCR personalizzati.
Quando si crea un DCR, è necessario considerare alcuni aspetti, ad esempio:
- Tipo di dati raccolti, noto anche come tipo di origine dati (prestazioni, eventi)
- Il Macchine virtuali di destinazione a cui è associato il Registro Azure Container
- La destinazione dei dati raccolti
Prendere in considerazione tutti questi fattori è fondamentale per una buona organizzazione DCR. Tutti i punti precedenti influiscono sul lavoro di gestione DCR e sul consumo di risorse per il trasferimento e l'elaborazione della configurazione.
Data la granularità nativa, che consente a un determinato DCR di essere associato a più di una macchina virtuale di destinazione e viceversa, è importante mantenere i controller di dominio il più semplici possibile usando meno origini dati ognuna. È anche importante mantenere l'elenco degli elementi raccolti in ogni origine dati snella e orientata all'ambito di osservabilità.
Per chiarire cosa potrebbe essere un ambito di osservabilità, considerarlo come limite logico preferito per la raccolta dei dati. Ad esempio, un possibile ambito può essere un set di macchine virtuali che eseguono software (ad esempio, SQL Server) necessari per un'applicazione specifica o contatori o eventi del sistema operativo di base impostati dagli amministratori IT. È anche possibile creare ambiti simili dedicati a diversi ambienti (Sviluppo, Test, Produzione) per specializzarsi ancora di più.
Infatti, non è ideale e nemmeno sconsigliato creare un singolo record di dominio contenente tutte le origini dati, gli elementi di raccolta e le destinazioni per implementare l'osservabilità. Nella tabella seguente sono disponibili diversi consigli utili per pianificare meglio la creazione e la manutenzione di DCR:
| Categoria | Procedura consigliata | Spiegazione | Area di impatto |
|---|---|---|---|
| Raccolta dati | Definire l'ambito di osservabilità. | La definizione dell'ambito di osservabilità è fondamentale per una gestione DCR semplificata e corretta e per l'ambito di osservabilità dell'organizzazione. Consente di chiarire qual è la necessità della raccolta e da quale macchina virtuale di destinazione deve essere eseguita. Come spiegato in precedenza, un ambito di osservabilità potrebbe essere un set di macchine virtuali che eseguono software comuni a un'applicazione specifica, un set di informazioni comuni per il reparto IT e così via. Ad esempio, la raccolta dei contatori delle prestazioni di base del sistema operativo, ad esempio l'utilizzo della CPU, la memoria disponibile e lo spazio libero su disco, può essere considerato un ambito per la gestione IT centrale. | Non avere un ambito chiaramente definito non offre chiarezza e non consente una gestione corretta. |
| Creare controller di dominio specifici per l'ambito di osservabilità. | La creazione di controller di dominio separati in base all'ambito di osservabilità è fondamentale per semplificare la manutenzione. Consente di associare facilmente i controller di dominio alle macchine virtuali di destinazione pertinenti. | Perché creare un singolo DCR che raccoglie i contatori delle prestazioni del sistema operativo più contatori del server Web e contatori di database tutti insieme? Questo approccio non solo forza ogni macchina virtuale associata a trasferire, elaborare ed eseguire la configurazione esterna all'ambito. Richiede anche un maggiore impegno quando è necessario aggiornare la configurazione del Registro Azure Container. Pensare alla gestione di un modello che include voci non necessarie; questa situazione è inferiore all'ideale e lascia spazio agli errori. | |
| Creare un record di controllo di dominio specifico per il tipo di origine dati all'interno degli ambiti di osservabilità definiti. | La creazione di controller di dominio separati per le prestazioni e gli eventi consente di gestire la configurazione e l'associazione con granularità in base ai computer di destinazione. Ad esempio, la creazione di un DCR per raccogliere sia gli eventi che i contatori delle prestazioni potrebbe comportare un approccio non ottimale. Potrebbero verificarsi situazioni in cui un determinato computer (o set di computer) non dispone dei registri eventi o dei contatori delle prestazioni configurati nel DCR. In questo caso, le macchine virtuali sono costrette a elaborare ed eseguire una configurazione non necessaria in base al software installato. | Non usando controller di dominio diversi forza ogni macchina virtuale associata a trasferire, elaborare ed eseguire la configurazione che potrebbe non essere applicabile in base al software installato. Un utilizzo eccessivo delle risorse di calcolo e errori nella configurazione di elaborazione potrebbe causare la mancata risposta dell'agente di Monitoraggio di Azure (AMA). Inoltre, la raccolta di dati non necessari aumenta i costi di inserimento dei dati. | |
| Destinazione dei dati | Creare record di dominio diversi in base alla destinazione. | I DCR hanno la possibilità di inviare dati a più destinazioni diverse, ad esempio metriche di Monitoraggio di Azure e log di Monitoraggio di Azure, contemporaneamente. La presenza di controller di dominio specifici per la destinazione è utile per la gestione dei requisiti di legge o sovranità dei dati. Poiché la conformità potrebbe richiedere l'invio di dati solo ai repository consentiti creati in aree consentite, la presenza di controller di dominio diversi consente una destinazione granulare migliore. | Se non si separano controller di dominio in base alla destinazione dei dati, questo può causare la mancata conformità con i requisiti di gestione, privacy e accesso dei dati. Può anche comportare una raccolta di dati non necessaria, causando costi imprevisti. |
I principi indicati in precedenza forniscono una base per la creazione di un approccio di gestione DCR personalizzato che bilancia la gestibilità, la facilità di riutilizzo, la granularità e i limiti dei servizi. I DCR richiedono anche la governance condivisa, per ridurre al minimo sia la creazione di silo che la duplicazione non necessaria del lavoro.