Un bon seuil d’alerte serveur se déclenche quand quelqu’un doit agir, et reste silencieux le reste du temps. En pratique, cela veut dire alerter sur des valeurs durables plutôt que sur des pics isolés, mesurer la charge par cœur de CPU plutôt qu’en valeur brute, surveiller la mémoire disponible et le swap plutôt que la « RAM utilisée », alerter tôt sur l’espace disque et sur la vitesse à laquelle il se remplit, et considérer chaque redémarrage imprévu comme une information utile. Séparez les alertes en un niveau d’avertissement pour les heures ouvrées et un niveau critique qui peut réveiller quelqu’un, et revoyez les valeurs après chaque incident.
Ce guide passe en revue chaque métrique, explique à quoi ressemble un seuil pertinent et se termine par un tableau de valeurs de départ. Ce sont des points de départ, pas des règles : chaque serveur a sa propre normalité, et le bon seuil est celui qui lui correspond.
À quoi sert un seuil
Chaque alerte coûte de l’attention. Une alerte qui se déclenche sans exiger d’action apprend aux équipes à ignorer la suivante, et la suivante sera peut-être la bonne. Avant de fixer un seuil, répondez à trois questions :
Qu’est-ce qui va casser si cette valeur continue sur sa lancée, et dans combien de temps ?
Que ferait concrètement la personne qui reçoit l’alerte ?
Est-ce que cela peut attendre le lendemain matin ?
Si rien ne casse et que personne n’agirait, c’est un graphique, pas une alerte. Si cela peut attendre le matin, c’est un avertissement. Seul ce qui ne peut pas attendre doit faire sonner un téléphone la nuit.
Niveaux d’avertissement et critique
Deux niveaux par métrique conviennent à la plupart des équipes :
Avertissement : quelque chose évolue dans le mauvais sens. Envoyez-le par e-mail ou dans un canal de discussion d’équipe et traitez-le pendant les heures ouvrées.
Critique : une panne est imminente ou en cours. Envoyez-la en notification push à la personne d’astreinte, de jour comme de nuit.
Si votre outil de surveillance ne propose qu’un seuil par métrique, vous obtenez le même effet avec le routage : placez le seuil là où une action est nécessaire et choisissez le canal serveur par serveur. Une alerte disque sur une machine de staging peut partir par e-mail ; la même alerte sur la base de données de production peut aller dans le canal de l’équipe d’astreinte. Avec Uptimecheck, les notifications se choisissent par moniteur, ce qui rend cette répartition simple. Grâce aux plannings d’astreinte, les alertes push atteignent la personne d’astreinte à cet instant, et l’escalade peut retenir un canal de 5 à 60 minutes pour n’alerter que si le problème persiste et que personne ne l’a pris en charge.
La durée compte plus que les pics
La source de bruit la plus courante, c’est l’alerte sur une seule mesure. Un CPU à 100 % pendant dix secondes lors d’un déploiement, d’une sauvegarde ou d’une reconstruction de cache, c’est normal. Un CPU à 100 % pendant vingt minutes, ça ne l’est pas. Partout où votre outil le permet, ajoutez une durée : « au-dessus de 90 % pendant 10 minutes » plutôt que « au-dessus de 90 % ».
Sinon, utilisez des métriques déjà lissées dans le temps. La charge moyenne sur 15 minutes en est un bon exemple : une courte rafale la fait à peine bouger, alors qu’une surcharge durable la fait monter et l’y maintient.
CPU
Un CPU élevé n’est en soi que rarement un problème. Un serveur occupé est un serveur qui fait son travail. Le CPU devient un problème quand il reste saturé assez longtemps pour que les requêtes s’accumulent et que les temps de réponse grimpent. Alertez sur une utilisation durable, et regardez-la en même temps que les temps de réponse de vos vérifications de disponibilité. Si le CPU est à 95 % et que les temps de réponse restent stables, le serveur est occupé, pas en panne.
Charge moyenne par cœur
Sous Linux, la charge moyenne correspond à peu près au nombre de processus en cours d’exécution ou en attente du CPU, et sous Linux aussi de ceux qui attendent des E/S disque, en moyenne sur 1, 5 et 15 minutes. Une charge brute de 4 ne veut rien dire en soi : sur un serveur à 16 cœurs, c’est peu ; sur un serveur à 2 cœurs, c’est le double de ce que la machine peut absorber. Divisez par le nombre de cœurs avant de comparer, nombre que vous donne nproc.
La valeur sur 1 minute réagit vite et fluctue beaucoup. Servez-vous-en pour le diagnostic, pas pour les alertes.
C’est sur la valeur à 15 minutes qu’il faut alerter. Au-dessus de 1 par cœur, le travail s’accumule ; nettement au-dessus, et pendant longtemps, les utilisateurs le ressentent.
Une charge élevée avec un CPU faible signifie généralement des processus qui attendent le disque ou un stockage réseau. Regardez les E/S, pas le code.
RAM et swap
La « RAM utilisée » est une métrique trompeuse sous Linux. Le noyau utilise la mémoire libre pour le cache de fichiers et la rend quand les applications en ont besoin : un serveur en bonne santé affiche donc souvent une mémoire presque pleine. Regardez plutôt la mémoire disponible, la colonne « available » de free -m, qui inclut le cache récupérable.
Le swap en dit davantage. Un serveur qui n’utilise normalement pas de swap et qui commence à le faire est sous pression mémoire, et les performances chutent nettement dès que de la mémoire active est paginée sur disque. Deux signaux utiles :
De l’utilisation du swap qui apparaît ou augmente sur un serveur qui n’en a habituellement pas.
Une mémoire disponible qui baisse régulièrement sur plusieurs jours, souvent le signe d’une fuite dans un processus de longue durée.
Les serveurs de bases de données sont un cas à part : ils sont configurés pour utiliser volontairement la plus grande partie de la mémoire. Fixez leurs seuils à partir de ce que vous observez sur une semaine normale.
Espace disque et croissance
Un disque plein est l’une des causes les plus fréquentes de pannes évitables. Les bases de données cessent d’écrire, les logs ne tournent plus, les sessions ne peuvent plus être enregistrées et les sauvegardes échouent. Le disque est aussi la métrique la plus facile à bien régler, car elle évolue rarement vite, ce qui laisse le temps d’agir si vous alertez tôt.
Utilisez un seuil en pourcentage pour l’avertissement et le niveau critique, mais adaptez-le à la taille. Sur un volume de 2 To, 10 % d’espace libre représentent encore 200 Go ; sur un volume de 20 Go, cela fait 2 Go, qu’un seul log incontrôlé peut engloutir en un après-midi.
Surveillez la croissance autant que le niveau. Un disque à 70 % qui a pris 10 points cette semaine est plus urgent qu’un disque resté à 85 % depuis un an.
Sachez ce qui le remplit : logs, sauvegardes conservées en local, fichiers téléversés, images Docker, fichiers de base de données. Chacun appelle une solution différente.
Réseau
Il est difficile de fixer un seuil fixe pour le trafic réseau, car la normale varie selon l’heure de la journée et la saison. Deux schémas méritent une alerte. Un trafic très au-dessus du niveau habituel, proche de la capacité du lien, peut signaler un pic de trafic, un scraper ou une attaque. Un trafic qui tombe presque à zéro sur un serveur habituellement chargé peut signifier qu’il a été retiré du load balancer ou qu’il a perdu son réseau, même si la machine elle-même semble aller bien. Apprenez la plage normale à partir de quelques semaines d’historique avant de fixer des valeurs.
Redémarrages
Un redémarrage imprévu mérite toujours d’être connu. Il peut s’agir d’une mise à jour du noyau, d’une maintenance de l’hébergeur, d’un crash ou d’un manque de mémoire. Même quand tout revient, des services qui ne sont pas configurés pour démarrer au boot, des tâches planifiées prévues pendant le redémarrage et des volumes montés peuvent rester dans un mauvais état. Alertez sur chaque redémarrage hors fenêtre de maintenance, au niveau avertissement si le serveur s’est rétabli tout seul.
Valeurs de départ
Les valeurs ci-dessous sont des exemples de points de départ pour un serveur web ou applicatif classique. Utilisez-les pendant les premières semaines, puis ajustez-les à ce que vous observez.
MétriqueAvertissement (exemple)Critique (exemple)CPUAu-dessus de 85 % pendant 15 minutesAu-dessus de 95 % pendant 15 minutes, avec des temps de réponse en hausseCharge moyenne (15 min)Au-dessus de 1 par cœurAu-dessus de 2 par cœurMémoire disponibleEn dessous de 15 %En dessous de 5 %SwapToute utilisation sur un serveur qui n’en a normalement pasPlus de 50 % du swap utiliséDisqueAu-dessus de 80 %, ou plein d’ici une semaine au rythme actuelAu-dessus de 90 %, ou plein d’ici une journéeRéseauNettement hors de la plage normale pour l’heure de la journéeProche de la capacité du lien, ou proche de zéro sur un serveur chargéRedémarrageTout redémarrage hors fenêtre de maintenanceDes services ne sont pas revenus après un redémarrage
La surveillance de serveurs d’Uptimecheck remonte le CPU, la mémoire, le disque et le réseau chaque minute sous Linux, macOS et Windows. Vous définissez des seuils pour le CPU, la mémoire et le disque serveur par serveur, avec une durée comme 5 ou 15 minutes, et vous êtes aussi alerté en cas de redémarrage et lorsqu’un serveur cesse d’émettre : une machine qui ne remonte plus rien n’est donc jamais confondue avec une machine tranquille. Pour comprendre pourquoi ces valeurs comptent, lisez garder votre site en ligne grâce à la surveillance de l’état des serveurs.
Surveillez aussi les symptômes
Les métriques serveur décrivent des causes. Vos utilisateurs, eux, subissent des symptômes : pages lentes, erreurs et tâches qui échouent. Surveillez les deux. Une vérification de disponibilité avec validation de la réponse vous indique quand le site tombe, et un heartbeat vous indique quand la sauvegarde ne s’est pas terminée. Quand une alerte de symptôme et une alerte de ressource se déclenchent ensemble, la cause est généralement évidente. Quand seule l’alerte de ressource se déclenche, vous avez souvent le temps de corriger avant que quiconque ne s’en aperçoive.
Cela vous permet aussi de relever les seuils serveur en toute confiance. Si le site est vérifié chaque minute, l’alerte CPU n’a pas à être celle qui détecte une panne. Elle peut être réglée pour prévenir tôt plutôt que de servir de dernier recours. Le même raisonnement s’applique aux vérifications de sites web ; consultez comment réduire les fausses alertes en surveillance de disponibilité.
Revoir les seuils après chaque incident
Les seuils ne sont jamais terminés. Après chaque incident, et une fois par mois pour les serveurs bruyants, posez-vous ces questions :
Une alerte s’est-elle déclenchée avant que les utilisateurs ne remarquent le problème ? Sinon, quelle métrique a bougé en premier, et un seuil plus bas l’aurait-il détecté ?
Quelles alertes se sont déclenchées sans que personne n’agisse ? Relevez-les, ajoutez une durée ou déplacez-les vers un canal de journée.
L’alerte a-t-elle atteint quelqu’un en mesure d’agir ? Sinon, modifiez le routage.
La normale du serveur a-t-elle changé après une mise à niveau, une migration ou une hausse du trafic ?
Consignez les réponses dans le rapport d’incident, pour que chaque changement ait une justification. Le modèle de postmortem d’incident comporte une section prévue exactement pour cela.
En résumé
Alertez sur ce qui demande une intervention humaine, avec le degré d’urgence réel. Utilisez des valeurs durables, la charge par cœur, la mémoire disponible et le swap, le niveau et la croissance du disque, ainsi que chaque redémarrage imprévu. Partez de valeurs d’exemple, apprenez la normale de chaque serveur et ajustez après chaque incident.
Uptimecheck réunit la surveillance de serveurs, les vérifications de disponibilité, les heartbeats et les pages de statut dans un seul compte. Démarrez un essai gratuit de 14 jours, sans carte bancaire.