Une erreur 500 apparaît sur un site client. Le réflexe naturel consiste à consulter le journal d’erreur nginx, qui indique qu’une requête PHP a échoué sans plus de détail. Il faut ensuite ouvrir le journal PHP-FPM, qui pointe vers un fichier précis mais reste avare sur le contexte métier. Enfin, le journal de débogage WordPress, s’il est activé, révèle la véritable cause : une extension incompatible qui appelle une fonction supprimée. Trois fichiers, trois formats, pour comprendre un seul incident.
Cette dispersion est le comportement par défaut de la pile WordPress classique, chaque composant journalisant dans son coin sans coordination. Sur un site isolé, ce n’est qu’un inconfort. Sur un parc de dizaines de sites hébergés sur plusieurs serveurs, cela devient un vrai frein au diagnostic rapide, surtout en pleine astreinte.
Les trois journaux à connaître
Le journal d’accès et d’erreur nginx se trouve typiquement dans /var/log/nginx/, avec un fichier par site si la configuration a défini des chemins de logs spécifiques par bloc serveur — une bonne pratique trop souvent négligée au profit du fichier global partagé, illisible dès que plusieurs sites cohabitent.
Le journal PHP-FPM, configuré dans le fichier de pool via la directive php_admin_value[error_log], capture les erreurs au niveau de l’interpréteur PHP lui-même, avant même que WordPress n’ait pu les traiter.
Le journal WordPress, activé via WP_DEBUG_LOG, capture les erreurs et avertissements générés au niveau de l’application : fonctions dépréciées, requêtes SQL en échec, erreurs de plugin.
Uniformiser le format avant de centraliser
Centraliser des logs dans des formats hétérogènes ne résout rien : il faut d’abord uniformiser autant que possible. Pour nginx, un format de log personnalisé au format JSON facilite grandement l’ingestion par un outil de centralisation :
log_format json_combined escape=json
'{"time":"$time_iso8601","remote_addr":"$remote_addr",'
'"request":"$request","status":"$status",'
'"host":"$host","request_time":"$request_time"}';
access_log /var/log/nginx/access.json json_combined;
Ce format structuré permet ensuite de filtrer facilement par domaine, par code de statut, ou par temps de réponse, plutôt que de parcourir des lignes de texte libre à la recherche d’un motif.
Centraliser à l’échelle d’un parc de sites
Pour un serveur unique hébergeant plusieurs sites, un simple script qui agrège les journaux pertinents autour d’un horodatage donné peut suffire en cas d’incident isolé. Dès que le parc s’étend sur plusieurs serveurs, un outil dédié à la centralisation de logs devient nécessaire :
- Grafana Loki, léger et bien intégré à un stack de supervision existant sous Grafana.
- ELK (Elasticsearch, Logstash, Kibana), plus complet mais plus lourd à opérer pour un petit parc.
- Un simple envoi centralisé via
rsyslogvers un serveur de logs dédié, pour un besoin plus modeste.
Rechercher efficacement un incident précis
Une fois les logs centralisés, une recherche par plage horaire et par nom de domaine permet de reconstituer la chronologie d’un incident en quelques secondes plutôt qu’en ouvrant successivement trois fichiers sur trois serveurs différents. Une requête typique dans Loki, par exemple, filtre directement sur le site concerné et sur les codes d’erreur 5xx :
{job="nginx", host="exemple.fr"} |= "\"status\":\"5"Un incident qui prend deux heures à diagnostiquer faute de logs centralisés coûte souvent plus cher en temps d’ingénieur que la mise en place initiale de l’outil de centralisation. C’est un investissement qui se rentabilise dès le premier incident sérieux.
En résumé
Centraliser les logs d’un parc WordPress n’est pas un luxe réservé aux grandes infrastructures : c’est un gain de temps immédiat dès que plus d’un ou deux sites sont en jeu. Uniformiser le format des journaux, choisir un outil de centralisation adapté à la taille réelle du parc, et structurer les requêtes de recherche par site transforment un diagnostic de plusieurs heures en une opération de quelques minutes.
