v1.3.3Version stable

Version stable v1.3.3

Migration du journal

Depuis la 0.0.78, audit-migrate valide les archives et peut produire une copie au schéma 2 avec sauvegarde des originaux. La simulation est le mode par défaut ; le journal de l’agent n’est jamais remplacé automatiquement.

Simuler puis convertir

Arrêter tous les processus qui écrivent dans ce journal avant la conversion. Utiliser les paramètres de rétention d’origine et un nouveau répertoire dont le parent existe. Cette commande fonctionne sans connexion à Docker.

monit-docker --audit-file /var/lib/monit-docker/events.jsonl \
  --audit-max-bytes 5242880 --audit-files 5 \
  audit-migrate --dry-run --output-dir /srv/monit-migration-001

monit-docker --audit-file /var/lib/monit-docker/events.jsonl \
  --audit-max-bytes 5242880 --audit-files 5 \
  audit-migrate --apply --output-dir /srv/monit-migration-001

Sans --apply, la commande valide et affiche un bilan JSON sans créer les fichiers de sortie. Le fichier de verrouillage associé au journal peut être créé. Un verrou occupé provoque une erreur immédiate. Les options globales précèdent audit-migrate.

Sauvegarde et résultat

Emplacement crééContenu
backup/Fichier actif et archives conservés à l’identique, octet par octet.
converted/Fichiers au schéma 2, avec les mêmes noms et le même ordre d’événements.
manifest.jsonBilan final : état, nombres d’événements, paramètres et empreintes SHA-256.

Les répertoires sont privés (0700), les fichiers aussi (0600), et appartiennent à l’utilisateur qui lance la commande. Une destination existante est refusée, comme un nom réservé aux archives ou au verrou du journal. Prévoir l’espace nécessaire aux originaux et aux copies converties, dont les textes peuvent grandir.

Contrôles effectués

Les fichiers sont validés avant de créer la destination. Les sauvegardes et les sorties sont ensuite relues : contenu complet, schéma, nombre d’événements, identifiants et corrélations sont vérifiés. Les champs scalaires supplémentaires sont conservés. Il n’y a ni tri ni dédoublonnage, et les valeurs du schéma 2 ne sont pas échappées une seconde fois.

Le bilan indique status (dry_run ou complete), records, legacy_records, target_schema et l’inventaire par fichier. Le manifeste utilise sa propre version de format. La conversion reste facultative : la lecture accepte déjà les schémas 1 et 2.

Le traitement parcourt les événements sans charger tout l’historique en mémoire. Un événement doit tenir dans 64 Kio. Chaque fichier d’origine et converti doit respecter la limite de lecture configurée, soit --audit-max-bytes plus un événement maximal. Augmenter cette limite si l’échappement fait trop grandir une archive, puis conserver cette valeur pour la relire.

Erreurs et interruption

Codes de sortie : 0 pour une simulation ou une conversion réussie, 2 pour des arguments incorrects, 119 pour un échec de migration. Les diagnostics restent en anglais sur la sortie d’erreur ; le bilan JSON est sur la sortie standard.

La commande refuse les schémas inconnus, les textes invalides, les événements tronqués ou trop gros, les champs imbriqués, les clés JSON dupliquées et les nombres non finis. Elle refuse aussi les liens symboliques et fichiers spéciaux. Une archive numérotée au-delà de --audit-files provoque une erreur : elle ne doit pas être oubliée silencieusement.

Après une erreur d’écriture ou une interruption, les originaux restent intacts et le répertoire partiel est conservé. Ne pas utiliser un résultat sans manifest.json final portant status: "complete". Un fichier temporaire peut subsister. Vérifier aussi le code de sortie, résoudre la cause puis recommencer dans un nouveau répertoire. Il n’y a ni reprise, ni suppression, ni écrasement automatique.

Activation et retour arrière

Après vérification, les processus étant toujours arrêtés, l’administrateur peut choisir le nouveau chemin --audit-file dans converted/, ou copier le jeu converti dans un répertoire persistant préparé. Adapter les droits au compte du service et conserver les paramètres de rétention. Vérifier un export complet avant de relancer les écritures.

Conserver les originaux hors du chemin de rotation. Ne pas concaténer les deux jeux : ils contiennent les mêmes identifiants. Recharger la première page du journal après le changement de chemin. Pour revenir en arrière, arrêter les écritures et conserver séparément les événements ajoutés depuis l’activation avant de restaurer une sauvegarde. Aucune action ne doit être rejouée.

L’outil traite uniquement les journaux, pas la configuration ni les états persistants des actions. Voir les environnements pris en charge et la procédure de compatibilité et de sauvegarde.