Monitoring d'un site Drupal

Un site Drupal en production n'est jamais vraiment au repos. Le trafic fluctue, le cron tourne, les modules échangent avec des API tierces, les logs s'accumulent et l'espace disque se remplit. La question n'est pas de savoir si un incident finira par survenir, mais de savoir si vous l'apprendrez par un tableau de bord ou par un appel d'un client mécontent. Le monitoring, c'est exactement la différence entre ces deux scénarios. Bien configuré, il transforme une panne potentiellement coûteuse en une alerte traitée avant même que les utilisateurs ne s'en aperçoivent.

La bonne nouvelle, c'est qu'un socle de surveillance efficace se met en place rapidement et sans budget démesuré. Quelques sondes externes, une bonne gestion des logs et une poignée d'alertes bien pensées couvrent déjà la majorité des risques. Cet article passe en revue les métriques à surveiller sur un site Drupal, les outils qui font le travail, la question des logs (dblog ou syslog), les alertes à configurer et la différence fondamentale entre une posture réactive et une posture proactive.

Les métriques à surveiller

Tout ne se vaut pas. Surveiller trop de choses noie les signaux importants dans le bruit, et surveiller trop peu laisse des angles morts. Voici les indicateurs qui comptent réellement pour un site Drupal en production.

Uptime (disponibilité). C'est la métrique reine. Votre site répond-il, et répond-il correctement ? Une sonde externe qui interroge une URL toutes les minutes détecte une panne en quelques secondes. Idéalement, la sonde ne se contente pas du code HTTP 200 : elle vérifie aussi qu'un mot-clé attendu est présent dans la page, car un site Drupal peut renvoyer un 200 tout en affichant une page d'erreur ou un message « site en maintenance » non désiré.

Erreurs PHP. Les erreurs et exceptions PHP sont le symptôme le plus direct d'un problème applicatif : un module incompatible après une mise à jour, une dépendance manquante, une fuite mémoire. Surveiller le taux d'erreurs PHP permet de repérer une régression avant qu'elle ne dégrade l'expérience d'une partie des visiteurs. Une hausse soudaine du nombre d'erreurs est presque toujours le signe d'un déploiement ou d'une mise à jour à examiner.

Exécution du cron. Le cron de Drupal orchestre des tâches essentielles : indexation de la recherche, envoi d'emails en file d'attente, purge de cache, nettoyage des fichiers temporaires, rotation des logs. Un cron qui ne tourne plus est un problème silencieux par nature : rien ne casse visiblement, mais les emails ne partent plus, l'index de recherche se périme et les files d'attente s'accumulent. Il faut surveiller la dernière exécution réussie du cron et alerter si elle dépasse un seuil (par exemple plusieurs heures sans run).

Espace disque. Un disque plein provoque des pannes spectaculaires et difficiles à diagnostiquer dans l'urgence : impossible d'écrire en base, sessions corrompues, uploads en échec. Sur Drupal, les coupables habituels sont les logs qui gonflent, le répertoire des fichiers temporaires, les images dérivées (image styles) et parfois la table watchdog de dblog. Surveiller le pourcentage d'occupation et alerter autour de 80 à 85% laisse une marge confortable pour intervenir.

Temps de réponse. La performance perçue se dégrade souvent progressivement, ce qui la rend insidieuse. Un temps de réponse moyen qui passe de 300 ms à près de 2 secondes sur plusieurs semaines signale en général un problème de cache, une requête SQL devenue lente avec la croissance des données ou une API tierce qui ralentit. Suivre le temps de réponse dans le temps permet d'agir avant que la lenteur ne devienne un problème business.

À ces fondamentaux, on ajoute selon les contextes la surveillance du certificat SSL (date d'expiration), de la connectivité base de données, de l'état des services externes (CDN, service d'email, paiement) et de la charge serveur (CPU, RAM). L'essentiel est de partir des fondamentaux ci-dessus et d'étendre ensuite en fonction des enjeux réels du site.

Les outils du monitoring

L'écosystème est riche et il n'est pas nécessaire d'empiler dix outils. On distingue trois grandes familles, complémentaires.

Les sondes de disponibilité externes. Elles interrogent votre site depuis l'extérieur, exactement comme le ferait un visiteur. UptimeRobot est un classique : simple, fiable, avec un palier gratuit qui suffit pour démarrer et des contrôles toutes les minutes ou cinq minutes. StatusCake joue dans la même catégorie avec des fonctions supplémentaires intéressantes : tests depuis plusieurs régions du monde, surveillance de l'expiration des domaines et des certificats SSL, pages de statut publiques. L'avantage d'une sonde externe est décisif : si votre serveur tombe entièrement, l'outil de monitoring installé dessus tombe avec lui, alors qu'une sonde externe continue de voir le problème et de vous alerter.

Les outils de supervision applicative (APM). New Relic est la référence pour aller au-delà du « ça répond ou non » et comprendre pourquoi c'est lent. Il instrumente le code PHP et révèle quelles requêtes SQL, quels hooks Drupal ou quels appels externes consomment le plus de temps. C'est un investissement qui prend tout son sens sur les sites à fort trafic ou à enjeux de performance, où une lenteur a un coût direct. Pour des besoins plus modestes, des alternatives comme Blackfire (orienté profiling) ou des solutions open source autour de Prometheus et Grafana couvrent une partie du périmètre.

La supervision serveur. Pour les métriques système (disque, CPU, RAM, cron), les outils d'infrastructure comme Netdata, Datadog ou la stack Prometheus et Grafana surveillent l'hôte lui-même. Sur les hébergements managés (Platform.sh, Acquia, Pantheon), une partie de cette supervision est souvent déjà intégrée et il suffit de brancher les alertes.

Le bon assemblage dépend de votre contexte. Pour beaucoup de sites, une sonde externe (UptimeRobot ou StatusCake) couplée à une supervision serveur de base et à une bonne gestion des logs constitue déjà un dispositif solide. New Relic vient compléter quand la performance applicative devient un enjeu mesuré.

Les logs Drupal : dblog ou syslog

Drupal journalise ses événements via le sous-système Logger, et deux modules du core en proposent l'implémentation. Le choix entre les deux n'est pas anodin pour qui veut monitorer sérieusement.

Database Logging (dblog). C'est le module activé par défaut. Il écrit les événements dans la table watchdog de la base de données, consultables directement dans l'interface d'administration (Rapports > Messages récents du journal). Pratique pour un coup d'œil rapide, dblog montre vite ses limites en production : il alourdit la base, ses écritures pèsent sur les performances sous forte charge et la table peut gonfler considérablement si la limite de purge n'est pas configurée correctement. C'est aussi une cause fréquente de disque qui se remplit.

Syslog. Ce module envoie les événements vers le syslog du système d'exploitation, donc vers des fichiers gérés par l'infrastructure. C'est l'approche recommandée en production : les écritures sont plus légères, elles n'impactent pas la base de données et les logs deviennent exploitables par les outils standards (agrégation, rotation, expédition vers une plateforme centralisée comme un stack ELK, Loki ou un service cloud). Pour un site avec du volume, basculer de dblog vers syslog est souvent un gain immédiat de performance et de robustesse.

En pratique, sur un site à enjeux, on désactive dblog au profit de syslog et on centralise les logs dans un outil qui permet de chercher, filtrer et alerter. C'est ce qui transforme des fichiers de logs passifs en véritable source de détection. Ce genre d'arbitrage technique fait partie de ce qu'un suivi sérieux apporte, et c'est l'une des composantes de notre offre de maintenance Drupal, où la configuration du monitoring et des logs est posée dès la prise en charge du site.

Les alertes à configurer

Un monitoring qui collecte des données sans alerter est un monitoring qu'on oublie de regarder. Les alertes sont le mécanisme qui fait remonter l'information au bon moment, à la bonne personne. Quelques règles pour des alertes utiles plutôt que bruyantes.

Couvrir les bons événements. Au minimum : site indisponible (uptime), pic d'erreurs PHP, cron non exécuté depuis un seuil défini, espace disque au-delà de 80 à 85%, certificat SSL expirant dans moins de deux semaines et dégradation marquée du temps de réponse. Ce sont les six alertes qui attrapent l'essentiel des incidents réels.

Calibrer les seuils pour éviter la fatigue d'alerte. Une alerte qui se déclenche pour un micro-incident sans conséquence finit par être ignorée, et c'est ce jour-là que la vraie panne passe inaperçue. Mieux vaut quelques alertes pertinentes que cinquante notifications quotidiennes. On ajuste les seuils dans le temps en fonction du comportement réel du site.

Router vers le bon canal. Email pour le suivi, mais aussi Slack, SMS ou un système d'astreinte (PagerDuty, Opsgenie) pour les incidents critiques. Une alerte d'indisponibilité à 3h du matin doit réveiller quelqu'un si le site est critique, ou au contraire patienter jusqu'au matin s'il ne l'est pas. La criticité du site dicte le niveau d'escalade.

Quand une alerte critique se déclenche, encore faut-il que quelqu'un soit en mesure d'intervenir vite. C'est là que le monitoring rejoint la capacité de réaction : une alerte sans bras pour agir derrière n'évite pas l'incident. Pour les situations où la rapidité d'intervention est vitale, notre support Drupal d'urgence prend le relais sur les incidents critiques, en complément des équipes déjà en place.

Monitoring proactif ou réactif

C'est la distinction qui sépare un dispositif subi d'un dispositif maîtrisé.

Le monitoring réactif consiste à être prévenu quand quelque chose est déjà cassé : le site est tombé, le disque est plein, les erreurs explosent. C'est indispensable, c'est le filet de sécurité de base, mais c'est par définition une course derrière le problème. L'incident a déjà commencé, des utilisateurs sont peut-être déjà touchés et il faut intervenir dans l'urgence.

Le monitoring proactif vise à détecter les signaux faibles avant qu'ils ne deviennent des incidents. Un temps de réponse qui dérive lentement, un espace disque qui se remplit régulièrement, un taux d'erreurs qui monte par paliers, une file d'attente de cron qui grossit : autant de tendances qui, suivies dans le temps, permettent d'agir à froid plutôt qu'à chaud. Planifier l'extension d'un disque avant qu'il ne soit plein coûte infiniment moins cher que de gérer la panne qui en découle.

La maturité consiste à combiner les deux : les alertes réactives garantissent qu'aucun incident grave ne passe inaperçu, et l'analyse proactive des tendances réduit progressivement le nombre d'incidents qui surviennent. Un site bien surveillé n'est pas un site qui ne tombe jamais (ça n'existe pas), c'est un site où l'on voit venir les problèmes et où l'on apprend de chaque incident.

Vous voulez mettre en place une surveillance solide sur votre site Drupal ou auditer celle qui existe déjà ? Parlons de votre projet et définissons ensemble le dispositif adapté à vos enjeux.