Types de moniteurs

Servor propose plusieurs types de moniteurs, chacun conçu pour vérifier une couche différente de votre infrastructure. Choisir le bon type fait toute la différence entre un moniteur qui détecte les vrais problèmes et un moniteur qui crie au loup. Cette page explique chaque type et quand l'utiliser.

Nouveau dans la surveillance ? Commencez par créer un moniteur — c'est là que vous choisissez le type.

Les types en un coup d'œil

Type	Vérifie	Idéal pour
HTTP(S)	Une URL répond avec le code de statut attendu	Sites web, API, applications web
TCP / port	Un port TCP accepte une connexion	Bases de données, SSH, mail, serveurs de jeu
Ping (ICMP)	Un hôte répond au ping	Joignabilité de base d'une machine
DNS	Un domaine résout vers l'enregistrement attendu	Domaines, migrations DNS
Certificat SSL	Un certificat est valide et n'expire pas bientôt	Sites HTTPS, éviter les pannes d'expiration
Mot-clé	Une page contient (ou non) un texte donné	Détecter pages d'erreur, défiguration, contenu
Heartbeat (push)	Votre tâche nous appelle — c'est le silence qui alerte	Cron, sauvegardes, imports, jobs planifiés
Métrique agent	Un seuil sur le CPU, la RAM, le swap, le disque ou la charge déjà remontés	Surveiller les ressources sans lancer la moindre commande

HTTP(S)

Le type le plus courant. Servor envoie une requête HTTP ou HTTPS vers une URL et vérifie la réponse. Utilisez-le pour tout ce qui parle HTTP — un site vitrine, un tableau de bord, une API REST, un endpoint de health-check.

Un bon moniteur HTTP pointe vers une URL peu coûteuse et représentative. Un endpoint /health dédié qui interroge votre base de données est bien plus utile que la page d'accueil, car il échoue quand ce qui compte vraiment échoue.

TCP / port

Vérifie qu'un port donné accepte une connexion TCP sur un hôte — sans dialoguer avec le protocole qui tourne dessus. Utilisez-le pour les services qui ne sont pas en HTTP : une base PostgreSQL ou MySQL (5432 / 3306), SSH (22), SMTP (25 / 587), Redis (6379), ou un serveur de jeu.

Un moniteur TCP vous indique que le service écoute. Il ne vous dit pas qu'il est sain à l'intérieur — pour cela, préférez une vérification HTTP ou mot-clé quand le service le permet.

Ping (ICMP)

Envoie un echo ICMP (un « ping ») et attend une réponse. C'est la vérification de joignabilité la plus légère : l'hôte est-il en ligne et accessible sur le réseau, tout simplement ? Utilisez-le comme signal grossier pour une machine ou un équipement réseau.

DNS

Résout un domaine et vérifie qu'il renvoie l'enregistrement attendu. Utilisez-le pour détecter directement les problèmes DNS — un enregistrement disparu, une mauvaise propagation après un changement, ou un souci chez le registrar. C'est particulièrement pratique pendant une migration DNS ou la configuration d'un domaine personnalisé, quand vous voulez confirmer que le nouvel enregistrement est actif partout.

Certificat SSL

Vérifie que le certificat servi sur un hôte HTTPS est valide et ne va pas expirer bientôt. Les certificats expirés sont l'une des pannes les plus courantes et les plus évitables — un certificat arrive à échéance en silence et chaque visiteur reçoit un avertissement de son navigateur.

Un moniteur SSL vous prévient en amont de l'expiration, pour renouveler à temps. Ajoutez-en un pour chaque domaine HTTPS qui compte, y compris le domaine personnalisé de votre page de statut.

Mot-clé

Récupère une page et vérifie la présence (ou l'absence) d'un texte précis. Cela détecte des pannes qu'un code de statut manque : une page qui renvoie 200 OK mais affiche un message d'erreur, une bannière de maintenance, ou une page blanche/défigurée.

Motifs courants :

• Doit contenir un mot attendu sur une page saine (ex. le nom de votre produit, "Se connecter").
• Ne doit pas contenir une chaîne d'erreur (ex. "500", "Service Unavailable", "En maintenance").

Vérifier un champ JSON

Quand l'endpoint répond en JSON, le texte brut est un instrument grossier : "ok" apparaît peut-être ailleurs dans la réponse. Renseignez plutôt un champ JSON et la valeur attendue — par exemple le champ status valant healthy, ou services[0].state valant up.

La syntaxe accepte les clés pointées et les index numériques (data.checks[2].name). C'est volontairement limité : les jokers et les filtres n'existent pas, parce qu'un chemin qui ne correspond à rien doit échouer franchement plutôt que de valider silencieusement quelque chose d'autre. Si la réponse n'est pas du JSON valide, ou si le champ est absent, le moniteur passe en panne.

Heartbeat (push)

Le seul moniteur qui ne sonde rien. Tous les autres posent une question et lisent une réponse ; celui-ci attend un appel. Votre tâche — un cron, une sauvegarde, un import nocturne — appelle une URL privée quand elle a terminé. Tant que l'appel arrive, le moniteur reste au vert ; si le silence dépasse le délai que vous avez fixé, l'alerte part.

C'est la seule façon de détecter ce genre de panne. Quand une tâche planifiée cesse discrètement de tourner, rien ne tombe : aucun port ne ferme, aucune page ne renvoie d'erreur, et tous les autres checks de la machine restent au vert.

À la création du moniteur, Servor affiche la ligne à ajouter à la fin de votre tâche :

curl -fsS -m 10 https://api.servor.app/public/heartbeat/VOTRE_JETON

Les options comptent : -f fait échouer la commande sur une erreur HTTP, -sS reste silencieux en cas de succès (pour que cron ne vous envoie pas un mail à chaque exécution) tout en affichant les vraies erreurs, et -m 10 évite qu'une requête qui traîne ne retarde la tâche à laquelle elle est attachée.

Un moniteur qui n'a jamais reçu d'appel est considéré en panne, et non « inconnu » : dès l'instant où il existe, la tâche qu'il représente est censée appeler.

Métrique agent

Un seuil sur une valeur que l'agent remonte déjà : CPU, RAM, swap, espace disque ou charge moyenne. C'est le seul contrôle qui ne lance aucune commande sur la machine — il lit le relevé arrivé quelques secondes plus tôt.

Ça change deux choses. C'est gratuit en ressources : là où un moniteur d'espace disque lance un df, celui-ci consulte une ligne déjà en base. Et surtout, il continue de fonctionner quand la machine est trop chargée pour lancer un shell — précisément le moment où vous voulez être prévenu.

Les seuils sont des nombres, pas des pourcentages, parce que la charge moyenne n'en est pas un : une charge de 4 sature une machine à 4 cœurs et laisse une machine à 32 cœurs au repos. Pour le CPU, la RAM, le swap et le disque, ce nombre se lit bien comme un pourcentage ; pour la charge, c'est la charge.

Quel type choisir ?

• Un site web ou une API → HTTP(S), idéalement sur un endpoint de santé.
• Une page qui peut renvoyer 200 tout en étant cassée → ajoutez un moniteur mot-clé.
• Une base de données, SSH, mail ou autre service non-HTTP → TCP / port.
• Simplement « la machine est-elle joignable ? » → ping (sauf si l'ICMP est bloqué).
• Un domaine ou un changement DNS → DNS.
• Tout certificat HTTPS → certificat SSL, pour anticiper l'expiration.
• Le CPU, la RAM, le swap, le disque ou la charge d’une machine → métrique agent : rien à exécuter, et ça alerte encore quand la machine est saturée.

Il est normal de faire tourner plusieurs types sur un même service — par exemple un moniteur HTTP pour l'application, un moniteur SSL pour son certificat, et un moniteur TCP pour sa base de données. Une fois le type choisi, créez le moniteur dans Servor.

Étapes suivantes