# Monitoring et logs : garder l’œil sur un parc de sites WordPress

> Gérer un site, c'est surveiller sa disponibilité. Gérer trente sites, c'est autre chose. Voici comment on a structuré notre surveillance après plusieurs pannes découvertes trop tard.

- Auteur : Clément Hadrot
- Publié le : 2023-01-17
- Mis à jour le : 2023-01-17
- Catégorie : Outils & workflow
- URL : https://wpmoderne.dev.wordpress-developpement.fr/outils/monitoring-logs-parc-sites-wordpress/

## L’essentiel

- Un site qui tombe sans qu'on le sache coûte plus cher qu'un site qui tombe
- Centraliser les logs évite de se connecter site par site
- Les alertes doivent être actionnables, pas juste bruyantes

Pendant longtemps, on a découvert qu'un site était en panne de la même façon que tout le monde : un client qui appelle. C'est la pire façon de l'apprendre, et sur un parc d'une trentaine de sites, ce n'était plus tenable. La mise en place d'une vraie stratégie de monitoring n'a rien de spectaculaire, mais elle a changé notre rapport aux incidents : on les détecte maintenant avant les utilisateurs, dans la grande majorité des cas.

## Trois niveaux de surveillance, pas un seul

On distingue systématiquement trois niveaux de monitoring, qui répondent à des questions différentes et qui échouent rarement en même temps :

- **Disponibilité** : le site répond-il, avec un code HTTP correct, en dessous d'un délai acceptable ?
- **Erreurs applicatives** : PHP génère-t-il des erreurs fatales, des avertissements de dépréciation, des requêtes SQL en échec ?
- **Performance** : le temps de réponse se dégrade-t-il progressivement, même sans erreur explicite ?

Un site peut répondre en 200 tout en générant des centaines d'erreurs PHP silencieuses dans les journaux. Se contenter d'un contrôle de disponibilité classique laisse passer ce genre de dégradation invisible pendant des semaines.

## Centraliser les logs applicatifs

> L'essentiel à retenir : Un site qui tombe sans qu'on le sache coûte plus cher qu'un site qui tombe ; Centraliser les logs évite de se connecter site par site ; Les alertes doivent être actionnables, pas juste bruyantes

Par défaut, WordPress écrit ses erreurs dans un fichier `debug.log` local à chaque site, activé via la configuration suivante :

```
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
```

Sur un seul site, se connecter en SSH pour consulter ce fichier est acceptable. Sur trente sites, c'est ingérable. On centralise désormais ces journaux via un agent de collecte qui remonte les logs vers un outil unique, ce qui permet de rechercher une erreur précise sur l'ensemble du parc en une seule requête plutôt que trente connexions SSH successives.

```
# Extrait de configuration rsyslog pour remonter les logs applicatifs
$ModLoad imfile
$InputFileName /var/www/site/wp-content/debug.log
$InputFileTag wordpress-site-a:
$InputFileStateFile state-wordpress-site-a
$InputRunFileMonitor
```

## Des alertes actionnables, pas juste du bruit

Une alerte qui se déclenche trop souvent finit ignorée — c'est le piège classique du monitoring mal calibré. On a appris à distinguer ce qui mérite un réveil en pleine nuit de ce qui peut attendre le lendemain matin :

| Événement | Niveau d'alerte |
| --- | --- |
| Site inaccessible (code 5xx répété) | Immédiat, notification directe |
| Certificat SSL expirant sous 7 jours | Immédiat, avant l'expiration réelle |
| Erreur PHP fatale isolée | Résumé quotidien |
| Avertissement de dépréciation | Résumé hebdomadaire |
| Ralentissement progressif du temps de réponse | Résumé hebdomadaire, avec tendance |

Cette hiérarchisation a directement réduit la fatigue d'alerte de l'équipe : les notifications immédiates sont devenues rares et systématiquement traitées, plutôt que noyées dans un flux ininterrompu de signaux mineurs.

## Notre outillage maison

Plutôt qu'une solution de supervision commerciale complète, dont le coût grimpe vite avec le nombre de sites surveillés, on a construit un outillage léger autour de scripts planifiés via cron, combinés à WP-CLI pour les vérifications applicatives :

```
#!/bin/bash
for site in $(cat liste-sites.txt); do
  statut=$(wp --path=/var/www/$site core version 2>&1)
  if [ $? -ne 0 ]; then
    echo "ALERTE : $site inaccessible ou en erreur" | mail -s "Incident $site" equipe@agence.fr
  fi
done
```

Ce script tourne toutes les cinq minutes et vérifie qu'une commande WP-CLI basique s'exécute correctement sur chaque site du parc — un indicateur simple mais fiable que la base de données répond et que WordPress se charge sans erreur fatale.

> Le monitoring le plus utile n'est pas le plus sophistiqué, c'est celui que l'équipe consulte et à qui elle fait confiance. Un tableau de bord ignoré parce que trop bruyant vaut moins qu'un script cron simple mais respecté.

## Ce qu'on surveille en plus depuis peu

Sur les sites les plus critiques du parc, on a ajouté une vérification de l'espace disque disponible et du nombre de connexions à la base de données actives, deux indicateurs qui précèdent souvent une panne complète de plusieurs heures. Un disque plein sur un site avec beaucoup d'uploads reste, à ce jour, l'une de nos causes de panne les plus fréquentes.

## En résumé

Passer d'un site à un parc de sites change la nature du monitoring : il ne s'agit plus de vérifier qu'un site fonctionne, mais de savoir en un coup d'œil lequel, parmi trente, a besoin d'attention. Centraliser les logs, hiérarchiser les alertes et accepter que le monitoring le plus utile reste souvent le plus simple ont été nos trois leviers les plus efficaces.