Monitoring serveur : surveiller uptime et performances

Après huit ans en agence web et des centaines de sites en production, je peux affirmer une chose : le monitoring serveur n’est pas un luxe, c’est une nécessité absolue. J’ai vu des sites e-commerce perdre plusieurs milliers d’euros parce qu’une panne de 45 minutes est passée inaperçue un samedi soir. J’ai vu des blogs WordPress devenir inaccessibles pendant des heures sans que personne ne s’en rende compte. Le monitoring serveur, c’est votre filet de sécurité : il vous alerte avant que vos visiteurs ne partent, avant que Google ne dégrade votre positionnement, et avant que la situation ne devienne critique.

Pourquoi le monitoring serveur est indispensable en 2026

Quand je déployais mes premiers sites en agence, le monitoring se résumait à vérifier manuellement que le site répondait. Aujourd’hui, cette approche est totalement obsolète. Les attentes des utilisateurs ont évolué : 53 % des visiteurs mobiles quittent un site qui met plus de 3 secondes à charger. Et Google intègre désormais les Core Web Vitals comme facteur de classement, ce qui signifie que les performances de votre serveur impactent directement votre SEO.

Le monitoring serveur remplit trois fonctions critiques. D’abord, la détection proactive des pannes : être alerté en 30 secondes plutôt que de découvrir le problème après plusieurs heures change tout. Ensuite, l’optimisation continue des performances : en analysant les tendances de consommation CPU et RAM, vous anticipez les besoins de mise à l’échelle. Enfin, la documentation des incidents : avoir un historique précis facilite le diagnostic et la communication avec votre hébergeur.

Si vous gérez un serveur VPS Linux, le monitoring n’est pas optionnel. Contrairement à un hébergement mutualisé où votre hébergeur gère l’infrastructure, sur un VPS vous êtes responsable de tout : si le disque se remplit, si Apache tombe, si MySQL consomme toute la RAM, personne ne vous préviendra sauf votre outil de monitoring.

Les métriques essentielles à surveiller sur votre serveur

Toutes les métriques ne se valent pas. Après des années à affiner mes configurations de monitoring, j’ai identifié les indicateurs qui comptent vraiment pour un serveur web.

Uptime et disponibilité

L’uptime mesure le pourcentage de temps pendant lequel votre serveur est accessible. Un uptime de 99,9 % semble excellent, mais cela représente tout de même 8 heures et 46 minutes d’indisponibilité par an. Pour un site e-commerce, chaque minute compte. Je recommande de viser 99,95 % minimum, ce qui correspond à environ 4 heures et 23 minutes de downtime annuel.

Utilisation CPU

Le processeur est le cœur de votre serveur. Une utilisation moyenne au-dessus de 70 % de manière prolongée indique que vous approchez de la saturation. Les pics ponctuels sont normaux (mise à jour de cache, cron jobs), mais une charge élevée constante doit déclencher une alerte. Sur un VPS, surveillez aussi le « steal time » : si votre voisin de serveur physique consomme trop de ressources, cela affecte vos performances.

Mémoire RAM

MySQL et PHP-FPM sont les deux plus gros consommateurs de RAM sur un serveur WordPress typique. Quand la RAM est saturée, le système utilise le swap (espace disque comme mémoire), ce qui ralentit les performances d’un facteur 10 à 100. Je configure systématiquement une alerte à 85 % d’utilisation RAM pour avoir le temps de réagir.

Espace disque

Un disque plein, c’est la panne garantie. Les logs qui s’accumulent, les sauvegardes non purgées, les fichiers temporaires : tout cela grignote l’espace silencieusement. J’ai une règle simple : alerte à 80 %, action immédiate à 90 %. C’est d’autant plus important si vous gérez des sauvegardes automatiques de votre site WordPress directement sur le serveur.

Temps de réponse HTTP

Le TTFB (Time To First Byte) mesure le temps entre la requête du navigateur et le premier octet de la réponse du serveur. Un TTFB sain se situe sous les 200 ms. Au-delà de 600 ms, l’expérience utilisateur se dégrade sensiblement. Combiner cette métrique avec un CDN comme Cloudflare permet d’avoir une vision globale de la chaîne de livraison du contenu.

Trafic réseau et bande passante

Surveiller le trafic entrant et sortant permet de détecter des anomalies : une attaque DDoS, un bot qui aspire votre contenu, ou simplement un pic de trafic légitime qui nécessite d’adapter les ressources. Un pic soudain de trafic entrant sans augmentation proportionnelle du trafic web est souvent le signe d’une activité malveillante.

Monitoring externe : surveiller l’uptime et la disponibilité

Le monitoring externe vérifie votre site depuis l’extérieur, exactement comme le ferait un visiteur. C’est la première couche de surveillance à mettre en place, et la plus simple.

UptimeRobot : le standard gratuit

C’est l’outil que je recommande en priorité. La version gratuite offre 50 moniteurs avec des vérifications toutes les 5 minutes. Pour chaque moniteur, vous pouvez configurer des vérifications HTTP, HTTPS, ping, ou même vérifier qu’un mot-clé spécifique apparaît sur la page. Les alertes sont envoyées par email, SMS, Slack, Telegram ou webhook.

En pratique, je configure au minimum trois moniteurs par site : la page d’accueil en HTTPS, la page de connexion WordPress (/wp-login.php), et une page dynamique qui interroge la base de données. Si seule la page statique répond mais pas la page dynamique, cela pointe vers un problème MySQL plutôt qu’Apache.

Hetrixtools et alternatives

Hetrixtools propose un plan gratuit généreux avec 15 moniteurs uptime et des vérifications depuis 10 localisations géographiques. C’est particulièrement utile si votre audience est internationale : un serveur peut répondre parfaitement depuis Paris mais être lent depuis Montréal à cause d’un problème de routage. D’autres alternatives comme Better Stack (anciennement Better Uptime) ou Pingdom offrent des fonctionnalités premium intéressantes pour les sites critiques.

Vérification SSL et DNS

Un certificat SSL expiré, c’est un site inaccessible avec un avertissement de sécurité qui fait fuir les visiteurs. Configurez un moniteur spécifique pour votre certificat SSL Let’s Encrypt avec une alerte 30 jours avant l’expiration. De même, surveillez vos enregistrements DNS : une modification non autorisée d’un enregistrement A ou CNAME peut rediriger votre trafic vers un serveur tiers.

Monitoring interne : suivre les performances du serveur en temps réel

Le monitoring externe vous dit si votre site est accessible. Le monitoring interne vous dit pourquoi il ne l’est plus, ou pourquoi il ralentit. C’est la couche complémentaire indispensable pour tout administrateur de serveur.

Netdata : le tableau de bord temps réel

Netdata est mon outil favori pour le monitoring interne. L’installation prend littéralement une ligne de commande :

bash <(curl -Ss https://my-netdata.io/kickstart.sh)

En quelques secondes, vous obtenez un tableau de bord accessible sur le port 19999 avec des centaines de métriques collectées chaque seconde. CPU par cœur, RAM détaillée (cache, buffers, utilisée, libre), I/O disque, trafic réseau par interface, processus Apache et MySQL, et bien plus. L’interface est fluide et les graphiques interactifs permettent de zoomer sur n’importe quelle période.

Pour la sécurité, pensez à restreindre l’accès au tableau de bord Netdata. Soit via un reverse proxy Nginx avec authentification Basic, soit en limitant l’écoute à localhost et en y accédant via un tunnel SSH :

ssh -L 19999:localhost:19999 [email protected]

Prometheus et Grafana : la solution professionnelle

Pour les infrastructures plus complexes (plusieurs serveurs, conteneurs Docker, microservices), la combinaison Prometheus + Grafana est le standard de l’industrie. Prometheus collecte et stocke les métriques, tandis que Grafana offre des tableaux de bord visuels personnalisables. La courbe d’apprentissage est plus raide, mais la flexibilité est incomparable.

J’utilise cette stack pour mes clients qui gèrent plusieurs serveurs VPS : un Prometheus central collecte les métriques de tous les serveurs via des exporters (node_exporter pour les métriques système, mysqld_exporter pour MySQL), et Grafana centralise la visualisation.

Commandes Linux essentielles pour le monitoring manuel

Avant même d’installer un outil, quelques commandes Linux vous donnent une vision immédiate de l’état du serveur :

# Vue d'ensemble CPU, RAM, processus
htop

# Espace disque par partition
df -h

# Taille des répertoires (trouver ce qui prend de la place)
du -sh /var/log/*

# Connexions réseau actives
ss -tuln

# Charge système sur 1, 5 et 15 minutes
uptime

Ces commandes sont votre premier réflexe quand un outil de monitoring externe vous signale un problème. Elles permettent un diagnostic rapide en attendant d’analyser les métriques détaillées.

Comparatif des meilleurs outils de monitoring serveur

Pour vous aider à choisir, voici un tableau comparatif des solutions que j’ai testées et que je recommande en fonction de vos besoins et de votre budget.

Mon conseil : commencez par UptimeRobot (externe) + Netdata (interne). Cette combinaison est gratuite, se met en place en moins de 15 minutes, et couvre la grande majorité des besoins. Vous pourrez évoluer vers Prometheus/Grafana quand votre infrastructure grandira.

Configurer les alertes et notifications efficacement

Un outil de monitoring sans alertes bien configurées, c’est comme une alarme incendie débranchée. Mais trop d’alertes tuent l’alerte : si vous recevez 50 notifications par jour, vous finirez par toutes les ignorer. Voici ma méthode pour trouver le bon équilibre.

Définir les seuils d’alerte pertinents

Je classe mes alertes en trois niveaux de sévérité :

Niveau critique (notification immédiate SMS + email + Slack) : site down (HTTP 5xx ou timeout), espace disque supérieur à 95 %, RAM swap active depuis plus de 5 minutes, certificat SSL expiré. Ces situations exigent une intervention immédiate.

Niveau warning (notification email + Slack) : CPU au-dessus de 80 % pendant 10 minutes, RAM au-dessus de 85 %, espace disque au-dessus de 80 %, TTFB supérieur à 500 ms de manière prolongée. Ces situations nécessitent une investigation dans l’heure.

Niveau info (rapport quotidien) : tendances de consommation, nombre de requêtes, erreurs 404 fréquentes. Ces données alimentent votre prise de décision à moyen terme.

Canaux de notification multi-niveaux

La clé d’un système d’alertes efficace, c’est l’escalade progressive. Si une alerte critique n’est pas acquittée en 15 minutes, elle doit remonter automatiquement vers un second canal ou un second contact. La plupart des outils de monitoring proposent cette fonctionnalité. Better Stack (anciennement Better Uptime) excelle particulièrement dans la gestion des incidents avec des plannings d’astreinte et des escalades automatiques.

Éviter la fatigue d’alerte

Un piège classique : configurer des seuils trop bas qui déclenchent des alertes en permanence. Mon approche est de commencer avec des seuils larges et de les resserrer progressivement en fonction de votre baseline. Observez d’abord le comportement normal de votre serveur pendant une semaine, identifiez les pics habituels, puis ajustez vos seuils pour qu’ils ne se déclenchent que sur des anomalies réelles.

Monitoring spécifique pour les sites WordPress

WordPress a ses particularités qui méritent une surveillance dédiée. Quand je déploie un site WordPress sur un VPS, j’ajoute systématiquement ces vérifications à mon monitoring standard.

Surveiller WP-Cron et les tâches planifiées

WP-Cron gère les publications programmées, les mises à jour automatiques et les sauvegardes planifiées. Mais il dépend du trafic pour se déclencher : sans visiteur, pas de cron. Sur un site à faible trafic, je désactive WP-Cron et je le remplace par un vrai cron système :

# Ajouter dans crontab (crontab -e)
*/5 * * * * curl -s https://votre-site.fr/wp-cron.php?doing_wp_cron > /dev/null 2>&1

Puis je surveille que ce cron s’exécute correctement via les logs.

Surveiller les mises à jour et la sécurité

Un WordPress non mis à jour est une cible privilégiée. Je configure des alertes pour détecter les versions obsolètes du cœur, des thèmes et des extensions. Des services comme WP Umbrella ou ManageWP permettent de centraliser la surveillance de plusieurs sites WordPress avec des alertes automatiques sur les mises à jour de sécurité disponibles.

Si vous gérez plusieurs sites via WordPress multisite, cette centralisation est d’autant plus critique. Une faille sur une installation multisite compromet tous les sites du réseau.

Performances WordPress et base de données

La base de données MySQL est souvent le goulot d’étranglement des sites WordPress. Surveillez le nombre de slow queries (requêtes lentes, supérieures à 1 seconde) et la taille des tables. Une table wp_options qui dépasse 5 Mo avec des milliers de lignes en autoload indique un problème de plugins mal codés qui dégradent les performances.

Pour les sites WooCommerce, ajoutez un moniteur spécifique sur le processus de commande (ajout au panier, page checkout, validation de paiement). Un hébergement optimisé WooCommerce intègre souvent des outils de monitoring de performance déjà configurés.

Plugin Query Monitor pour le développement

En phase de développement et d’optimisation SEO technique, le plugin Query Monitor est indispensable. Il affiche en temps réel toutes les requêtes SQL, les hooks déclenchés, les erreurs PHP et le temps d’exécution de chaque composant. Ce n’est pas un outil de monitoring en production (il ralentit le site), mais c’est parfait pour identifier les sources de lenteur avant la mise en ligne.

Bonnes pratiques et tableaux de bord personnalisés

Le monitoring n’est efficace que s’il est consulté régulièrement et correctement configuré. Voici les bonnes pratiques que j’applique sur tous mes projets.

Créer une page de statut publique

Une page de statut publique (status page) renforce la confiance de vos utilisateurs. UptimeRobot et Better Stack proposent des pages de statut personnalisables et gratuites. Vous y affichez l’uptime de vos services principaux et l’historique des incidents. C’est particulièrement utile si vous proposez un SaaS ou un service web où la disponibilité est un argument commercial.

Documenter les procédures d’intervention

Chaque type d’alerte devrait être associé à une procédure de résolution documentée. Quand le disque est plein, quels répertoires purger en priorité ? Quand MySQL consomme trop de RAM, quels paramètres ajuster dans my.cnf ? Cette documentation, appelée « runbook », fait gagner un temps précieux lors des incidents, surtout si vous n’êtes pas le seul à intervenir sur le serveur.

Automatiser les réactions aux incidents courants

Certains problèmes récurrents peuvent être résolus automatiquement. Par exemple, redémarrer PHP-FPM quand il consomme trop de mémoire, ou purger les logs quand le disque dépasse 85 %. Netdata permet de déclencher des scripts personnalisés via ses alarmes. Attention toutefois : l’automatisation doit traiter les symptômes en attendant que vous corrigiez la cause, pas la remplacer.

Monitoring et choix d’hébergeur

Le niveau de monitoring intégré varie considérablement selon les hébergeurs. Les hébergeurs premium comme Kinsta ou WP Engine incluent des tableaux de bord de performance détaillés. Les hébergeurs mutualisés comme ceux comparés dans notre article OVH vs O2Switch offrent des métriques plus basiques. Sur un hébergement dédié ou VPS, tout est à configurer vous-même, mais vous avez une liberté totale.

Si votre budget est serré et que vous êtes sur un hébergement pas cher, le monitoring externe avec UptimeRobot est d’autant plus important puisque les outils intégrés sont souvent limités.

Conserver un historique des métriques

Les données de monitoring ont une valeur croissante avec le temps. En comparant les performances d’un mois sur l’autre, vous identifiez des tendances : la consommation de RAM augmente-t-elle régulièrement ? Le TTFB se dégrade-t-il progressivement ? Ces tendances vous permettent d’anticiper les besoins de mise à l’échelle et de planifier une éventuelle migration vers un hébergeur plus performant avant que la situation ne devienne critique.