Un disque à 87 % n'est qu'une mesure. Elle ne vous dit pas si l'utilisation tourne autour de ce niveau depuis des mois ou si elle grimpe vers la saturation. Ces deux situations appellent des réponses différentes : l'une ne nécessite peut-être aucune action, l'autre peut exiger un plan.
Bien lire les métriques d'un serveur, c'est savoir distinguer un saut ponctuel d'une hausse durable. Une valeur isolée vous donne un instantané ; une série de mesures vous permet de juger ce qui évolue.
Les systèmes de supervision emploient différentes techniques selon le problème : lissage, contrôles statistiques ou exigence qu'une condition persiste avant d'alerter. InfraNest s'appuie sur les mesures récentes pour estimer si certaines métriques serveur progressent vers une limite significative et, lorsque les données le permettent, combien de temps il reste approximativement.
Pourquoi une seule mesure ne suffit pas
Une mesure unique prise à un instant donné est appelée singleton dans le cadre de mesure décrit par la RFC 2330. Elle indique la valeur de la métrique à ce moment-là, mais pas si celle-ci est stable ou en train d'évoluer. Pour cela, il faut des mesures dans le temps.
C'est aussi vrai pour les compteurs. Un compteur augmente généralement jusqu'à sa réinitialisation, si bien que sa valeur brute est rarement la grandeur utile. Prometheus utilise des fonctions comme rate() ou increase() pour estimer de combien un compteur varie sur une fenêtre de temps. Les jauges, comme l'espace disque libre, peuvent monter comme descendre ; pour elles, une fonction adaptée aux jauges comme deriv() est plus appropriée.
À chaque outil sa question
Le problème n'est pas nouveau, mais aucune technique ne permet à elle seule de séparer tous les sauts de toutes les tendances. Les systèmes de supervision emploient des méthodes différentes selon ce qu'ils mesurent et ce qu'ils doivent décider.
| Technique | Ce qu'elle permet de savoir | Comment |
|---|---|---|
| Load average Unix | Comment la charge système évolue dans le temps | Fournit des moyennes à amortissement exponentiel sur 1, 5 et 15 minutes. Elles mesurent les tâches exécutables ou non interruptibles — pas le pourcentage de CPU — et la moyenne la plus courte réagit plus vite aux changements récents. |
| CloudWatch « Datapoints to Alarm » | Si une métrique a dépassé le seuil de façon répétée | Exige un nombre configuré de points en dépassement sur un nombre défini de périodes d'évaluation, par exemple 3 sur 5. |
Prometheus rate() et irate() |
À quelle vitesse un compteur augmente | rate() estime l'augmentation moyenne par seconde sur une fenêtre ; irate() utilise les deux derniers échantillons et réagit plus vite aux changements récents. |
Clause for de Prometheus |
Si une condition d'alerte persiste | Retarde le déclenchement jusqu'à ce que la condition soit restée active pendant la durée configurée. |
| Règles de maîtrise statistique des procédés | Si un processus a pu se décaler ou dériver | Les règles des cartes de contrôle recherchent des points ou des motifs inhabituels par rapport à une référence du processus. Elles dépendent de la méthode ; elles ne constituent pas une définition universelle d'une tendance. |
| Alertes SRE de burn rate multi-fenêtres | Si un budget d'erreur est consommé trop vite | Combinent des fenêtres courtes et longues pour identifier différents niveaux de risque sur le SLO. Elles sont conçues pour la fiabilité des services, pas pour la prévision générale de capacité des serveurs. |
Ces techniques sont apparentées, mais pas interchangeables. Une alerte qui exige un dépassement prolongé ne répond pas à la même question qu'une estimation du moment où une valeur en hausse pourrait atteindre une limite.
Exemple Prometheus : une jauge d'espace disque libre
node_filesystem_free_bytes est une jauge ; utilisez donc deriv() pour estimer la vitesse à laquelle l'espace libre évolue. Un résultat négatif signifie que l'espace libre diminue :
deriv(node_filesystem_free_bytes{mountpoint="/"}[6h])
Vous pouvez utiliser predict_linear() pour estimer si l'espace libre atteindra zéro dans les prochaines 24 heures, et exiger que cette condition persiste avant de déclencher une alerte :
- alert: DiskFillingFast
expr: predict_linear(node_filesystem_free_bytes{mountpoint="/"}[6h], 24 * 3600) < 0
for: 10m
predict_linear() repose sur une régression linéaire. Cet exemple prédit le passage à zéro octet libre — et non un seuil de disque configuré par l'utilisateur — et ce n'est pas le calcul utilisé par InfraNest.
Lire l'état d'un parc de serveurs d'un coup d'œil
Un serveur qui reste autour de 60 % et un autre qui a connu un pic bref mais élevé peuvent afficher une moyenne similaire sur une période donnée. Regarder le pic en plus de la moyenne permet de révéler cette différence.
Le Capacity & growth report d'InfraNest affiche les valeurs de pic et de moyenne sur la période pour le CPU, la mémoire et le disque, ainsi qu'une petite sparkline CPU pour donner une idée de l'allure de la courbe. Une estimation pour le disque n'apparaît que lorsque les mesures récentes la justifient. Il s'agit d'une prévision en temps réel, affichée pour une période incluant aujourd'hui — pas d'une prévision pour chaque disque ni pour un mois passé.
Avant de comparer des chiffres, vérifiez combien de jours ont été mesurés. Un serveur dont seule une partie de la période a été enregistrée n'est pas directement comparable à un serveur mesuré tout au long de celle-ci. Et en cas d'utilisation cyclique ou irrégulière, il n'existe pas forcément de tendance fiable à extrapoler.
Comment InfraNest estime quand une tendance devient préoccupante
Sur la page d'un serveur supervisé, InfraNest peut afficher un résumé comme celui-ci :
En ligne depuis 18 j 4 h, mais le CPU atteint son seuil d'alerte de 90 % dans environ 6 jours
Le bouton vous mène au graphique correspondant. Pour le disque, l'estimation est un compte à rebours jusqu'à la saturation. Pour le CPU, la mémoire et la charge, il s'agit d'un compte à rebours jusqu'à une règle d'alerte de seuil haut active. Le disque est traité différemment : un disque plein constitue une limite de capacité, qu'une règle d'alerte disque soit configurée ou non.
L'estimation est volontairement prudente :
- Elle utilise jusqu'aux sept derniers jours de mesures horaires ; cela ne signifie pas que sept jours complets d'historique soient toujours nécessaires.
- Elle nécessite au moins 12 mesures exploitables et n'affiche aucune estimation lorsque les mesures ne traduisent pas une tendance à la hausse crédible — par exemple après un saut ponctuel ou lorsque la série fluctue trop.
- Les estimations pour le CPU, la mémoire et la charge nécessitent une règle de seuil haut active. Pas celles du disque.
- Elle indique la tendance éligible la plus proche plutôt que de lister une échéance distincte pour chaque métrique.
- Les mesures CPU remontées par le fournisseur peuvent suffire à une estimation sans l'agent. La mémoire, l'utilisation du disque et le load average nécessitent les mesures de l'agent.
Le résumé lui-même ne déclenche pas d'alerte de seuil et n'ouvre pas d'incident. Il estime quand une valeur en hausse pourrait atteindre sa limite ; ce n'est pas une promesse du moment où vous serez notifié. Les alertes numériques évaluent une moyenne sur la durée configurée. Par ailleurs, un disque supervisé dont la saturation est estimée sous 14 jours peut apparaître dans la liste des points d'attention et le récapitulatif d'InfraNest.
Le résumé apporte un contexte utile, mais ne remplace pas les alertes. Celles-ci continuent de gérer les conditions de seuil configurées ; l'estimation peut vous donner plus tôt une raison d'enquêter sur un éventuel problème de capacité.
Pour la vue d'ensemble du parc, consultez le rapport Capacity & growth. Pour la configuration et l'évaluation des seuils, consultez les règles d'alerte par serveur.
Passer à la pratique
Configurez le server monitoring pour collecter les mesures disponibles pour vos serveurs. Les métriques remontées par le fournisseur peuvent fournir les mesures CPU lorsque c'est pris en charge ; installez l'agent pour collecter la mémoire, l'utilisation du disque et le load average.
Questions fréquentes
#De combien d'historique InfraNest a-t-il besoin avant d'afficher une ligne de tendance ?
Un serveur doit disposer de plus d'un jour ou deux de mesures avant qu'InfraNest ne se prononce. Avec trop peu d'historique, les données ne suffisent pas à distinguer une vraie tendance du bruit : la ligne n'est donc tout simplement pas affichée plutôt que de risquer une supposition.
#La ligne de tendance fonctionne-t-elle sur les serveurs sans agent de supervision ?
Oui. Les serveurs sans agent sont pris en compte pour toutes les mesures remontées par leur fournisseur cloud ; l'agent ajoute des métriques supplémentaires comme la mémoire, l'espace disque et le load average, mais il n'est pas nécessaire pour la phrase de tendance elle-même.
#Pourquoi mon serveur n'affiche-t-il aucune ligne de tendance alors qu'une métrique semble élevée ?
Une mesure élevée mais stable, qui a fait un saut ponctuel avant de se stabiliser, ou qui oscille, n'obtient pas de ligne de tendance — seule une métrique en hausse réellement régulière en a une. Une mesure élevée mais stable ne vous est pas cachée ailleurs ; on ne lui attribue simplement pas une fausse échéance.
#La prévision de tendance est-elle la même chose qu'une alerte serveur ?
Non. La ligne de tendance est un élément de contexte, pas une notification : rien ne se déclenche et personne n'est prévenu lorsqu'elle apparaît. L'alerte proprement dite ne se déclenche que lorsque la métrique franchit votre seuil et y reste pendant la durée que vous avez configurée.
Essayez avec un outil gratuit
Cet article vous a-t-il été utile ?
