La surveillance en temps réel d'une application Drupal en production est un enjeu stratégique pour garantir la disponibilité et la performance des services numériques. Pourtant, de nombreux projets s'appuient encore sur des méthodes de journalisation obsolètes ou se tournent vers des abonnements cloud propriétaires dont les tarifs s'envolent à la moindre crise de performance.
Cet article détaille comment mettre en place une stratégie d'observabilité moderne, souveraine et économiquement viable en s'appuyant sur des outils open-source auto-hébergés.
Les limites du watchdog de Drupal en environnement de production
Le module de journalisation natif de Drupal, communément appelé watchdog, enregistre les événements directement dans la base de données de l'application via le module dblog. Si cette solution convient parfaitement durant les phases de développement local, elle s'avère totalement inadaptée et risquée pour un environnement de production.
Pourquoi le journal natif de Drupal sature rapidement ?
L'écriture continue de logs d'erreurs, d'avertissements ou d'actions d'utilisateurs dans la base de données principale génère des problématiques majeures :
- Une amplification importante des opérations d'écriture sur le serveur de base de données, ce qui ralentit les requêtes SQL légitimes des utilisateurs du site.
- Un gonflement rapide de la taille des tables de stockage, entraînant des lenteurs lors des opérations de sauvegarde et de restauration de la base de données.
- Des risques de verrous de tables lors de pics d'erreurs simultanés, ce qui peut paralyser l'intégralité du site web en production.
La problématique des architectures multi-serveurs sur AWS ou OVHcloud
Dans le cadre d'un hébergement moderne s'appuyant sur des grappes de serveurs (clusters d'auto-scaling) ou sur Kubernetes, les instances applicatives deviennent éphémères. Si un conteneur ou un serveur s'éteint, l'accès aux logs locaux devient complexe.
- Les logs de base de données ne permettent pas de corréler efficacement quelle instance spécifique a généré l'anomalie sans ajouter des surcharges d'informations complexes.
- Les fichiers de logs classiques écrits sur disque dur sont perdus lors de la destruction automatique d'une instance par le service d'auto-scaling.
- La centralisation des journaux devient un prérequis technique absolu pour que les équipes de production puissent analyser les dysfonctionnements de manière globale.
L'alternative de l'observabilité open-source et auto-hébergée
Pour pallier ces limites, il est nécessaire de déporter la collecte et l'analyse des erreurs vers une plateforme externe dédiée. Au lieu de souscrire à des services SaaS tiers qui facturent au volume de données et hébergent souvent les informations hors de l'Union européenne, l'auto-hébergement d'une solution libre constitue la réponse idéale.
Comparaison des approches d'observabilité
Pour comprendre les enjeux, voici une analyse comparative entre les différentes méthodes :
- L'approche du journal interne dblog de Drupal : elle est gratuite mais consomme des ressources système critiques, sature la base de données applicative et n'offre aucune alerte en temps réel.
- L'approche SaaS propriétaire type Sentry Cloud ou Datadog : elle offre d'excellentes fonctionnalités de filtrage et d'alertes, mais présente un coût d'exploitation très élevé et expose l'organisation à des transferts de données hors Union européenne.
- L'approche open-source auto-hébergée avec GlitchTip : elle offre les mêmes fonctionnalités avancées que les meilleurs outils du marché, garantit une maîtrise totale de la souveraineté des données et supprime les coûts de licence récurrents.
GlitchTip, l'alternative légère et compatible avec le protocole Sentry
GlitchTip est un outil open-source écrit en langage Python avec le framework Django, utilisant une base de données PostgreSQL. Sa grande force est de reprendre l'interface de programmation (API) de Sentry.
- Il permet de réutiliser tous les SDK et modules clients développés pour Sentry sans aucune modification de code complexe.
- Son empreinte mémoire et sa consommation de ressources CPU sont extrêmement faibles, ce qui rend son hébergement très économique sur un serveur virtuel classique.
- Il centralise les exceptions PHP, les logs applicatifs de Drupal ainsi que les erreurs JavaScript qui surviennent directement sur le navigateur de vos internautes.
Déploiement technique de GlitchTip et connexion avec Drupal
La mise en œuvre de cette architecture s'effectue en deux étapes principales : le déploiement de l'instance GlitchTip sur votre infrastructure (OVHcloud ou AWS) et la configuration du module de liaison sur votre application Drupal 10 ou Drupal 11.
Schéma global d'intégration de GlitchTip
L'instance de monitoring doit être installée de préférence sur un réseau ou un serveur distinct de l'application de production pour éviter qu'une panne de l'application n'affecte l'outil de surveillance. L'utilisation d'un conteneur Docker facilite grandement son déploiement et ses mises à jour.
Voici un exemple de configuration pour déployer rapidement l'outil via un fichier docker-compose :
version: '3.8'
services:
postgres:
image: postgres:15
environment:
POSTGRES_DB: glitchtip
POSTGRES_USER: glitch_user
POSTGRES_PASSWORD: un_mot_de_passe_tres_secourise
volumes:
- pgdata:/var/lib/postgresql/data
web:
image: glitchtip/glitchtip:v4.0
ports:
- "8000:8000"
environment:
DATABASE_URL: postgres://glitch_user:un_mot_de_passe_tres_secourise@postgres:5432/glitchtip
SECRET_KEY: une_cle_secrete_generée_aleatoirement
PORT: 8000
depends_on:
- postgres
volumes:
pgdata:Configuration du module Drupal Sentry pour GlitchTip
Une fois votre instance GlitchTip opérationnelle, vous devez créer un nouveau projet dans son interface pour obtenir une adresse de connexion nommée DSN (Data Source Name). Dans votre projet Drupal, installez le module contrib Sentry à l'aide de Composer.
Saisissez ensuite la configuration directement dans votre fichier settings.php pour éviter de stocker des clés de connexion en base de données :
// Configuration de la connexion au serveur d'observabilité open-source
$config['sentry.settings']['dsn'] = '[https://cle_publique@glitchtip.mon-infrastructure.net/1](https://cle_publique@glitchtip.mon-infrastructure.net/1)';
$config['sentry.settings']['environment'] = 'production';
$config['sentry.settings']['release'] = 'v1.4.2';
// Désactivation de la journalisation en base de données locale pour économiser les ressources
$config['system.logging']['error_level'] = 'hide';Sécurisation des données et conformité au RGPD
Le RGPD impose des règles strictes concernant la collecte, le stockage et le traitement des données à caractère personnel (PII). Les rapports d'erreurs générés par PHP ou Drupal contiennent fréquemment des informations sensibles comme des adresses courriels, des jetons de connexion, des cookies ou même des mots de passe saisis par erreur dans des formulaires.
Filtrage des données personnelles à la source avant envoi
Pour respecter la souveraineté des données, il est indispensable de nettoyer les données directement sur le serveur Drupal avant qu'elles ne soient expédiées à GlitchTip. Le SDK PHP utilisé par le module Drupal permet de déclarer des filtres personnalisés.
Voici un exemple de code PHP à intégrer dans un module sur-mesure ou dans un service Drupal pour nettoyer automatiquement les requêtes contenant des informations confidentielles :
namespace Drupal\mon_module_monitoring\EventSubscriber;
use Sentry\Event;
use Sentry\EventHint;
class SentrySanitizer {
// Cette méthode nettoie les données sensibles de l'événement d'erreur
public function sanitizeEvent(Event $event, EventHint $hint): ?Event {
$request = $event->getRequest();
if ($request) {
$data = $request['data'] ?? [];
// Liste des champs sensibles à masquer obligatoirement
$sensitive_fields = ['password', 'mail', 'token', 'authorization', 'cookie'];
foreach ($sensitive_fields as $field) {
if (isset($data[$field])) {
$data[$field] = '[DONNEE_MASQUEE_PAR_SECURITE]';
}
}
$request['data'] = $data;
$event->setRequest($request);
}
return $event;
}
}Configuration des alertes par niveau de criticité et équipe
L'un des principaux avantages d'un outil dédié comme GlitchTip est sa capacité à organiser la gestion des alertes de manière intelligente :
- Les erreurs de niveau critique (exceptions fatales PHP, erreurs de connexion à la base de données) sont envoyées instantanément par courrier électronique ou via des webhooks vers vos canaux de discussion Slack ou Mattermost.
- Les avertissements mineurs (fonctions dépréciées, alertes de traduction manquante) sont stockés sans déclencher de notification, afin de ne pas saturer l'attention des équipes de développement.
- La répartition des alertes peut s'organiser par projet ou par équipe de production, permettant ainsi de cibler précisément les ingénieurs responsables du composant défaillant.
Conclusion sur l'importance de la souveraineté numérique
Passer à une solution d'observabilité open-source et auto-hébergée représente un gain significatif sur tous les plans pour les projets Drupal d'envergure.
- Sur le plan financier : la suppression des licences SaaS tierces permet de réinvestir le budget dans l'amélioration de l'infrastructure ou dans des fonctionnalités à forte valeur ajoutée pour les utilisateurs.
- Sur le plan technique : la centralisation immédiate des exceptions PHP et JavaScript améliore drastiquement le temps de résolution des incidents de production.
- Sur le plan de la souveraineté : l'hébergement de vos outils de diagnostic sur des infrastructures de confiance chez OVHcloud ou au sein de vos espaces privés AWS garantit un contrôle total et pérenne de votre patrimoine informationnel numérique.
Questions fréquentes sur le monitoring Drupal
GlitchTip est-il capable de suivre les erreurs du front-end JavaScript sur un Drupal découplé ?
Oui. GlitchTip s'appuie sur les bibliothèques et SDK standards de Sentry. Vous pouvez intégrer le SDK JavaScript officiel de Sentry au sein de votre application front-end (React, Vue.js, Angular ou Next.js) et configurer l'adresse de connexion pour envoyer directement toutes les anomalies d'affichage ou d'exécution vers la même interface de contrôle.
Quel est l'impact de l'envoi d'erreurs HTTP sur le temps de chargement de mon site Drupal ?
Le module Drupal Sentry expédie les rapports d'erreurs de manière asynchrone à la toute fin de l'exécution du script PHP, ou s'appuie sur le gestionnaire de fin de requête de Drupal. De ce fait, l'utilisateur final ne subit aucun ralentissement notable lors de sa navigation, même lorsqu'une erreur interne est capturée et envoyée.
Est-il difficile de mettre à jour une instance GlitchTip auto-hébergée ?
Non. Le projet étant distribué sous forme de conteneurs Docker officiels, la mise à jour se résume généralement à modifier le numéro de version dans votre fichier docker-compose, à télécharger la nouvelle image et à relancer le conteneur. Les migrations de la base de données PostgreSQL sont gérées automatiquement au démarrage de la nouvelle version.
