Qu'est-ce que l'Infrastructure Monitoring ?

Qu'est-ce que l'infrastructure monitoring ?

L'infrastructure monitoring suit la santé des hosts, containers, réseaux et services cloud managed qui sont sous le code de ton application. Le set standard de signaux est utilisation CPU, pression mémoire, I/O disque et espace libre, throughput réseau et packet loss, plus des metrics spécifiques au service : profondeur de queue sur SQS, replica lag sur une base de données, usage de connection pool sur un load balancer, target health sur un service ECS. L'infrastructure monitoring répond à la question "est-ce que la couche sous mon app est saine" avant que tu commences à demander pourquoi ton app est lente.

Un agent d'infrastructure monitoring (Datadog Agent, Prometheus node_exporter, AWS CloudWatch Agent, Telegraf, Beats) tourne sur chaque host ou en sidecar dans chaque container. Il scrape les compteurs OS (procfs, /sys, performance counters sur Windows), poll l'API metrics du cloud provider (CloudWatch, Azure Monitor, GCP Monitoring) et ship les séries temporelles à un backend pour storage, query et alerting.

Infrastructure monitoring vs application monitoring

Deux couches, les deux nécessaires, souvent confondues :

• Infrastructure monitoring : le host, le container, le service cloud. CPU, mémoire, disque, profondeur de queue. Répond à "la plateforme est-elle saine ?"
• Application monitoring (APM) : le code par-dessus. Latency endpoint, error rate, traces. Répond à "l'app se comporte-t-elle ?" Voir APM.

Les deux couches échouent de façons caractéristiques. CPU bloqué à 100% est un signal infrastructure. p95 latency qui monte alors que CPU reste plat est un signal application. Les plateformes modernes d'observability corrèlent les deux : l'observability en tant que discipline a émergé en partie parce qu'alerter sur des metrics host isolées produisait trop de faux positifs sans contexte app.

Ce que couvre l'infrastructure monitoring

• Hosts et VMs : CPU, load average, mémoire, swap, I/O disque, disque libre, usage d'inodes, file descriptor count, process count.
• Containers (Docker, Kubernetes) : CPU par container, mémoire, restart count, événements OOMKilled, pod readiness, node pressure, échecs d'image pull.
• Réseaux : throughput in/out, packet loss, retransmissions, remplissage de table de connection tracking, security group flow logs.
• Load balancers : target health, request count, 5xx rate, latency p95 à la couche LB, connection counts.
• Bases de données : connections utilisés, replica lag, throughput de queries, slow query log, cache hit ratio, lock contention.
• Message queues : profondeur de queue, message age, consumer lag, dead letter count.
• Services cloud managed : profondeur SQS, S3 4xx/5xx, requêtes DynamoDB throttled, concurrence Lambda, CPU et connections RDS.

Alerts infrastructure clés

1. Disque libre sous 15% sur n'importe quel host. Attrape les échecs de log rotation et les temp files qui débordent.
2. CPU soutenu au-dessus de 80% pendant 10+ minutes. Te dit qu'un host est at capacity, souvent avant que la latency d'app spike.
3. Pression mémoire ou événements OOMKilled sur n'importe quel container. Souvent le premier symptôme d'un memory leak.
4. Target load balancer unhealthy pendant 2+ minutes. Signal direct que le trafic est dévié.
5. Profondeur de queue au-dessus de N où N est ton nombre "consumer peut traiter en 15 min". Attrape les crashes de consumer ou la lenteur downstream.
6. Packet loss réseau au-dessus de 1% soutenu. Habituellement un switch, une mauvaise config de security group, ou une NIC défectueuse.

Comment configurer

Pour les stacks cloud-native : activer CloudWatch (ou le monitoring natif de ton provider) comme baseline, puis installer le Datadog Agent, Prometheus node_exporter plus Grafana, ou le module infrastructure de ton vendor APM sur chaque host. Pour Kubernetes : kube-state-metrics plus node_exporter scrapé par Prometheus est le default OSS. Ajouter les alerts de façon incrémentale.

Coupler l'infrastructure monitoring aux load tests pour valider les alerts. Lancer load testing, spike testing ou capacity testing contre staging et observer quelle metric host monte la première.

Si ton équipe a besoin de corrélation infrastructure-charge sous trafic de production, LoadFocus propose des services de load testing où des ingénieurs lancent la matrice et produisent le breakdown.