Mise à jour 2025 – Supervision d’infrastructure WordPress
Un serveur WordPress peut sembler “bien marcher” pendant des semaines… jusqu’au jour où un site devient lent, que les erreurs 5xx se multiplient, ou qu’un pic de trafic fait tout tomber. Sans outils de monitoring, vous restez aveugle : difficile de savoir si le problème vient du CPU, de la RAM, du disque, de MySQL, de PHP-FPM, du réseau ou d’un plugin en particulier.
Dans ce guide, nous allons voir comment mettre en place un monitoring efficace pour un serveur WordPress : métriques essentielles à suivre, outils à installer (htop, glances, Netdata, monitoring externe), alertes, lecture des logs et méthode de diagnostic en cas de lenteurs ou de pannes.
Résumé rapide : Pour surveiller un serveur WordPress, il faut suivre la charge CPU, la RAM, l’IO disque, le réseau, PHP-FPM, MySQL/MariaDB, la disponibilité HTTP et les erreurs applicatives. Combinez des outils locaux (htop, glances, Netdata) avec un monitoring externe (uptime) et une gestion propre des logs pour détecter les problèmes avant qu’ils n’affectent vos utilisateurs.
Sommaire
1. Pourquoi le monitoring est indispensable pour un serveur WordPress
Sans monitoring, vous découvrez souvent les problèmes parce que :
- un client vous appelle pour dire que son site est lent,
- vous voyez des erreurs 5xx dans le navigateur,
- Google Search Console signale un taux d’erreurs élevé,
- ou un outil comme PageSpeed vous renvoie un TTFB catastrophique.
Avec un monitoring en place, vous pouvez :
- voir que la RAM commence à saturer,
- voir que le CPU est à 100 % à certaines heures,
- repérer des pics de requêtes MySQL ou PHP,
- être prévenu par mail ou message avant que le site ne tombe.
Pour un parc de sites, le monitoring n’est plus un luxe : c’est un outil de travail quotidien.
2. Les métriques clés à surveiller
Plutôt que d’essayer de tout surveiller, concentrez-vous sur quelques métriques essentielles :
2.1. CPU
Un CPU régulièrement à 80–100 % peut indiquer :
- trop de processus PHP-FPM simultanés,
- des requêtes MySQL trop gourmandes,
- un script mal optimisé (cron, plugin, etc.).
2.2. RAM et swap
Si la RAM est saturée et que le serveur commence à swapper, tout devient lent :
- les requêtes PHP,
- les réponses MySQL,
- les accès disque.
Surveillez :
- la RAM totale utilisée,
- l’usage du swap,
- la consommation des principaux processus (MySQL, PHP-FPM, Apache/Nginx).
2.3. Disque (I/O, espace libre)
Deux points importants :
- Espace disque : un disque plein peut casser la base SQL, empêcher les logs de s’écrire, faire échouer des mises à jour.
- I/O : un disque saturé (trop d’entrées/sorties) peut rendre tout le système très lent.
2.4. MySQL/MariaDB
Pour la base de données, surveillez au minimum :
- la charge globale (threads, requêtes par seconde),
- le temps de réponse moyen,
- les requêtes lentes (slow queries).
2.5. PHP-FPM et HTTP
Sur PHP-FPM, les signaux importants :
- nombre de processus actifs,
- erreurs
max_children reached, - timeouts.
Côté HTTP :
- taux d’erreurs 4xx/5xx,
- TTFB (Time To First Byte),
- nombre de requêtes par seconde.
3. Outils de base sur le serveur (htop, glances, logs)
Avant d’installer des dashboards avancés, quelques outils en ligne de commande sont déjà très puissants pour diagnostiquer un problème en direct.
3.1. htop
htop permet de voir :
- la charge CPU par cœur,
- la RAM utilisée,
- les processus qui consomment le plus,
- les utilisateurs associés aux processus.
En cas de lenteur, un htop en temps réel donne souvent un premier indice : explosion de PHP,
MySQL, etc.
3.2. glances
glances offre une vue d’ensemble : CPU, RAM, swap, disque, réseau, processus.
C’est très utile pour voir si le problème est :
- global (tout le système souffre),
- ou isolé à un seul service.
3.3. Logs (Apache/Nginx, PHP, MySQL)
Les logs restent une source d’information précieuse :
- Logs web (Apache/Nginx) : erreurs 500, 502, 504, 403, etc.
- Logs PHP : erreurs fatales, warnings massifs, problèmes de mémoire.
- Logs MySQL : erreurs de connexion, corruptions, slow query log.
Une bonne politique de logrotate permet de garder les logs lisibles sans saturer le disque.
4. Monitoring temps réel avec Netdata (ou équivalent)
Pour une vision plus confortable et historique de votre serveur, des outils comme Netdata offrent :
- un tableau de bord web avec graphiques temps réel,
- des métriques détaillées (CPU, mémoire, I/O, MySQL, Nginx/Apache, etc.),
- des alertes prédéfinies.
4.1. Vue d’ensemble du serveur
Un dashboard comme Netdata permet :
- de voir les pics d’activité passés (pas seulement l’instant présent),
- de corréler un pic CPU à un pic de requêtes web ou SQL,
- de repérer des comportements anormaux (processus qui consomme trop, etc.).
4.2. Multi-serveurs
Si vous avez plusieurs serveurs (prod, préprod, tests ou plusieurs VPS), vous pouvez :
- installer Netdata sur chacun,
- ou déployer une stack Prometheus/Grafana plus avancée.
L’idée est de conserver une vue globale : quels serveurs souffrent, à quel moment, et pourquoi.
5. Monitoring externe : uptime, latence et alertes
Le monitoring interne (sur le serveur) ne suffit pas. Il faut aussi un monitoring externe qui vérifie que le site répond bien depuis l’extérieur :
- Uptime (site accessible ou non),
- Temps de réponse moyen,
- Erreur HTTP (500, 502, 503, etc.).
Des services d’uptime (gratuits ou payants) peuvent :
- vérifier vos sites toutes les X minutes,
- vous alerter par email, SMS ou webhook si un site tombe,
- conserver un historique de disponibilité.
Pour un parc de sites, cela permet de savoir :
- si un seul site est affecté (problème local),
- ou si plusieurs domaines sont indisponibles (problème serveur ou réseau).
6. Mettre en place des alertes et des procédures simples
Le monitoring n’a de valeur que si les alertes sont utiles et gérées. Quelques bonnes pratiques :
- Configurer des alertes sur :
- down du site (HTTP 5xx),
- CPU trop élevé pendant trop longtemps,
- RAM ou swap saturé,
- disque à plus de 80–90 %.
- Définir une adresse email “technique” (ou un canal Slack/Discord) pour les alertes.
- Éviter le spam d’alertes : des seuils trop sensibles deviennent vite inutiles.
Important : définissez une procédure simple à suivre quand vous recevez une alerte : vérifier le monitoring interne, les logs, et consigner ce qui a été fait pour résoudre le problème.
7. Méthode de diagnostic en cas de lenteurs ou d’erreurs
Quand un site devient lent ou renvoie des erreurs, il est utile d’avoir une méthode de diagnostic plutôt que de “cliquer partout au hasard”. Par exemple :
- Étape 1 – Vérifier l’uptime externe : le site répond-il ? Si non, erreur HTTP ?
- Étape 2 – Regarder la charge serveur (htop/glances) : CPU, RAM, swap, I/O.
- Étape 3 – Vérifier les logs Apache/Nginx et PHP : erreurs récentes, 500, 502, etc.
- Étape 4 – Vérifier MySQL : slow queries, connexions saturées.
- Étape 5 – Tester un site simple sur le même serveur : problème global ou spécifique à un site ?
En appliquant la même méthode à chaque incident, vous gagnez du temps et vous accumulez de l’expérience utile pour les cas suivants.
FAQ – Monitoring & WordPress
Un petit serveur avec quelques sites WordPress a-t-il besoin de monitoring ?
Oui, même un petit serveur mérite un minimum de supervision. Un simple uptime externe et un outil comme Netdata ou glances peuvent vous éviter de mauvaises surprises, surtout si des clients comptent sur ces sites.
Monitoring interne ou externe : lequel est le plus important ?
Les deux se complètent. Le monitoring interne vous dit ce qui se passe sur la machine (CPU, RAM, etc.). Le monitoring externe vous dit si les utilisateurs peuvent accéder au site. Pour prendre de bonnes décisions, vous avez besoin des deux.
Est-ce que le monitoring peut impacter les performances du serveur ?
Un monitoring bien configuré consomme très peu de ressources. Certains outils peuvent être plus lourds, mais en pratique, le bénéfice dépasse largement le coût, surtout si vous hébergez plusieurs sites.
Dois-je surveiller chaque site WordPress séparément ?
Pour l’uptime, oui : chaque domaine doit être testé. Pour les métriques système (CPU, RAM, etc.), une vue globale par serveur suffit. Ensuite, vous pouvez affiner si certains sites sont plus critiques que d’autres.
Le monitoring remplace-t-il les logs ?
Non, le monitoring donne une vue macro (graphes, alertes), alors que les logs sont nécessaires pour comprendre précisément ce qui s’est passé (erreurs, requêtes, détails techniques). Les deux sont complémentaires.
Conclusion : voir les problèmes avant vos utilisateurs
Mettre en place un monitoring pour un serveur WordPress, c’est accepter que des problèmes arriveront tôt ou tard, mais décider de les voir venir plutôt que de les subir. En surveillant les métriques clés, en installant des outils adaptés, en configurant des alertes raisonnables et en appliquant une méthode de diagnostic, vous transformez les incidents en simples événements techniques gérables.
Combiné aux bonnes pratiques de configuration serveur (CPU/RAM/stockage adaptés), de tuning PHP-FPM, de MySQL/MariaDB et de cache (Redis, Cloudflare), le monitoring devient un pilier de votre plateforme WordPress professionnelle. Il vous permet de garantir à vos clients – ou à vos propres projets – un niveau de fiabilité et de performance bien supérieur à un simple hébergement “par défaut”.
