Qu'est-ce que la supervision d'infrastructure ?

Qu'est-ce que la supervision d'infrastructure ?

La supervision d'infrastructure (infrastructure monitoring) consiste à collecter en continu des métriques de santé, avec alertes, sur la couche située sous votre application : serveurs et machines virtuelles, conteneurs, réseaux, bases de données et services cloud managés. Les signaux typiques sont le CPU, la mémoire, l'espace et les I/O disque, le débit et les erreurs réseau, ainsi que des valeurs propres à chaque service comme la profondeur d'une file ou le retard de réplication. Elle répond à une question : la plateforme est-elle saine ?

Comment ça marche

Un petit agent ou exporter tourne sur chaque hôte, ou à côté de chaque conteneur, et lit les compteurs du système d'exploitation. Pour les services managés, le collecteur interroge plutôt l'API de métriques du fournisseur cloud. Les deux envoient des séries temporelles vers un backend qui les stocke, trace des tableaux de bord et évalue des règles d'alerte. Les agents courants sont Prometheus node_exporter, le Datadog Agent, l'agent AWS CloudWatch et Telegraf. Les données sont en général collectées toutes les quelques secondes à chaque minute : la tendance est visible bien avant d'atteindre une limite.

Que mesurer

• CPU : utilisation et longueur de la file d'exécution. Voir CPU utilization in performance testing (en anglais).
• Mémoire : utilisée, disponible et activité de swap. Le swap est un signal plus fort qu'un taux d'utilisation élevé.
• Disque : espace libre, latence de lecture et d'écriture, attente d'I/O.
• Réseau : bande passante, retransmissions, paquets perdus et nombre de connexions.
• Limites des services : profondeur des files, connexions à la base de données, retard des réplicas, santé des cibles du répartiteur de charge.

Exemple

Une page de paiement ralentit chaque soir. Les métriques applicatives disent seulement « les requêtes sont lentes ». Le tableau de bord d'infrastructure montre que l'attente disque de l'hôte de la base de données grimpe alors que le CPU reste plat, et qu'une tâche de sauvegarde écrit sur le même volume. Décaler la fenêtre de sauvegarde règle le problème. Sans données au niveau de l'hôte, l'équipe aurait accusé le code.

Erreurs courantes

• Alerter uniquement sur des moyennes. Un CPU moyen de 40 % sur un parc peut cacher un nœud saturé. Alertez par hôte et suivez les percentiles.
• Alerter à chaque pic. Les pics brefs sont normaux. Exigez que la condition dure quelques minutes, sinon vous habituez l'équipe à ignorer les alertes.
• Pas de référence. Une valeur n'a de sens que comparée à la normale de ce service à cette heure.
• Surveiller les hôtes, pas les utilisateurs. Tous les tableaux de bord peuvent être au vert pendant qu'un endpoint de connexion renvoie des erreurs.
• Oublier les services managés. Files, caches et bases de données atteignent des limites qui n'apparaissent jamais dans le CPU de l'hôte.

Supervision d'infrastructure et reste de votre stack

La supervision d'infrastructure est une couche de l'observabilité. L'APM couvre le code au-dessus, la supervision réseau les chemins entre systèmes et la supervision cloud les services du fournisseur que vous louez. Elle se marie bien avec les tests de charge : générez un trafic maîtrisé et observez quelle ressource sature en premier, ce qui indique où manque la capacité.

LoadFocus ne supervise ni les hôtes ni les conteneurs et ne remplace pas un outil d'infrastructure. Il surveille de l'extérieur : la supervision d'API vérifie vos endpoints à intervalle régulier et alerte en cas d'échec ou de lenteur, et les tests de charge produisent le trafic qui sollicite vos serveurs. Utilisez un outil d'infrastructure pour comprendre le pourquoi, et une vérification de l'extérieur pour savoir si les utilisateurs sont touchés. Plus sur les alertes dans monitoring best practices for DevOps and developers (en anglais).

Questions fréquentes

Quelle différence entre supervision d'infrastructure et supervision applicative ?

La supervision d'infrastructure surveille la plateforme : hôtes, conteneurs, réseaux et services managés. La supervision applicative surveille le code qui tourne dessus : latence des endpoints, taux d'erreur et traces. Il faut les deux, car un hôte sain peut faire tourner une application lente.

Quelles métriques comptent le plus ?

Commencez par le CPU, la mémoire, l'espace et les I/O disque et les erreurs réseau de chaque hôte, puis ajoutez les limites des services dont vous dépendez, comme la profondeur des files et les connexions à la base de données. Privilégiez les métriques qui montrent la saturation, pas seulement l'usage.

Faut-il un agent sur chaque serveur ?

Pour les machines virtuelles et conteneurs que vous gérez, en général oui, ou un exporter qui expose des métriques. Pour les services cloud managés, on lit en général les métriques via l'API du fournisseur.

LoadFocus peut-il remplacer ma supervision d'infrastructure ?

Non. LoadFocus vérifie des endpoints et des pages de l'extérieur et génère de la charge pour les tests. Il ne lit ni le CPU, ni la mémoire, ni le disque de vos serveurs : utilisez-le avec un outil de supervision d'infrastructure.