Accueil Technologies Logrotate – ajout / test d’une configuration de rotation des logs
Logrotate - ajout & test d'une configuration de rotation des logs

Logrotate – ajout / test d’une configuration de rotation des logs

par Jérémy PASTOURET

Si vous ne connaissez pas Logrotate, je vous invite à lire mon précédent article qui explique à quoi sert ce service. Et comment il fonctionne – dans les grandes lignes. Dans cet article, nous allons rédiger une configuration pour un service contenant des logs. Celui-ci ne possède pas encore de politique de rotation de logs. C’est mon cas aujourd’hui : j’ai développé un service qui s’exécute en arrière-plan et j’ai besoin d’une historisation des logs. Cela peut aussi vous intéresser si vous êtes un administrateur de serveur. Surtout si vous avez organisé les répertoires un peu différemment, et que vous devez changer les fichiers de configuration.

Comment créer sa propre configuration pour un service ?

Il est important de suivre la documentation sur cette partie, c’est-à-dire de créer un fichier de configuration par programme. Les avantages ? Éviter de tout faire planter, et mieux s’organiser en sous-fichiers. Cela permet aussi de désactiver rapidement une configuration défaillante. Pour vous imprégner de cette organisation, rendez-vous dans le répertoire suivant :

/etc/logrotate.d/

Vous obtiendrez approximativement le contenu suivant – en fonction des programmes installés :

logrotate.d ls
alternatives  apport  cups-daemon  httpd-prerotate  ppp      speech-dispatcher  ufw
apache2       apt     dpkg         jenkins          rsyslog  stunnel4           unattended-upgrades

Création du fichier de configuration

Pour chaque service, il existe une configuration. Vous souhaitez créer une nouvelle configuration correspondant à un service en particulier ? Il faut alors créer un fichier portant le nom du service concerné dans ce répertoire (surtout sans extension). Par exemple :

touch new-service

Concernant le contenu de ce fichier, il y a quelques règles à respecter. Éditez le fichier nouvellement créé, puis ajoutez-y les lignes dont vous avez besoin – par rapport à l’exemple de base présent ci-dessous. Prenez en compte que le nom du nouveau service se nomme new-service : il faudra donc le remplacer par le vôtre.

/var/log/new-service/*.log {
	daily
	missingok
	rotate 14
	compress
	delaycompress
	notifempty
	create 640 root adm
}

Explication détaillée de la configuration

La première ligne indique le chemin pour trouver tous les types de logs d’un service. Il faut remplacer new-service par le programme que vous souhaitez gérer. Si les logs générés possèdent l’extension .log, Logrotate devrait s’en sortir. Vous pouvez aussi procéder autrement en insérant directement le nom du fichier de logs, par exemple history.log.

Il est également possible de définir plusieurs types de logs dans un fichier de configuration. Une typologie de log est définie par : un chemin pour accéder au log en question, suivi d’une accolade définissant les paramètres de ces logs-ci. Par exemple :

/var/log/new-service-1/*.log {
	daily
	missingok
	rotate 14
	compress
	delaycompress
	notifempty
	create 640 root adm
}

/var/log/new-service-2/*.log {
	weekly
	missingok
	rotate 14
	compress
	delaycompress
	notifempty
	create 640 root adm
}

daily | weekly : définit la régularité de la rotation des logs. Si vous souhaitez avoir des logs qui tournent tous les jours, il faut préciser daily. Une fois par semaine : weekly. Une fois par mois : monthly. Et une fois par an : yearly.

missingok : le script fonctionnera même si le fichier de logs courant n’a pas été crée. Par exemple, pendant le week-end, un service précis n’est pas utilisé et donc aucun fichier de logs n’est généré. Le programme de rotation de logs n’enverra pas de mail à l’administrateur pour lui indiquer l’absence du fichier de logs.

rotate <nombre> : c’est une propriété importante qui définit le nombre de fichiers de logs conservés. Dans l’exemple ci-dessus, le programme conserve 14 jours de logs.

compress : pour garder de la place sur le disque dur, le système compresse les logs – sauf le fichier courant.

delaycompress : Lors de la compression, si le fichier de logs courant est utilisé par un programme, Logrotate compressera ce fichier sur la prochaine itération. C’est pourquoi, pour certains services, les logs sont définis comme suit :

auth.log  auth.log.1  auth.log.2.gz  auth.log.3.gz  auth.log.4.gz

notifempty : l’opération de rotation des logs n’est pas appliquée si le fichier courant est vide.

create 640 root adm : les fichiers créés par Logrotate auront comme étiquette root pour l’auteur et adm pour le groupe. Ces informations sont précieuses, en fonction de la stratégie de droits appliquée sur le serveur.

Maintenant que vous savez comment fonctionne le programme Logrotate, il est temps de passer à la partie test / debug.

Comment tester ou débugger une configuration pour Logrotate ?

La clé pour tester / débugger une configuration de Logrotate se résume en deux commandes :

logrotate -f /etc/logrotate.d/<nom>

La commande ci-dessus permet de forcer l’utilisation du script pour vérifier si celui-ci fonctionne.

logrotate -d /etc/logrotate.d/<nom>

La commande ci-dessus permet de déboguer le script. L’instruction retourne la réponse suivante :

Logrotate - debogage de script de configuration

Pourquoi la rotation des logs ne fonctionne-t-elle pas ?

Peut-être parce que le service qui écrit des logs supprime le contenu du fichier courant dans la journée. Cette opération est réalisée par mesure de sécurité, pour éviter de saturer l’espace disque. Pour parer à ce problème, il faut identifier l’heure à laquelle le service concerné vide le fichier de logs. En fonction de l’heure indiquée, il faut décaler cette opération – ou désactiver la fonction de vidage. Pour connaître l’heure de rotation des logs par le programme Logrotate, il faut consulter le fichier qui liste les tâches planifiées. Lancez la commande ci-dessous pour accéder à la liste des tâches par heures / minutes :

cat /etc/crontab 
Liste des tâches planifiées sous Ubuntu

Sur l’image ci-dessus, on voit que les tâches journalières sont exécutées à 6h25 (3ème ligne). Il faut donc gérer les logs en fonction de cette information. Ces paramètres sont modifiables, mais je ne vous encourage pas à le faire au risque de déstabiliser certains programmes habitués à ces horaires.

Conclusion

Vous êtes maintenant en capacité de rédiger vos propres configurations de rotation des logs. Si vous avez des questions ou des remarques, les commentaires sont tout à vous.

Vous pourriez aussi aimer

Laisser un commentaire

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.