Planification des scripts et des journaux

Introduction

Imaginez un robot qui nettoie votre maison pendant que vous dormez. Comme vous dormez, vous ne pouvez pas le voir travailler. À votre réveil, comment savoir s’il a vraiment nettoyé la maison ou s’il est resté bloqué sous le canapé ?

La solution consiste à demander au robot de tenir un journal.

Sous Linux, les scripts automatisés s’exécutent souvent en arrière-plan ou via des ordonnanceurs, sans personne pour surveiller le terminal. L’affichage à l’écran ne suffit donc pas. Pour garder une trace de ce qui s’est passé, nous écrivons plutôt la sortie dans un fichier journal.

C’est l’une des habitudes d’automatisation les plus simples et les plus utiles. Un script sans journalisation peut échouer silencieusement. Un script qui écrit des journaux laisse des éléments permettant de comprendre ce qui s’est passé.

Dans ce laboratoire, vous allez :

Rediriger la sortie : apprendre à un script à écrire dans un fichier plutôt qu’à l’écran ;
Préserver l’historique : utiliser l’opérateur d’ajout pour ajouter de nouvelles entrées sans supprimer les anciennes ;
Ajouter des horodatages : faire en sorte que chaque entrée du journal contienne une date et une heure.

Ajouter la sortie à un fichier journal

Les scripts classiques affichent immédiatement leur sortie à l’écran. C’est comme parler directement à quelqu’un. Mais si personne n’écoute — ce qui est souvent le cas pour les scripts automatisés — les informations sont perdues.

Nous devons enregistrer ces informations dans un fichier. Pour cela, nous utiliserons les opérateurs de redirection.

Cela reprend directement une notion déjà vue sur le shell : les commandes écrivent normalement sur la sortie standard, et la redirection détermine où cette sortie est envoyée. La journalisation est simplement une utilisation pratique de ce mécanisme dans l’automatisation.

> (écrasement) : « Effacer le journal et commencer une nouvelle page. » (Mauvais pour conserver l’historique)
>> (ajout) : « Aller à la prochaine ligne vide et y écrire. » (Idéal pour conserver l’historique)

Examinons le script simple que nous avons préparé :

cat myscript.sh

Il affiche simplement « The script is running ». Si vous l’exécutez maintenant (./myscript.sh), le message s’affiche à l’écran.

Modifions-le pour écrire dans un journal appelé script.log.

Ouvrez le script :

nano myscript.sh

Modifiez la ligne afin d’utiliser l’opérateur >>.

Conseil pratique : pour écrire dans des journaux, utilisez toujours le chemin absolu (l’adresse complète), par exemple /home/labex/project/script.log. Ainsi, le journal ne risque pas d’être créé dans un dossier inattendu si le script est exécuté depuis un autre emplacement.

Cette habitude est importante, car les tâches planifiées s’exécutent souvent depuis un répertoire de travail différent de celui que vous utilisez dans un shell interactif. Un script qui écrit dans script.log sans préciser de chemin peut créer le fichier au mauvais endroit.

Votre fichier doit ressembler à ceci :

#!/bin/bash
echo "The script is running" >> /home/labex/project/script.log

Enregistrez le fichier et quittez l’éditeur.

Exécutez maintenant le script :

./myscript.sh

Aucun affichage.

Le script s’est exécuté, mais il n’a rien affiché. Il a écrit son message dans le journal.

Consultez le journal :

cat script.log

Vous devez voir le message enregistré dans le fichier.

Ajouter des horodatages

Une entrée de journal qui indique « ce qui s’est passé » ne sert pas à grand-chose si elle n’indique pas « quand cela s’est passé ». Si votre script s’exécute tous les jours pendant un an, votre fichier journal contiendra simplement 365 lignes identiques indiquant « The script is running ».

Nous devons ajouter un horodatage. Linux fournit une commande appelée date, qui affiche la date et l’heure actuelles. Nous allons également rediriger sa sortie vers le fichier journal.

C’est le début de l’observabilité : laisser suffisamment d’éléments pour qu’une personne puisse reconstituer ce qui s’est passé plus tard. Même des horodatages très simples améliorent considérablement votre capacité à diagnostiquer les tâches automatisées.

Ouvrez myscript.sh :

nano myscript.sh

Ajoutez la commande date avant le message. Ainsi, le journal affichera d’abord l’heure, puis l’action.

#!/bin/bash
date >> /home/labex/project/script.log
echo "The script is running" >> /home/labex/project/script.log

Enregistrez le fichier et quittez l’éditeur.

Exécutez à nouveau le script :

./myscript.sh

Consultez le journal :

cat script.log

Vous devez maintenant voir quelque chose comme ceci :

The script is running
Fri Oct 27 10:00:00 UTC 2023
The script is running

La première ligne provient de votre test précédent.

Chaque action est maintenant associée à une heure précise. Vous pouvez ainsi prouver à votre responsable que la sauvegarde automatisée s’est bien exécutée à 3 heures du matin.

Dans les systèmes plus importants, les journaux permettent également de répondre à des questions plus complexes : le script s’est-il exécuté deux fois ? S’est-il arrêté en cours d’exécution ? Combien de temps s’est écoulé entre deux exécutions ? De bons journaux rendent l’automatisation invisible consultable et vérifiable.

Vérifier l’historique du journal

Testons la théorie de l’« ajout ». Si nous utilisions > (écrasement) au lieu de >> (ajout), notre fichier journal ne grandirait jamais : il afficherait simplement, en pratique, le résultat de la dernière exécution.

Cette distinction est importante lorsqu’un script s’exécute régulièrement. L’écrasement est utile pour obtenir un instantané de l’état actuel, mais l’ajout convient généralement mieux aux historiques, car il conserve la succession des événements.

Simulons une journée chargée pendant laquelle le script s’exécute plusieurs fois.

Exécutez-le trois fois de suite :

./myscript.sh
./myscript.sh
./myscript.sh

Lisez maintenant le journal :

cat script.log

Vous devez voir une liste d’entrées qui s’allonge, chacune avec son propre horodatage. Cet historique est très utile pour le dépannage. Si un serveur est tombé en panne hier, vous pouvez remonter jusqu’à l’horodatage d’hier dans le journal et voir exactement ce que faisait le script à ce moment-là.

Résumé

Vous avez appris à votre script à tenir un journal.

Dans ce laboratoire, vous avez appris à :

Rediriger la sortie (>>) : envoyer la « parole » du script dans un fichier afin qu’elle ne soit pas perdue ;
Ajouter des entrées : conserver l’historique au lieu de l’effacer ;
Ajouter des horodatages : utiliser date pour savoir quand les événements se sont produits.

C’est la méthode standard utilisée par les services professionnels sous Linux. Qu’il s’agisse d’un serveur web ou d’une base de données, tous écrivent dans des fichiers journaux, exactement comme vous venez de le faire.