Pratiche Operative Consigliate

Cosa fare bene prima di lasciare che una conversione di log DNS venga eseguita in modo automatico sui controller di dominio di produzione.

For AI agents: a documentation index is available at /llms.txt; a markdown version of this page is available at /it/docs/06-operational-best-practices/index.md.

Convertire un log manualmente è facile. Farlo ogni notte su ogni controller di dominio, per anni, senza che nessuno lo controlli, è la parte che richiede un po’ di progettazione. Questi sono i punti che contano nella pratica.

1. Converti i log ruotati, non quello attivo

Abilita il rollover dei log sul server DNS e converti solo i file chiusi. Il modulo può leggere il log su cui il DNS Server sta attualmente scrivendo, ma quel file cambia durante la conversione: le voci più recenti potrebbero mancare e l’ultima riga potrebbe essere troncata. Due esecuzioni producono due risultati diversi.

Lo schema standard salta il file più recente:

Get-ChildItem "C:\Administration\Logs\DNSServer\*.log" |
    Sort-Object LastWriteTime -Descending |
    Select-Object -Skip 1 |
    Convert-DNSDebugLogFile -ComputerName $env:COMPUTERNAME

Un compromesso da tenere a mente: su un server a basso volume, il rollover può richiedere più di un giorno, quindi i dati del giorno corrente restano non convertiti finché il file non ruota. Dimensiona la soglia di rollover di conseguenza.

2. Pianificalo e assegna al job un’identità che funzioni

Task Scheduler è la soluzione abituale — una frequenza giornaliera è un buon default. Un’implementazione completa tramite Group Policy per i controller di dominio è documentata nell’esempio di raccolta guidata da GPO, e un task standalone nell’esempio di Scheduled Task.

Tre cose creano problemi qui:

  • Rilevamento del modulo. Un task che gira come SYSTEM con -NoProfile vede solo i percorsi dei moduli a livello macchina. Installa il modulo a livello macchina o aggiungi un Import-Module esplicito all’azione del task.
  • Localizzazione. L’account che esegue il task potrebbe non avere la stessa localizzazione con cui hai testato interattivamente. Imposta esplicitamente -InputCulture e -OutputCulture invece di affidarti al default.
  • Accesso di rete. Se la sorgente o la destinazione è un percorso UNC, SYSTEM si autentica come account computer. Concedi i permessi di condivisione e NTFS all’account computer (o al gruppo Domain Controllers), oppure esegui il task con un account di servizio dedicato.

3. Ruota a una dimensione che puoi gestire

50–200 MB per file mantiene le conversioni prevedibili e permette a un job notturno di finire entro la finestra prevista. Un file che cresce all’infinito alla fine non ce la fa. Vedi Performance.

4. Valida i primi output prima di automatizzare

Esegui la conversione manualmente su due o tre log reali e apri effettivamente il CSV:

  • Le timestamp sono corrette — non invertite giorno/mese? (Se lo sono, imposta -InputCulture.)
  • Il delimitatore corrisponde a quello che il tuo consumatore si aspetta?
  • ComputerName è valorizzato?
  • I contesti di cui hai bisogno sono presenti, e quelli inutili filtrati?

-WhatIf ti mostra quali file un batch toccherebbe prima di toccarli:

Get-ChildItem "C:\Administration\Logs\DNSServer\*.log" |
    Convert-DNSDebugLogFile -RemoveSourceFile -WhatIf

5. Decidi cosa fare con i log processati

Un job che semplicemente converte “tutti i log tranne il più recente” rielaborerà gli stessi file ogni notte. È robusto e semplice, ma sovrascrive gli output e può inserire righe duplicate in chi li consuma.

Scegli una delle seguenti opzioni:

  • sposta i file .log processati in una cartella di archivio
  • cancellali con -RemoveSourceFile una volta che ti fidi della pipeline
  • fai deduplicare il collector a valle

Qualunque scelta tu faccia, annotala — è il dettaglio che confonde il prossimo amministratore.

6. Pianifica spazio e conservazione

La compressione (-CompressOutput) di solito riduce il CSV del 90% o più, ma il volume si accumula comunque. Stima in base al tuo reale tasso di query e all’obbligo di conservazione, e imposta una data di fine per i dati invece di lasciarli crescere indefinitamente.

-OutputType Statistic vale la pena considerarlo per conservazioni lunghe: i rollup giornalieri sono piccoli e spesso rispondono alle domande di trend per cui si tenevano i dati a livello di riga.

7. Tratta l’output come sensibile

I log DNS analizzati descrivono la tua struttura interna dei nomi e chi ha cercato cosa. Questo è più rivelatore della maggior parte dei log infrastrutturali e, a seconda della tua giurisdizione, può essere considerato dato personale.

  • Limita i permessi NTFS e di condivisione sulle cartelle di output.
  • Non lasciare i CSV su una condivisione generica “temporaneamente”.
  • Includi i dati dei log DNS nella tua policy di conservazione e cancellazione, non solo nella policy di backup.
  • L’output compresso è più piccolo, non protetto — usa crittografia o controllo accessi dove serve.

8. Mantieni attiva la validazione dell’intestazione

Il controllo predefinito che verifica che un file sia davvero un log di debug DNS non costa nulla e previene che un percorso digitato male produca migliaia di righe senza senso. Usa -SkipHeaderValidation solo per formati davvero insoliti — e nota che il comando rifiuta di combinarlo con -RemoveSourceFile proprio per questo motivo.

9. Monitora il job, non solo il server

Una conversione non sorvegliata che si ferma silenziosamente è peggio di nessuna conversione, perché il gap si nota solo quando qualcuno ha bisogno dei dati.

  • Controlla l’output di errore non nullo; l’implementazione di riferimento GPO genera un errore quando $Error.Count -gt 0 così il task segnala il fallimento.
  • Allerta sul codice risultato dell’ultimo task schedulato, non solo sull’esistenza del task.
  • Verifica che i file di output compaiano effettivamente con timestamp recenti.
  • Controlla lo spazio libero su disco sia sul volume dei log che sulla destinazione di output.

Cause comuni di un’esecuzione fallita — accesso negato, log corrotti, intestazioni non valide — sono trattate in Troubleshooting.

10. Documenta il flusso di lavoro

Dove vengono scritti i log, quando gira il job, quali parametri usa, dove va l’output, chi lo consuma e per quanto tempo viene conservato. Sei righe nella tua wiki operativa. È ciò che rende la configurazione verificabile e trasferibile.