Monitoring serveur et monitoring du site web ne répondent pas à la même question. Le premier observe la machine : processus, CPU, mémoire, disque, parfois la file du serveur web. Le second envoie une requête comme un visiteur, depuis un réseau qui n’est pas le vôtre, et juge la réponse. Un tableau de charge à 10 % ne dit rien sur une redirection cassée. Un code 200 ne dit rien sur un disque plein qui plantera au prochain upload.
Ce que mesure un agent sur la machine
L’agent est installé sur le serveur, ou il interroge l’hyperviseur et les journaux locaux. Il peut relever :
- la charge CPU et la mémoire disponible ;
- l’espace disque et les inodes ;
- l’état d’un processus (php-fpm, nginx, mysql) ;
- le nombre de connexions ouvertes vers la base.
Ces chiffres expliquent une lenteur dont la cause est interne. Ils ne traversent pas le DNS public, ni le pare-feu, ni le certificat que le navigateur va accepter ou refuser. Si le nom de domaine pointe ailleurs, l’agent continue de voir « sa » machine en bonne santé, et les visiteurs, une autre.
Sur un hébergement mutualisé, vous n’avez en général pas cet agent. Le graphe du panneau est celui de l’hébergeur. Il reste utile pour lui, pas comme preuve de ce que votre URL renvoie.
Ce que voit une requête venue de l’extérieur
Le contrôle de site web part d’un point hors de votre réseau. Il résout le nom, ouvre TLS, envoie la requête HTTP, suit les redirections, puis lit le code, le délai et un extrait du corps. C’est le parcours décrit dans la définition du monitoring de site web.
Ce parcours échoue alors que la machine est saine dans plusieurs cas concrets :
- le certificat expire demain, le processus nginx tourne ;
- une règle renvoie 301 vers une URL qui boucle ;
- PHP affiche une erreur fatale : le système d’exploitation n’a pas « planté », la page si ;
- un pare-feu bloque le pays ou le réseau d’où vient le contrôle ;
- le CDN sert une ancienne page pendant que l’origine est arrêtée, ou l’inverse.
À l’opposé, le disque à 95 % ne change pas encore le code HTTP. L’agent le voit. Le contrôle de page, non, jusqu’au moment où une écriture échoue et où le site commence à répondre 500.
Lire les deux résultats côte à côte
| Constat | Agent serveur | Requête extérieure |
|---|---|---|
| CPU saturé | visible tout de suite | visible seulement si le temps de réponse monte |
| Erreur PHP | dans le journal, si on le lit | code 500 ou page d’erreur |
| Certificat expiré | souvent rien | échec TLS |
| Disque presque plein | visible | rien, tant que la page est en lecture |
| Mauvais enregistrement DNS | la machine est inchangée | le contrôle n’atteint pas cette machine |
Pendant un incident, commencez par le symptôme du visiteur : code, certificat, redirection, corps. Le test d’URL donne ce relevé sans ouvrir une session sur le serveur. Ensuite seulement, si le temps de réponse ou les 500 collent à une saturation, ouvrez l’agent.
Confondre les deux mène à de mauvaises conclusions. « Le serveur est vert » ne clôt pas un ticket de page blanche. « Le site répond 200 » ne dispense pas de surveiller le disque si vous gérez la machine.
Qui surveille quoi
L’hébergeur surveille son infrastructure pour tenir son propre engagement. Il ne vérifie pas que votre formulaire contient encore le bon titre, ni qu’une mise à jour n’a pas ajouté une redirection. Ce deuxième contrôle vous appartient, même quand le premier est inclus dans l’offre.
SiteGarde se place du côté de la requête extérieure. Il ne remplace pas un agent système, et un agent ne le remplace pas. Si vous n’avez pas la main sur le serveur, le parcours HTTP est de toute façon le seul que vous pouvez mesurer vous-même. S’il vous manque le rappel de la méthode manuelle, le guide tester la disponibilité détaille les quatre contrôles à enchaîner.