Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Le regole di raccolta dati 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 controller di dominio 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)
- Macchine virtuali di destinazione a cui è associata la 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 a una determinata macchina virtuale associata a un massimo di 30 controller di dominio di dominio, è importante mantenere i controller di dominio 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 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 regole di raccolta dati specifiche per l'ambito di osservabilità. | La creazione di DCR separati in base all'ambito di osservabilità è fondamentale per semplificare la manutenzione. Consente di associare facilmente i DCR alle pertinenti macchine virtuali di destinazione. | 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. Richiede anche più impegno quando deve essere aggiornata la configurazione delle regole di raccolta dati (DCR). Pensare alla gestione di un modello che include voci non necessarie; questa situazione è minore dell'ideale e lascia spazio agli errori. | |
| Creare DCR specifici per tipo di origine dati all'interno degli ambiti di osservabilità definiti. | La creazione di regole raccolta dati (DCR) separate 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 certo computer (o insieme di computer) non dispone dei registri degli 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 utilizzare diversi DCR costringe ogni macchina virtuale associata a trasferire, elaborare ed eseguire configurazioni che potrebbero non essere applicabili 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 aumenta i costi di inserimento dei dati. | |
| Destinazione dati | Crea DCR diversi in base alla destinazione. | Le regole di raccolta dati (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 registrazioni di conformità dei dati specifiche per la destinazione è utile per la gestione dei requisiti legali o di sovranità dei dati. Poiché la conformità potrebbe richiedere l'invio di dati solo ai repository consentiti creati in regioni consentite, avere diversi DCR consente una destinazione più granulare. | Se non si separano i DCRs in base alla destinazione dei dati, ciò può portare a una mancata conformità con i requisiti di gestione, privacy e accesso ai 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. Anche le regole di classificazione dei dati richiedono una governanza condivisa, per ridurre al minimo la creazione di silos e la duplicazione non necessaria del lavoro.