Procedure consigliate per la creazione e la gestione delle regole di raccolta dati in Monitoraggio di Azure
Le regole di raccolta dati determinano come raccogliere ed elaborare i dati di telemetria inviati ad Azure. Alcune regole di raccolta dati verranno create e gestite da Monitoraggio di Azure, mentre è possibile crearne altre per personalizzare la raccolta dati in base a requisiti specifici. Questo articolo illustra alcune procedure consigliate da applicare durante la creazione di controller di dominio personalizzati.
Quando si crea un record di controllo di dominio, è necessario considerare alcuni aspetti, ad esempio:
- Tipo di dati che verranno raccolti, noto anche come tipo di origine dati (prestazioni, eventi)
- Il Macchine virtuali di destinazione a cui verrà associato il DCR
- Destinazione dei dati raccolti
Prendere in considerazione tutti questi fattori è fondamentale per una buona organizzazione DCR. Tutti i punti precedenti influisce 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 controller di dominio 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 dai Amministrazione IT. È anche possibile creare ambiti simili dedicati a diversi ambienti ("Sviluppo", "Test", "Produzione") per specializzarsi ancora di più.
In effetti, non è ideale e nemmeno non è consigliabile 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 | Procedure consigliate | Spiegazione | Area di impatto |
|---|---|---|---|
| Raccolta di dati | Definire l'ambito di osservabilità | La definizione dell'ambito di osservabilità è fondamentale per una gestione DCR semplificata e corretta e l'ambito di osservabilità dell'organizzazione. Consentirà 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 record di dominio 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, ma richiederà anche un maggiore sforzo quando è necessario aggiornare la configurazione di DCR. Pensare alla gestione di un modello che include voci non necessarie; questa situazione è minore dell'ideale e lascia spazio agli errori. | |
| Creare record di controllo di dominio specifici 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 record di controllo di dominio 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 Registro Azure Container. In questo caso, le macchine virtuali verranno forzate a elaborare ed eseguire una configurazione non necessaria in base al software installato. | Se non si usano controller di dominio diversi, ogni macchina virtuale associata verrà trasferita, elaborata ed eseguita 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. Inoltre, la raccolta di dati non necessari aumenterà i costi di inserimento dei dati. | |
| Destinazione dati | Creare record di dominio diversi in base alla destinazione | I controller di dominio 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 record 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 | La mancata separazione dei controller di dominio in base alla destinazione dei dati potrebbe comportare la mancata conformità con la gestione dei dati, la privacy e i requisiti di accesso e potrebbe rendere superflua la raccolta dei dati con costi imprevisti. |
I principi menzionati 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 controller di dominio richiedono anche la governance condivisa, per ridurre al minimo sia la creazione di silo che la duplicazione non necessaria del lavoro.