Bonnes pratiques opérationnelles

Ce qu’il faut bien faire avant de laisser une conversion de journal DNS s’exécuter sans surveillance sur des contrôleurs de domaine en production.

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

Convertir un journal à la main est facile. Le faire tourner chaque nuit sur chaque contrôleur de domaine, pendant des années, sans que personne ne le regarde, c’est la partie qui demande un peu de conception. Voici les points qui comptent en pratique.

1. Convertir les journaux archivés, pas celui en cours

Activez la rotation des journaux sur le serveur DNS et ne convertissez que les fichiers fermés. Le module peut lire le journal sur lequel le serveur DNS écrit actuellement, mais ce fichier change pendant la conversion : les entrées les plus récentes peuvent manquer et le dernier enregistrement peut être tronqué. Deux exécutions produisent deux résultats différents.

Le modèle standard ignore le fichier le plus récent :

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

Compromis à garder en tête : sur un serveur à faible volume, la rotation peut prendre plus d’un jour, donc les données du jour en cours restent non converties jusqu’à la rotation du fichier. Ajustez le seuil de rotation en conséquence.

2. Planifiez-le, et donnez au travail une identité qui fonctionne

Le Planificateur de tâches est l’endroit habituel — une exécution quotidienne est un bon choix par défaut. Une implémentation complète via GPO pour les contrôleurs de domaine est documentée dans l’exemple de collecte pilotée par GPO, et une tâche autonome dans l’exemple de tâche planifiée.

Trois pièges courants :

  • Découverte du module. Une tâche exécutée en tant que SYSTEM avec -NoProfile ne voit que les chemins de modules machine-wide. Installez le module pour toute la machine, ou ajoutez un Import-Module explicite dans l’action de la tâche.
  • Culture. Le compte qui exécute la tâche peut ne pas avoir la locale avec laquelle vous avez testé en interactif. Spécifiez explicitement -InputCulture et -OutputCulture au lieu de compter sur la valeur par défaut.
  • Accès réseau. Si la source ou la destination est un chemin UNC, SYSTEM s’authentifie en tant que compte ordinateur. Accordez les droits de partage et NTFS au compte ordinateur (ou au groupe Domain Controllers), ou exécutez la tâche avec un compte de service dédié.

3. Faites tourner la rotation à une taille que vous pouvez traiter

50 à 200 Mo par fichier maintiennent les conversions prévisibles et permettent à un travail nocturne de finir dans sa fenêtre. Un fichier qui grandit sans fin ne le permet pas. Voir Performance.

4. Validez les premiers résultats avant d’automatiser

Lancez la conversion manuellement sur deux ou trois vrais journaux et ouvrez vraiment le CSV :

  • Les horodatages sont-ils corrects — pas d’inversion jour/mois ? (Si oui, définissez -InputCulture.)
  • Le délimiteur correspond-il à ce que votre consommateur attend ?
  • Le champ ComputerName est-il rempli ?
  • Les contextes dont vous avez besoin sont-ils présents, et ceux dont vous n’avez pas besoin sont-ils filtrés ?

-WhatIf vous montre quels fichiers un lot toucherait avant de les toucher :

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

5. Décidez ce qu’il advient des journaux traités

Un travail qui convertit simplement « tous les journaux sauf le plus récent » retraitera les mêmes fichiers chaque nuit. C’est robuste et simple, mais cela écrase les sorties et peut injecter des lignes dupliquées dans ce qui les ingère.

Choisissez une option :

  • déplacer les fichiers .log traités dans un dossier d’archive
  • les supprimer avec -RemoveSourceFile une fois que vous avez confiance dans la chaîne
  • faire dédupliquer le collecteur en aval

Quelle que soit votre décision, notez-la — c’est ce détail qui embrouille le prochain administrateur.

6. Planifiez le stockage et la rétention

La compression (-CompressOutput) réduit généralement le CSV de 90 % ou plus, mais le volume s’accumule quand même. Estimez à partir de votre taux de requêtes réel et de votre obligation de rétention, et fixez une date de fin pour les données au lieu de les laisser croître indéfiniment.

-OutputType Statistic mérite d’être envisagé pour une rétention longue : les agrégats quotidiens sont minuscules et répondent souvent aux questions de tendance pour lesquelles les données détaillées anciennes étaient conservées.

7. Traitez la sortie comme sensible

Les journaux DNS analysés décrivent votre structure de noms interne et qui a cherché quoi. C’est plus révélateur que la plupart des journaux d’infrastructure, et selon votre juridiction cela peut être considéré comme des données personnelles.

  • Restreignez les permissions NTFS et de partage sur les dossiers de sortie.
  • Ne déposez pas les CSV sur un partage de fichiers généraliste « temporairement ».
  • Incluez les données des journaux DNS dans votre politique de rétention et de suppression, pas seulement dans votre politique de sauvegarde.
  • La sortie compressée est plus petite, pas protégée — utilisez le chiffrement ou le contrôle d’accès là où c’est important.

8. Gardez la validation d’en-tête activée

La vérification par défaut qu’un fichier est bien un journal de débogage DNS ne coûte rien et évite qu’un chemin mal tapé produise des milliers de lignes absurdes. Utilisez -SkipHeaderValidation uniquement pour des formats vraiment inhabituels — et notez que la commande refuse de le combiner avec -RemoveSourceFile pour cette raison précise.

9. Surveillez le travail, pas seulement le serveur

Une conversion sans surveillance qui s’arrête silencieusement est pire qu’aucune conversion, car le trou n’est remarqué que lorsqu’on a besoin des données.

  • Surveillez la sortie d’erreur non nulle ; l’implémentation de référence GPO lance volontairement une erreur quand $Error.Count -gt 0 pour que la tâche signale un échec.
  • Alertez sur le dernier code de résultat de la tâche planifiée, pas seulement sur son existence.
  • Vérifiez que les fichiers de sortie apparaissent bien avec des horodatages récents.
  • Surveillez l’espace disque libre sur le volume des journaux et sur la cible de sortie.

Les causes courantes d’échec — accès refusé, journaux corrompus, en-têtes invalides — sont couvertes dans Dépannage.

10. Documentez le flux de travail

Où les journaux sont écrits, quand le travail s’exécute, quels paramètres sont utilisés, où la sortie va, qui la consomme, et combien de temps elle est conservée. Six lignes dans votre wiki opérationnel. C’est ce qui rend la configuration auditable et transmissible.