Les journaux : la seule chose qui grossit sans que personne l’ait décidé

L’essentiel de ce qui remplit votre disque, c’est vous qui l’avez ajouté : machines virtuelles, sauvegardes, images d’installation. Chacun était une décision.

Les journaux sont différents. Ils grossissent parce que le système tourne. Personne n’a jamais dit « que ce fichier grossisse ».

La croissance est lente mais sans limite

Un fichier de journal peut grossir de quelques kilooctets par jour. Cela n’attire l’attention de personne pendant des mois. Un an plus tard il est encore petit.

Mais il n’a pas de plafond. Et une croissance sans plafond, si lente soit-elle, devient un problème si vous attendez assez longtemps.

Le multiplicateur que personne n’attend : la panne accélère l’écriture

C’est là le vrai propos de cet article.

Un système en bonne santé écrit peu. Si une vérification échoue à chaque exécution, une ligne tombe dans le même fichier à chaque exécution. Pour une tâche qui tourne toutes les quinze minutes, cela fait quatre-vingt-seize lignes par jour, et cela ne s’arrête pas.

Le journal grossit donc le plus vite précisément quand vous pouvez le moins le regarder : pendant qu’une panne est en cours.

Et sa pire version

Un problème apparaît, les journaux accélèrent, le disque se remplit. Le disque plein provoque de nouveaux problèmes. Les nouveaux problèmes produisent plus de journaux.

À partir de là, il devient plus difficile de trouver la panne d’origine, car la plupart des erreurs à l’écran ne sont pas la conséquence du premier problème mais du disque plein.

La règle : tout ce qui écrit doit avoir un plafond

« On nettoiera plus tard » n’est pas un plan. Ce qu’il faut, c’est une limite mécanique qui s’applique sans que personne ait à s’en souvenir.

Cette règle ne vaut pas seulement pour les journaux du système : elle vaut pour tout fichier produit par vos services, par les tâches planifiées et par les collecteurs.

Deux erreurs fréquentes en configurant la rotation

Un : la règle qui casse à cause d’un fichier absent. Certains fichiers n’apparaissent que lorsque la fonction correspondante est utilisée. La règle doit être écrite de façon à ne pas échouer quand un fichier manque ; sinon une fonction que vous n’utilisez jamais arrête toute la rotation.

Deux : la mauvaise méthode de rotation. Renommer le fichier et envoyer au service qui écrit un signal « rouvre » est la méthode courante, mais elle ne marche que s’il existe un service de longue durée. Si l’écrivain est une tâche brève qui ouvre et ferme à chaque fois, il n’y a personne à qui envoyer un signal ; dans ce cas, la bonne méthode est de copier le contenu et de vider le fichier sur place.

Les deux sont des échecs silencieux : la règle est en place, le fichier continue de grossir, et personne ne remarque que la règle ne fonctionne pas.

Et la question de la machine déjà installée

Si vous n’écrivez une règle de rotation que dans le script d’installation, elle n’atteint jamais les machines installées avant l’existence de la règle. Ces machines tournent des années sans elle.

La bonne façon est d’écrire la règle à chaque démarrage : ainsi les installations plus anciennes la reçoivent quand elles passent à une nouvelle version.

Ce que fait Atlas

Tout cet article vient d’une mesure faite par Atlas sur lui-même, il faut donc le raconter honnêtement.

Atlas tourne avec les droits root sur la machine du client et écrit dans plusieurs fichiers de journal : le résumé du veilleur toutes les quinze minutes, la sortie des mises à jour planifiées à chaque exécution, son propre relevé d’auto-mise à jour. Cela a été mesuré et aucun d’eux n’était en rotation, car l’installation n’écrivait de règle de rotation nulle part. Sur une machine en service, le journal du veilleur avait atteint cent quatre-vingts kilooctets en trente-deux jours et il n’existait aucun mécanisme pour le réduire.

Le chiffre paraît petit et ce jour-là ce n’était pas un problème. Le problème était que la croissance était sans limite, plus l’accélération décrite plus haut. Les journaux des mises à jour planifiées capturent toute la sortie du gestionnaire de paquets à chaque exécution, ce qui peut atteindre des mégaoctets par exécution.

La règle est désormais écrite, et les deux pièges ci-dessus sont traités délibérément : les fichiers absents sont tolérés, et la rotation utilise la méthode copier puis vider, car ceux qui écrivent sont des processus brefs lancés par une tâche planifiée.

Et la règle est écrite au démarrage, pas dans le script d’installation. La raison est exactement la question ci-dessus : pour que les machines installées plus tôt reçoivent elles aussi la règle en passant à une nouvelle version.