Découvrez nos offres pour faire du digital le levier de votre croissance !

Modèles

Téléchargez le Guide Ultime de gestion de projet digitale pour vous aider à piloter vos transformations et faire les bons choix !

Image mise en avant pour l'article

Mettre en place une stratégie de log de production sur Drupal

31 janvier 2022
Par défaut, Drupal utilise un système de log nommé Watchdog qui utilise la base de données du site pour stocker tout un tas de messages.


Mais la gestion des logs sous Drupal est aussi possible grâce à un module inclus dans Drupal : syslog.

Je recommande l'utilisation de syslog plutôt que le système de log Watchdog par défaut. Je vous explique pourquoi ce choix et comment mettre en place cette stratégie de log de production sur Drupal.

 

Le protocole Syslog

Concentrons-nous d’abord sur le fonctionnement du protocole. Syslog est l’acronyme de System Logging Protocol et désigne un protocole standard qui permet l'envoi des fichiers du journal système ou des messages ayant trait à des événements à un serveur dédié appelé serveur syslog. Chaque message est caractérisé par un niveau de gravité (Severity level) représenté par un chiffre de 0 à 7.

Code Constante PHP Mot-clé Description
0 LOG_EMERG emerg Système inutilisable
1 LOG_ALERT alert Intervention immédiate nécessaire
2
LOG_CRIT
crit Erreur système critique
3 LOG_ERR err Erreur de fonctionnement
4 LOG_WARNING warning Avertissement
5 LOG_NOTICE notice Événement devant être signalé
6 LOG_INFO info Message d’information
7 LOG_DEBUG debug Message de débogage

 

Pourquoi utiliser Syslog plutôt que Watchdog ?

 

Syslog est une alternative au système de logs en base de données proposés par défaut sur Drupal. Cette alternative présente plusieurs avantages :

  • L'utilisation du système de logs déjà présent sur l’OS du serveur ;
  • Des options de configuration beaucoup plus large (filtres, format de sortie, backup, etc.) ;
  • Pas d'utilisation de la base de données, ce qui évite les pertes de performance du site lorsque Drupal écrit de nouveaux logs.

Syslog présente aussi quelques inconvénients. Son utilisation requière :

  • Un accès à l’OS du serveur pour la consultation ;
  • Des connaissances techniques pour la mise en place de ce système.

 

Installation de Syslog sur un serveur

Syslog existe sous plusieurs variantes telles que rsyslog et syslog-ng. Ce sont des versions plus avancées offrant des fonctionnalité supplémentaires. Première bonne nouvelle : l’une de ces variantes est probablement déjà installée sur votre serveur. Sur les versions récentes de Debian, CentOS et Ubuntu, c’est rsyslog qui est en place. Pour vérifier que rsyslog est actif, il suffit d’utiliser cette commande dans un terminal :

rsyslogd -v

Si le service n’est pas présent, il peut être installé avec l’aide d’un gestionnaire de paquets (package manager). Sur les distributions Debian telles que Ubuntu il s’agit de APT. La commande à utiliser est :

sudo apt-get install rsyslog

 

Mise en place du module syslog

Le module syslog est inclus dans le core de Drupal. Il peut être utilisé en parallèle avec dblog ou peut le remplacer complètement. Le module peut être installé depuis la page des modules ou directement en utilisant drush avec la commande :

drush en syslog -y

Passons ensuite à la configuration. En consultant la page /admin/config/development/logging on peut configurer la façon dont Drupal crée les logs. Tout d’abord, il faut sélectionner le type d’erreur à afficher dans les logs. Ici il est plutôt conseillé de configurer cette option depuis le fichier settings.php dans le dossier du site en ajoutant la ligne :

$config['system.logging']['error_level'] = hide/some/all ou verbose ;

(si la valeur « hide » correspond à l’affichage d’aucun message et la valeur « verbose » correspond à l’affichage de tous les messages avec un stack trace complete).

Mise en place du module syslog

Le champ « Syslog Identity » correspond au nom qui apparaît dans le fichier de log. Ce champs permet de différencier les messages venant de Drupal dans la liste des logs.

Le champ « Syslog facility » permet de choisir une catégorie pour l’enregistrement des logs. Le protocole syslog dispose de 24 catégories. Certaines sont utilisées par l’OS et d’autres, comme celles finissant par "local", sont libres et peuvent être utilisées pour stocker les logs Drupal.

Il existe une page de configuration sur /admin/config/development/logging qui permet de choisir une catégorie (facility).

 

Configuration rsyslog

Il reste encore a configurer le fichier de sortie pour une catégorie de logs. Pour cela il faut modifier le fichier etc/rysislog.d/50-default.conf et ajouter en bas du fichier la ligne :

local0.* var/log/drupal.log

Ryslog comprend maintenant qu’il doit écrire tous les logs de la catégorie local0 dans le fichier qui se trouve dans var/log/drupal.log

Tous les logs sont écrits dans mon fichier, pour tous les niveaux, qu'il s'agisse d'un log de debug ou d’erreur.

Si je souhaite avoir un fichier de logs uniquement pour les erreurs et un autre pour les messages debugs, je peut le configurer comme ceci :

local0.err var/log/drupal.err.log
local0.debug var/log/drupal.debug.log

Ici je vais avoir un fichier avec mes logs d’erreurs et un autre avec mes logs de debug.

Vous pouvez changer le nom du fichier comme vous les souhaitez, tant qu’il n’est pas déjà utilisé par une autre catégorie de log.

Pour finir, il suffit de redémarrer le service rsyslog :

sudo service rsyslog --full-restart

 

Pour aller plus loin, il est également possible d’installer le module Drupal pour Monolog.

Monolog permet non seulement d’envoyer des logs avec rsyslog mais il dispose également de nombreux « Handlers » qui sont des interfaces pour d’autres services tels que ElasticSearch, Redis, ou un server rsyslog externe.

Il propose également des « formatters » pour changer le format de sortie, par exemple en JSON ou dans un format compatible avec un serveur logstash.

Et pour finir il existe des processors qui permettent d’ajouter rapidement des informations supplémentaires aux logs telles que l’utilisation mémoire ou l’URI de la requête.

Vous avez aimé cet article, je vous conseille de lire également ces deux articles :

 

Crédit photo : undrey

Image mise en avant pour l'article
Nicolas Fabing
Développeur Drupal @Adimeo
De l'urgence de migrer sur Drupal 9 : conseils et bonnes pratiques
Voir le webinar !
Vous maitrisez la technologie Drupal et vous souhaitez participer à une aventure humaine ?
Adimeo recrute un Développeur Drupal Senior capable d’encadrer des projets et d’accompagner des développeurs juniors...
Voir notre offre d'emploi !
Pourquoi s'abonner à
notre newsletter ?
Pour recevoir tous les mois, un condensé de contenus utiles et pertinents pour votre transformation digitale !