Netdata collecteurs : supervision temps réel Kubernetes, Docker et AWS

Table des matières :

Netdata est rarement “magique” par lui‑même : la valeur vient des collecteurs Netdata (collectors) et de la manière dont ils lisent le noyau, les runtimes conteneurs, ou des APIs cloud. Si vous supervisez une stack e‑commerce (typiquement PrestaShop 9.x / PHP 8.2+ ou 8.3 en 2026) déployée en VM, Docker ou Kubernetes, l’enjeu n’est pas d’avoir des métriques, mais d’avoir des métriques à haute fréquence, corrélables, et avec un coût d’ingestion maîtrisé.

Un bon “plan collecteurs” répond à trois questions très opérationnelles :

Quelle décision cette métrique permet-elle de prendre en incident ? (ex. “CPU throttling → augmenter la limite CPU du pod”, plutôt que “CPU haut → ajouter des nœuds”)
À quelle fréquence a-t-on besoin de la série ? (1 s pour diagnostiquer un freeze, 60–300 s pour un service managé CloudWatch)
Où la métrique est-elle la plus fiable ? (agent local vs API agrégée)

Sur PrestaShop, on retombe vite sur les mêmes causes racines : saturation CPU (et throttling), latence disque, contention DB, files de jobs, erreurs 5xx et timeouts réseau. Les collecteurs doivent donc couvrir machine + conteneurs + application (PHP‑FPM, DB, webserver) et pas seulement “l’OS”.

Ce que Netdata appelle un « collecteur » (et pourquoi ça compte)

Dans Netdata, un collecteur est un composant (plugin) qui extrait des métriques d’une source (procfs, cgroups, socket, API HTTP, SNMP, CloudWatch…) et les expose sous forme de charts et dimensions dans l’agent. C’est la base de la supervision temps réel : si le collecteur est mal choisi (ou mal paramétré), vous aurez des dashboards “jolis” mais inutiles pour diagnostiquer un incident.

Techniquement, la plupart des collecteurs Linux s’appuient sur des interfaces noyau stables : /proc, /sys, cgroups v1/v2, et parfois eBPF pour des mesures plus fines. À l’inverse, les collecteurs “cloud” (AWS, services managés) dépendent de quotas et de latences d’API. Il faut donc raisonner en plan de contrôle : quelles métriques sont récupérées localement à 1 s, lesquelles sont interrogées via API à 60 s/300 s, lesquelles doivent être agrégées (et où).

Pour rendre ça concret, voici une grille simple (souvent suffisante pour éviter 80 % des erreurs de design) :

Source de métriques	Exemple de collecteur	Fréquence réaliste	Avantage	Risque principal
Noyau / hôte	`proc`, `sys`, disques, réseau	1 s	Très réactif, utile en incident	Trop de détails si on active tout
cgroups / conteneurs	CPU quota, throttling, mémoire, IO	1 s	Explique “pourquoi ça rame” en conteneur	Mauvaise lecture si cgroups v2 non pris en compte
Process / applications	PHP‑FPM, MySQL, Nginx, Redis	1–5 s	Diagnostique applicatif rapide	Cardinalité si on “track” trop de process
API managées cloud	CloudWatch RDS/ALB/EBS	60–300 s	Couvre l’invisible (services managés)	Coût + métriques déjà agrégées
Pull tiers	Prometheus/OpenMetrics, StatsD, SNMP	10–60 s	Centralise, corrèle	Doublons si on scrape deux fois la même chose

Un point d’audit fréquent : la confusion entre “santé du service” et “état machine”. Le Google SRE Book insiste sur le monitoring orienté service (chapitre Monitoring Distributed Systems) : l’objectif est d’attraper ce qui dégrade l’expérience utilisateur, pas uniquement des compteurs système. Dans Netdata, ça se traduit par une sélection de collecteurs et d’alertes qui suivent les symptômes pertinents pour votre boutique : latence PHP‑FPM, saturation et throttling, I/O DB, erreurs HTTP, etc.

Pour la partie perf applicative PrestaShop (cache, images, DB), l’article sur l’optimisation serveur et base aide à relier symptômes et actions : article sur l’optimisation serveur et base.

Docker : collecteurs cgroups, apps et réseau pour diagnostiquer une saturation en minutes

En environnement Docker, les collecteurs Netdata qui comptent vraiment sont ceux qui “comprennent” l’isolation : métriques cgroups (CPU quota, throttling, mémoire RSS/Cache, OOM), et métriques par processus (apps) pour distinguer une charge PHP‑FPM d’un pic MySQL. Sur une boutique conteneurisée, c’est typiquement la différence entre “CPU à 90 %” et “CPU à 90 % dont 35 % perdu en throttling car cpu.cfs_quota_us est trop bas”. Sans ce niveau, vous finissez à sur‑provisionner.

Mini‑scénario (fréquent en prod) : vous lancez une campagne, le trafic grimpe, mais le CPU host reste “raisonnable”. Pourtant, le TTFB explose. En regardant par cgroup, vous voyez :

php-fpm : CPU élevé + throttling qui monte au même moment
mariadb : CPU stable, mais I/O wait en hausse
un conteneur “cron/index” : pics réguliers qui saturent brièvement le disque

La conséquence opérationnelle est claire : augmenter uniquement les nœuds ne résout pas si vos pods restent limités (limits CPU trop bas), et optimiser MySQL ne suffit pas si les IOPS sont déjà en file d’attente à cause d’un job annexe.

Un incident classique : pages qui ralentissent, mais pas de saturation CPU globale. Dans Docker, c’est souvent un mélange I/O + contention : MariaDB en flush, PHP‑FPM en attente, et un conteneur “sidecar” (antivirus, indexeur, cron) qui grignote les IOPS. Les charts Netdata “disk utilization”, “iowait”, “filesystem latency” + par‑cgroup permettent de l’isoler rapidement.

Checklist “Docker utile en incident” (à activer/valider en priorité) :

CPU : usage + throttling par cgroup (sinon vous manque l’information la plus actionnable)
Mémoire : RSS, cache, OOM kills (les OOM en conteneur sont souvent “silencieux” côté appli)
Disque : latence, util%, queue (utile pour DB et sessions si mal placées)
Réseau : erreurs, drops, retransmissions TCP (utile sur checkout, webhooks, PSP)

Côté durcissement, n’oubliez pas que des collecteurs (ou des exporters) mal configurés deviennent une surface d’attaque ; si vous appliquez les exigences CIS, gardez un œil sur les permissions : checklist CIS Benchmark Docker.

Enfin, sur le réseau, Netdata peut donner une visibilité immédiate sur les resets, retransmissions TCP et sockets en backlog. C’est utile quand “tout va bien” sur CPU/RAM mais que vous avez des timeouts côté client (checkout, API PSP, webhooks). En pratique, si votre CDN cache bien (voir vos critères CDN 2026 : critères CDN 2026), les pics réseau se déplacent vers les endpoints dynamiques : /order, /module/*, webservices, Admin API.

Kubernetes : déploiement en DaemonSet/Helm, kubelet, cAdvisor et état du cluster

Sur Kubernetes, la supervision “temps réel” exige de séparer deux couches : nœud (node) et cluster. Netdata fonctionne bien en DaemonSet : un agent par nœud, accès aux cgroups et au filesystem du host, et collecte à haute fréquence. Le déploiement le plus propre passe généralement par Helm (chart officiel Netdata), mais vous devez valider votre posture sécurité (RBAC minimal, NetworkPolicy, PodSecurity) et vos contraintes runtime (containerd vs Docker).

Point d’audit important : sur K8s, on a vite tendance à sur‑collecter “par défaut”. Or la supervision utile en incident vient d’un petit noyau de signaux :

Node : CPU (dont throttling), mémoire (pressure), disque (latence), réseau (drops/retrans)
Workload : latence applicative (Nginx/PHP‑FPM), erreurs HTTP, DB (threads, slow queries), files
Plateforme : événements de déploiement (rollout), pods en échec, saturation kubelet/API (si accessible)

Pour la partie conteneurs, la mesure fine repose sur ce que Kubernetes expose via kubelet/cAdvisor. Le projet cAdvisor résume précisément son rôle :

“cAdvisor (Container Advisor) provides container users an understanding of the resource usage and performance characteristics of their running containers.” — README cAdvisor (github.com/google/cadvisor)

Netdata va ensuite “réconcilier” ces métriques avec son modèle (charts/dimensions). Le point important : sur K8s, vous devez surveiller explicitement CPU throttling et memory pressure au niveau cgroups v2, sinon vous confondez HPA (autoscaling) et sur‑commit réel. C’est particulièrement vrai quand vous migrez une app PHP stateful comme PrestaShop vers K8s : la checklist GitOps et les pièges (volumes, sessions, caches) sont détaillés ici : migration PrestaShop vers Kubernetes — checklist.

Deux signaux qui “payent” presque toujours sur une boutique :

Throttling + HPA qui scale “dans le vide” : vous ajoutez des réplicas, mais chaque pod reste bridé → la latence ne baisse pas.
Pending pods + disk pressure : vos pods ne démarrent pas (ou redémarrent) alors que l’UI “cluster” semble OK → un nœud est en pression disque/inodes, ou vos requests/limits empêchent le scheduling.

La troisième brique est l’“état du cluster” : pods en CrashLoopBackOff, Pending, saturation de l’API server, erreurs d’admission, etc. Netdata n’est pas un remplacement de kube‑state‑metrics, mais il peut ingérer des métriques déjà exposées (Prometheus/OpenMetrics) et corréler avec la perf node. C’est souvent plus utile en incident qu’un dashboard séparé : vous voyez sur la même timeline le pic d’erreurs 5xx, le rollout, et la hausse de throttling sur un node précis.

Pour une migration avec TLS/DNS/multiboutique (cas fréquent en agence), recoupez aussi avec : guide migration TLS/DNS multiboutique.

AWS : collecteurs CloudWatch, EC2 metadata, EKS et les pièges coût/quotas

En AWS, la supervision via Netdata se heurte à un fait : une partie des métriques “managées” sont déjà agrégées côté CloudWatch, avec une granularité et un coût variables. Un collecteur Netdata CloudWatch est pertinent pour RDS, ELB/ALB, EBS, SQS, etc., mais pas pour remplacer la télémétrie locale d’une instance (où Netdata est meilleur, car à 1 s). Le bon design consiste à utiliser CloudWatch pour ce qui n’est pas accessible autrement (services managés) et l’agent pour le reste.

Les deux pièges récurrents sont : (1) les quotas/rate limits et (2) le coût. Poller 200 métriques CloudWatch toutes les 10 secondes est un non-sens : vous augmentez votre facture et vous obtenez quand même une métrique “moyennée” (selon le namespace et la période). Préférez des périodes alignées sur CloudWatch (60 s ou 300 s selon le service), et réservez le temps réel aux collecteurs locaux (cgroups, sockets, MySQL, PHP‑FPM). Si vous avez une démarche IaC, encodez ces choix directement dans Terraform : Terraform & conteneurs — IaC.

Une approche pragmatique consiste à limiter CloudWatch aux métriques qui expliquent réellement les incidents (et qui n’existent pas “localement”) :

Service AWS	Namespace CloudWatch	Séries souvent utiles en e‑commerce	Période typique
RDS (MySQL/MariaDB)	`AWS/RDS`	`DatabaseConnections`, IOPS, stockage libre	60–300 s
ALB	`AWS/ApplicationELB`	`TargetResponseTime`, `HTTPCode_Target_5XX_Count`	60 s
EBS	`AWS/EBS`	`VolumeQueueLength`, `BurstBalance`	60–300 s
SQS	`AWS/SQS`	profondeur de file, âge du plus vieux message	60 s

Sur EKS, un point technique sous-estimé est l’authentification : donnez au collecteur uniquement les permissions IAM nécessaires (idéalement via IRSA) et limitez les namespaces/metrics. Exemple de logique (pseudo) : rôle IAM autorisé à cloudwatch:GetMetricData sur des namespaces précis + ServiceAccount annoté. Dans Netdata, l’objectif n’est pas de “tout aspirer”, mais d’avoir les quelques séries qui expliquent les incidents : AWS/RDS (DatabaseConnections, Read/WriteIOPS, FreeStorageSpace), AWS/ApplicationELB (TargetResponseTime, HTTPCodeTarget5XX_Count), AWS/EBS (VolumeQueueLength, BurstBalance).

Pour le “GEO flavour” (sans surcharger) : si vous opérez une boutique destinée majoritairement à des clients en France/Europe, pensez aussi latence + conformité dans votre choix de collecte centralisée (où vont les métriques, combien de temps, et si des noms d’hôtes/IP peuvent être considérés comme données personnelles selon votre contexte). C’est rarement un sujet “monitoring” au départ… jusqu’au jour où il faut justifier où sont stockées les données d’observabilité.

Industrialiser : exporter, corréler et alerter (Prometheus, OpenTelemetry, health)

Netdata est efficace en troubleshooting, mais dans une orga, vous voulez aussi : rétention long terme, alerting centralisé, et corrélation avec logs/traces. Deux patterns dominent : (1) exporter depuis Netdata vers un backend de séries temporelles, ou (2) ingérer dans Netdata des métriques existantes (Prometheus/OpenMetrics, StatsD, SNMP). Sur ce blog, le scénario “Netdata ↔ Prometheus/SNMP/StatsD” est déjà traité de façon opérationnelle : Netdata intégrer Prometheus, SNMP et StatsD.

Pour cadrer Prometheus, sa définition officielle est concise et stable :

“Prometheus is an open-source systems monitoring and alerting toolkit.” — Prometheus documentation (prometheus.io/docs)

Dans un cluster Kubernetes, l’approche pragmatique est souvent : Prometheus/Thanos pour la rétention et les règles d’alerting, Netdata pour le temps réel et la navigation “drill‑down” par host/cgroup/process. Attention toutefois aux doublons : si vous scrapez à la fois kubelet/cAdvisor via Prometheus et via Netdata, vous payez deux fois le coût et vous compliquez la lecture. Fixez un “owner” par métrique.

Un cadre simple pour éviter les doublons :

Netdata “owner” : 1 s, diagnostic, granularité fine (process, cgroups, latence disque)
Prometheus “owner” : SLO/SLA, alertes standardisées, rétention, agrégations par service/namespace
OTel (si présent) : traces et métriques applicatives (latence par endpoint, erreurs métier), corrélées aux logs

Côté alerting, Netdata a son propre moteur de “health checks” et des mécanismes de détection (y compris des approches statistiques/ML selon la configuration). L’intérêt, pour un stack PHP e‑commerce, est d’écrire des alertes orientées symptôme (donc actionnables) :

Nginx 5xx + augmentation de la latence upstream → suspecter PHP‑FPM ou DB
php-fpm busy + hausse slowlog → suspecter contention, opcode cache, appels externes
threads_running MySQL + latence disque → suspecter flush/IOPS et requêtes lourdes
Throttling CPU + HPA qui scale → requests/limits mal calibrés, ou nœuds sous-dimensionnés

Pour la résolution rapide des 500 sur PrestaShop (où la métrique ne suffit pas sans logs), ce rappel reste utile : résolution des 500 sur PrestaShop.

Écrire ou adapter un collecteur : go.d / python.d, chart dimensions, tests

Dès que vous sortez des sentiers battus (module métier, ERP, bus RabbitMQ, API interne), vous finirez par écrire un collecteur. Netdata propose plusieurs frameworks (ex. go.d, python.d, scripts “charts.d”) qui permettent de transformer un endpoint HTTP/JSON, une commande CLI, ou un socket en séries temporelles. Le critère de choix est simple : performance et maintenabilité. Pour des métriques à 1 s sur 200 hosts, privilégiez Go (overhead plus faible, runtime stable). Pour un collecteur “interne” à faible fréquence (10 s/60 s), Python est acceptable.

Un collecteur Netdata bien fait respecte quelques invariants : dimensions stables (pas de cardinalité explosive), labels maîtrisés, et timeouts agressifs (un collecteur ne doit jamais bloquer l’agent). En audit, les mauvaises pratiques reviennent souvent :

Cardinalité non bornée (ex. une dimension par client, par URL, par ID commande)
Timeouts trop longs (un endpoint lent “gèle” le plugin et dégrade la collecte globale)
Unités incohérentes (ms vs s, bytes vs MiB) rendant les alertes inutilisables
Noms instables (des dimensions qui apparaissent/disparaissent selon les déploiements)

Exemple concret côté e‑commerce : vous voulez monitorer une file RabbitMQ “orders” (messages ready, unacked, rate publish/ack). Vous exposez un endpoint JSON (ou utilisez l’API management) et vous mappez ces champs vers 3‑5 dimensions. Surtout : évitez d’émettre une dimension par queue dynamique (ex. une queue par client), sinon votre dashboard devient inutilisable et votre stockage explose.

Processus conseillé (rapide, mais robuste) pour livrer un collecteur :

Définir les 5–10 métriques max qui expliquent une panne (pas “tout”)
Fixer une fréquence (1 s / 5 s / 60 s) cohérente avec l’usage
Définir des valeurs par défaut sûres (timeouts, retries, backoff)
Ajouter 1–2 alertes “symptôme” (ex. backlog qui croît + absence de consommateurs)
Tester avec des fixtures (JSON) et rejouer en CI

Testez vos collecteurs comme du code de prod : fixtures JSON, tests unitaires, et validation en CI/CD. Si vous avez déjà des pipelines pour vos modules PrestaShop, réutilisez cette discipline (lint, tests, packaging) : la dette d’observabilité est de la dette de prod. Pour la qualité de delivery dans l’écosystème PrestaShop, voyez aussi l’intégration CI/CD et environnements : Chaoslab — tester modules PrestaShop et PS Validator — intégration CI/CD.

Checklist de mise en production (sécurité, perf, rétention) pour un e‑commerce

Sur la sécurité, partez du principe que l’agent Netdata est un composant privilégié : il lit des métriques kernel, inspecte des process, et peut appeler des APIs. En Docker/Kubernetes, isolez-le : ServiceAccount dédié, RBAC minimal, pas d’accès en écriture au host, et si possible un réseau sortant contrôlé (egress). Sur des environnements multi‑tenant, limitez la visibilité (namespaces) et évitez de remonter des variables d’environnement applicatives (risque de secrets). La logique est la même que pour sécuriser vos APIs et modules (SBOM, WAF, CI/CD) : sécuriser APIs et modules — guide.

Checklist sécurité (pratique) :

RBAC minimal (K8s) et IAM minimal (AWS/IRSA) : une permission = une métrique justifiée
Pas d’exposition publique des endpoints de métriques/dashboards (reverse proxy, auth, IP allowlist)
Pas de collecte de données sensibles “par accident” (noms de variables, env, labels trop verbeux)
Segmentation réseau : l’agent n’a pas besoin d’accéder à tout votre réseau interne

Sur la performance, mesurez l’overhead au lieu de l’imaginer. L’agent temps réel peut monter à plusieurs centaines de charts sur un node chargé ; ce n’est pas “gratuit”, surtout si vous activez des collecteurs très verbeux (réseau détaillé, eBPF, collecte process exhaustive) sur des nœuds déjà CPU‑bound. La bonne pratique consiste à : (1) fixer une fréquence réaliste par collecteur, (2) désactiver ce que vous n’exploitez pas en incident, (3) valider en charge (ex. campagne, soldes).

Un repère utile en e‑commerce : les pics ne sont pas seulement “Black Friday”. En France, des périodes comme les soldes ou certaines campagnes média créent des patterns de charge très brusques (trafic + backoffice + jobs). Cela renforce l’intérêt des métriques 1 seconde (Netdata) pour diagnostiquer les micro‑saturations, et des métriques long terme (TSDB) pour comparer les semaines.

Si votre problème actuel est un TTFB dégradé, commencez par diagnostiquer serveur/bots et contention : diagnostic TTFB PrestaShop.

Sur la rétention, soyez clair : Netdata sert d’abord au temps réel et au troubleshooting. Pour l’historique long terme (semaines/mois), externalisez vers un TSDB (Prometheus+Thanos, VictoriaMetrics, Mimir…) ou utilisez la couche de stockage/centralisation que vous avez déjà. L’important est la continuité opérationnelle : une boutique qui “ralentit une fois par semaine” se comprend avec des corrélations sur 30 jours, pas avec 2 h de données.

Petit tableau “objectif → où stocker” (pour trancher vite) :

Besoin	Outil/stockage adapté	Pourquoi
Debug instantané (1–10 minutes)	Netdata local / temps réel	Drill‑down host → cgroup → process
Corrélation 24–72 h	Netdata + export limité	Suffisant pour incidents récents
Tendances 30 jours (capacity)	TSDB (Prometheus/Thanos, etc.)	Agrégations, SLO, saisonnalité
Audit/forensic	Logs + traces + TSDB	Les métriques seules ne suffisent pas

Si vous opérez un hébergement géré avec staging et maintenance, intégrez Netdata dès la migration, pas après l’incident : hébergement PrestaShop géré — migration.