Bonnes pratiques de surveillance serveur
Guide pratique des bonnes pratiques de surveillance serveur — que surveiller, comment régler les seuils et comment éviter la fatigue d'alerte dans votre équipe.
Une bonne surveillance vous prévient qu'un problème existe avant vos utilisateurs — et reste silencieuse le reste du temps. Ce guide couvre les bonnes pratiques de surveillance serveur qui comptent vraiment : quoi surveiller, où placer les seuils, et comment garder des alertes pertinentes pour que votre équipe ne finisse pas par les ignorer.
Si vous n'avez encore rien configuré, commencez par Créer un moniteur — ou lancez-vous directement : créer un moniteur dans Servor.
Surveillez de l'extérieur et de l'intérieur
Les deux points de vue répondent à des questions différentes, et il vous faut les deux.
- De l'extérieur (disponibilité) — le service est-il joignable et répond-il correctement ? Ce sont vos moniteurs HTTP, TCP, ping, DNS et SSL. Ils détectent les pannes que vos utilisateurs ressentent réellement : un site en panne, un certificat expiré, un changement DNS mal passé.
- De l'intérieur (ressources) — la machine elle-même est-elle en bonne santé ? Les métriques de ressources (CPU, RAM, disque) proviennent de l'agent et vous alertent avant la panne — un disque qui se remplit ou une pression mémoire qui monte est un problème que l'on corrige à froid, pas à 3 h du matin.
Règle générale
Chaque service exposé mérite au moins un moniteur externe. Chaque serveur qui exécute l'agent mérite des métriques de ressources. C'est dans le recouvrement des deux que vous obtenez à la fois l'alerte précoce et la confirmation de l'impact utilisateur.
Que surveiller en premier
Inutile de tout surveiller dès le premier jour. Couvrez l'essentiel, puis élargissez.
Le service que vos utilisateurs consultent
Ajoutez un moniteur HTTP sur votre URL principale.
Utilisez une vérification par mot-clé pour qu'une page renvoyant 200 mais affichant
une erreur soit tout de même comptée comme en panne.
Votre certificat SSL
Ajoutez un moniteur de certificat SSL pour être prévenu des semaines avant l'expiration — et non par un avertissement de sécurité que vos clients voient en premier dans leur navigateur.
La machine qui héberge le tout
Activez les métriques de ressources du serveur pour rendre visibles les tendances CPU, RAM et disque. Voyez Lire les métriques serveur pour comprendre ce que signifient ces chiffres.
Les dépendances
Bases de données, caches, files de messages, API tierces — un moniteur TCP/port sur chacune confirme que ce dont dépend votre application écoute bien.
Régler des seuils qui veulent dire quelque chose
Un seuil qui se déclenche sans arrêt n'est que du bruit ; un seuil qui ne se déclenche jamais n'est que décoration. Visez le juste milieu.
| Signal | Point de départ raisonnable | Pourquoi |
|---|---|---|
| CPU | Alerter sur une charge élevée soutenue, pas sur de brefs pics | Les rafales courtes sont normales ; un CPU saturé plusieurs minutes ne l'est pas |
| RAM | Surveiller la tendance, alerter proche de la capacité | Une montée lente signale souvent une fuite — attrapez-la tôt |
| Disque | Alerter bien avant le plein (garder de la marge) | Un disque plein fait tomber les services brutalement et se récupère lentement |
| Vérification de disponibilité | Un intervalle court pour les services critiques | Des vérifications plus fréquentes détectent les pannes plus vite |
La durée prime sur l'instant
Chaque fois que possible, alertez sur une condition qui persiste plutôt que sur une seule mauvaise lecture. « CPU élevé pendant plusieurs minutes » est un vrai problème ; « CPU élevé sur une vérification » n'est souvent qu'une tâche cron. Réglez les seuils du serveur depuis les paramètres du serveur (icône engrenage → seuils de surveillance).
Éviter la fatigue d'alerte
La fatigue d'alerte est le vrai mode d'échec de la surveillance : quand tout sonne, les gens arrêtent de lire, et celle qui comptait passe à la trappe. Gardez vos alertes rares et dignes de confiance.
- Alertez sur les symptômes, pas sur chaque cause. Un seul « le site est en panne » vaut mieux que cinq alertes pour chaque sous-composant tombé avec lui.
- Utilisez les temporisations (cooldowns). Les canaux de notification prennent en charge une temporisation pour qu'un service instable n'envoie pas cinquante messages en une minute.
- Routez par urgence. Envoyez les alertes critiques (celles qui réveillent) vers un canal réellement surveillé ; envoyez les informatives ailleurs, plus au calme. Email, Slack, Discord et Webhook sont tous disponibles comme canaux.
- Ajustez, ne coupez pas. Si une alerte crie au loup en permanence, corrigez le seuil ou l'instabilité sous-jacente. Couper une alerte bruyante vous entraîne à en ignorer une vraie plus tard.
- Révisez régulièrement. Chaque alerte qui s'est déclenchée sans nécessiter d'action est candidate à un assouplissement. Chaque incident dont un utilisateur vous a informé est un moniteur qui vous manquait.
Un seul canal est un point de défaillance unique
Si toutes les alertes arrivent dans une seule boîte et que cette boîte est en sourdine le week-end, votre surveillance est éteinte le week-end. Configurez au moins deux canaux de notification pour tout ce qui est critique. Configurer les canaux de notification dans Servor
Boucler la boucle avec les pages de statut et les incidents
Une surveillance qui ne prévient que votre équipe n'est qu'un demi-système. Quand quelque chose casse :
- Une page de statut avec des composants liés à vos moniteurs se met à jour toute seule, si bien que les utilisateurs voient la vérité sans écrire au support.
- Les incidents automatiques peuvent s'ouvrir dès la transition en panne d'un moniteur, offrant une chronologie publique dès le début du problème.
- Le copilote IA peut investiguer un serveur signalé et proposer un correctif, que vous approuvez avant son exécution.