Netdata monitoring : surveiller AWS, Kubernetes, bases de données et serveurs web

Table des matières :

1. Où Netdata se place dans une stack d’observabilité (et ses limites)
2. Déployer l’agent Netdata proprement sur Linux : install, surface d’attaque, perf
3. Surveiller AWS avec Netdata : CloudWatch, IAM minimal, angles morts et coûts
4. Netdata sur Kubernetes : DaemonSet, kubelet/cAdvisor, cgroups v2, multi-cluster
5. Bases de données : MySQL/MariaDB, PostgreSQL, Redis — métriques qui comptent vraiment
6. Serveurs web et reverse proxies : Nginx, Apache, HAProxy, Varnish — instrumentation minimale
7. Alerting Netdata : règles “health”, seuils réalistes, export vers Grafana/Prometheus

Le monitoring Netdata, en pratique, sert surtout à deux choses : collecter des métriques à haute fréquence (typiquement à la seconde) au plus près des workloads (serveur, conteneur, pod) et fournir des graphes/actionnables quasi temps réel sans monter immédiatement une stack Prometheus + long-term storage. C’est particulièrement utile quand vous devez diagnostiquer un incident sur une boutique PrestaShop (8.x/9.x) sous PHP 8.2–8.4, où une régression peut venir aussi bien d’un pool PHP-FPM que d’un verrou InnoDB, d’un throttling EBS, ou d’un kubelet à genoux.

En exploitation e-commerce, Netdata brille surtout dans trois scénarios :

• Incident “ça rame maintenant” : vous voulez une réponse en minutes (CPU steal ? iowait ? saturation FD ? backlog FPM ?).
• Dégradation progressive : vous voyez une dérive (latence disque, erreurs réseau, mémoire reclaim) avant que les 5xx n’explosent.
• Préparation d’un pic (soldes, campagnes, TV) : établir une baseline et détecter les goulets (DB, cache, réseau) sans instrumentation lourde côté app.

Où Netdata se place dans une stack d’observabilité (et ses limites)

Netdata est un agent de monitoring orienté « host-first » : il échantillonne des centaines (voire milliers) de métriques par nœud (CPU, mémoire, FS, réseau, cgroups, processus, applis via collectors) et les expose en dashboards intégrés. En 2026, l’intérêt reste sa densité de métriques et le délai quasi nul entre un symptôme et sa visualisation, là où une stack métriques classique vous impose souvent un pipeline (exporters → scrape → TSDB → dashboards).

Pour le positionner clairement, une lecture simple est :

Besoin	Netdata	Prometheus + TSDB long terme
Diagnostic “temps réel”, 1s, sur un nœud	Excellent	Possible mais plus lourd
Grande profondeur infra (kernel, cgroups, per-process)	Excellent	Variable selon exporters
Historique 30–180 jours, comparatifs, capacity planning	Limité seul	Excellent
Gouvernance (rétention, multi-tenant, requêtes ad hoc)	Variable	Excellent
Traçage applicatif (APM / traces)	Non	Non (se couple à OTel/APM)

La contrepartie, c’est la rétention. Netdata garde de l’historique local, mais ce n’est pas une base de séries temporelles « long terme » au sens Prometheus+Thanos/Mimir, InfluxDB ou VictoriaMetrics. Si vous voulez répondre à « que s’est-il passé il y a 90 jours pendant les soldes ? », Netdata seul ne suffit pas : vous finirez par exporter (Prometheus/OpenMetrics, remote write, etc.) ou par centraliser via Netdata Cloud (avec les implications de conformité et d’egress réseau).

Sur ce point, ajoutez une contrainte “terrain” : en Europe (et a fortiori pour des marchands FR), la question n’est pas seulement technique. Dès que vous centralisez des métriques hors de votre périmètre (SaaS), vous devez vérifier où les données sont traitées, le DPA (contrat de traitement des données), les clauses de transfert, et si des identifiants/labels peuvent être considérés comme des données personnelles (par exemple des noms de clients dans des labels, ou des IPs si elles se retrouvent dans des dimensions de logs/metrics — en principe à éviter). L’avantage de Netdata en “local-first” est justement de permettre de diagnostiquer vite, sans tout exporter par défaut.

Autre point : Netdata n’est pas un APM transactionnel. Il vous aidera à voir que php-fpm sature, que mysqld attend des I/O, que nginx ouvre trop de connexions, mais il ne remplacera pas un traceur distribué (OpenTelemetry) pour suivre une requête de bout en bout. Pensez-le comme un outil d’« infrastructure troubleshooting » qui comble très bien le gap entre « je n’ai que des logs » et « je maintiens une stack observabilité complète ».

« Prometheus is an open-source systems monitoring and alerting toolkit. » — Prometheus documentation, https://prometheus.io/

Déployer l’agent Netdata proprement sur Linux : install, surface d’attaque, perf

Contexte : exemples validés pour Ubuntu 22.04/24.04 LTS, Debian 12, noyaux Linux 5.15+ (cgroups v2 recommandé en environnement conteneurisé), et architectures x86_64/arm64. Sur une prod e-commerce, évitez les installations « one-liner » sans contrôle : l’agent écoute une interface web, collecte des métriques sensibles, et a besoin d’accès système. Pré-requis : accès root, un plan de rollback (snapshot VM/AMI, point de restauration), et une fenêtre de maintenance si vous touchez aux reverse proxies.

Netdata peut s’installer via paquets distro (souvent en retard), via dépôt officiel, via conteneur, ou via script d’installation. Pour une approche reproductible, privilégiez un déploiement infra-as-code : Ansible + dépôt officiel, ou Helm chart sur Kubernetes (voir section dédiée). En VM, l’objectif est d’avoir : service systemd, mises à jour maîtrisées, et un binding réseau restreint.

La première mesure de durcissement consiste à ne pas exposer le dashboard Netdata sur Internet. Dans /etc/netdata/netdata.conf, forcez un bind local et passez par un reverse proxy interne (Nginx/Traefik) avec authentification si besoin :

[web]
  bind to = 127.0.0.1
  default port = 19999

Quelques ajouts “hardening” qui évitent des erreurs classiques en production :

• Désactiver l’envoi de statistiques anonymes si votre politique sécurité le demande (environnement régulé, client sensible). Le paramètre existe dans la configuration globale Netdata (selon versions) :

  [global]
    send anonymous statistics = no

• Isoler l’accès via reverse proxy + auth (Basic/OIDC) et filtrer par IP côté réseau (VPN/bastion). Le reverse proxy est aussi l’endroit propre pour activer TLS si vous exposez le dashboard en interne.
• Limiter la surface collectors : si vous n’utilisez pas certaines intégrations, ne les activez pas “juste au cas où”. Chaque collector = dépendances + endpoints + droits potentiels.
• Superviser l’agent lui-même : dans Netdata, ajoutez une alerte sur la croissance anormale de /var/lib/netdata/ et sur le CPU du process netdata.

Ensuite, vérifiez l’impact CPU/RAM : sur un nœud « standard » (4 vCPU / 8–16 Go), Netdata reste généralement contenu, mais certains collectors (notamment ceux très verbeux ou mal configurés) peuvent générer du bruit. Sur des serveurs PrestaShop soumis à forte charge, surveillez : netdata CPU%, latence disque, et la croissance des fichiers de DB Netdata dans /var/lib/netdata/. L’agent doit rester un observateur, pas un perturbateur.

Checklist de déploiement “propre” (utile en runbook) :

• [ ] Bind local (127.0.0.1) + reverse proxy interne
• [ ] Auth activée (au moins Basic, idéalement SSO si déjà en place)
• [ ] Collectors activés = besoins réels (DB, Nginx, Redis…)
• [ ] Compte DB de monitoring à droits minimaux
• [ ] Mises à jour maîtrisées (fenêtre, changelog, rollback)
• [ ] Rétention locale observée (taille, rotation, FS)
• [ ] Alertes calibrées sur baseline (pas sur des “valeurs magiques”)

Surveiller AWS avec Netdata : CloudWatch, IAM minimal, angles morts et coûts

Sur AWS, Netdata couvre deux couches : (1) l’OS de vos instances EC2 (agent installé sur l’instance), et (2) les métriques managées (RDS, ALB, ElastiCache, EBS, etc.) via CloudWatch. La 2e couche est souvent indispensable : une boutique peut « ramer » parce que le CPU EC2 est OK mais que le volume EBS est throttlé, ou parce que RDS atteint des limites de IOPS.

Le point critique, c’est l’IAM. Donnez au collector CloudWatch uniquement ce qu’il doit lire : cloudwatch:GetMetricData, cloudwatch:ListMetrics (et éventuellement tag:GetResources si vous faites du mapping par tags). Évitez les policies larges type CloudWatchReadOnlyAccess si vous êtes en environnement régulé (PCI-DSS, RGPD). Pour un compte multi-environnements, isolez par rôle et par account (AWS Organizations) plutôt que par « conventions de nommage ».

Exemple de policy minimale (à ajuster selon vos services) :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "CloudWatchReadNetdata",
      "Effect": "Allow",
      "Action": [
        "cloudwatch:GetMetricData",
        "cloudwatch:ListMetrics"
      ],
      "Resource": "*"
    },
    {
      "Sid": "TaggingReadOptional",
      "Effect": "Allow",
      "Action": [
        "tag:GetResources"
      ],
      "Resource": "*"
    }
  ]
}

Côté coûts/quotas : CloudWatch n’est pas gratuit dès que vous multipliez les appels GetMetricData sur beaucoup de dimensions. Netdata peut interroger fréquemment (période 60s), ce qui peut faire grimper la facture si vous activez trop de services ou trop de métriques (par exemple AWS/ApplicationELB avec des dizaines de target groups). Stratégie réaliste : commencer par 10–20 métriques “symptômes” (latence ALB, 5xx, CPU/RAM RDS, free storage, read/write latency EBS) puis élargir. Pour cadrer, appuyez-vous sur la page officielle de tarification CloudWatch (référence la plus fiable) : https://aws.amazon.com/cloudwatch/pricing/

Exemple de logique de collecte (pseudo-config, adaptez à votre module CloudWatch Netdata) :

• RDS : CPUUtilization, FreeStorageSpace, DatabaseConnections, ReadLatency, WriteLatency (et souvent aussi FreeableMemory si disponible selon moteur/édition).
• ALB : TargetResponseTime, HTTPCode_Target_5XX_Count, RequestCount.
• EBS : VolumeReadOps, VolumeWriteOps, VolumeQueueLength, BurstBalance.

Mini-scenario “très PrestaShop” (utile pour trier rapidement) :

1. ALB : TargetResponseTime P95 grimpe et HTTPCode_Target_5XX_Count augmente légèrement.
2. EC2 : CPU stable, mais iowait monte par à-coups.
3. EBS : BurstBalance chute et VolumeQueueLength s’allonge.
4. Conclusion actionnable : vous n’êtes pas sur un bug PHP, vous êtes sur un goulot I/O (volume sous-dimensionné, type EBS inadapté, ou pic d’écriture côté DB/queue). À ce stade, on corrige l’infra (IOPS/throughput) et on recoupe ensuite avec la DB (requêtes, indexes) si besoin.

Un autre cas classique : CPU stable, mais TargetResponseTime ALB monte (P95), et en parallèle ReadLatency RDS dérive : vous êtes sur un goulot d’étranglement DB (index manquant, buffer pool trop petit, ou requêtes lentes). Pour l’analyse DB côté schéma, recoupez avec une démarche type Index MySQL : optimiser WHERE, JOIN et ORDER BY avec EXPLAIN.

Netdata sur Kubernetes : DaemonSet, kubelet/cAdvisor, cgroups v2, multi-cluster

Sur Kubernetes, Netdata se déploie généralement en DaemonSet pour collecter par nœud (cgroups, kubelet, container runtime) + composants optionnels pour l’état du cluster. C’est la bonne approche si vous avez des workloads e-commerce (fronts, workers, cron, search) qui bougent : un monitoring “VM-only” perd complètement la notion de saturation par pod.

« Kubernetes is an open-source system for automating deployment, scaling, and management of containerized applications. » — Kubernetes documentation, https://kubernetes.io/

Le Helm chart Netdata (repo officiel Netdata) permet de gérer RBAC, hostNetwork, montage /proc, accès à kubelet, et éventuellement l’intégration eBPF. Point d’attention 2026 : cgroups v2 est de plus en plus la norme (Ubuntu 24.04, distributions récentes). Vérifiez que votre runtime (containerd) et votre kubelet sont alignés, sinon vous allez voir des métriques incohérentes (CPU throttling par pod “0” ou RAM “infinie”).

Trois pièges fréquents en prod :

1. Permissions kubelet/cAdvisor : si vous verrouillez trop, Netdata perd la granularité pod/container. À l’inverse, ouvrir large expose des surfaces sensibles. Faites un audit RBAC et limitez aux namespaces/nœuds nécessaires.
2. Cardinalité : Netdata peut générer beaucoup de séries si vous avez des labels instables (pods éphémères, jobs). Réglez la collecte (ce que vous voulez réellement observer) au lieu de tout activer “par défaut”.
3. Multi-cluster : évitez de centraliser en “plein mesh”. Préférez un modèle parent/enfants (streaming) : agents → parent local par cluster → export vers votre stack long-terme.

Deux bonnes pratiques qui stabilisent le déploiement en environnement marchand (où les pics sont brutaux) :

• Mettre des limites/requests au DaemonSet Netdata : cela évite que l’observabilité devienne victime de l’incident (OOM, eviction). L’objectif est une dégradation “gracieuse”, pas un trou noir métrique.
• Surveiller la pression système (quand disponible) : en plus du CPU/RAM, les signaux de contention modernes incluent la pression I/O et mémoire. Sur Linux, cela se traduit souvent par des métriques PSI (Pressure Stall Information) : quand ça monte, “tout attend” (I/O, mémoire), même si le CPU ne semble pas saturé.

Pour une boutique PrestaShop containerisée, vous voulez au minimum : CPU throttling par pod, RSS, oom_kill, saturation des nodes (load, PSI si dispo), et métriques réseau (drops/retransmits). Si vous faites déjà du tuning cache/reverse proxy, recoupez avec des patterns décrits dans Cache PrestaShop : Varnish, Redis, Memcached et OPcache côté serveur.

Pour aller plus loin sur le modèle “agents → parent → centralisation”, la documentation Netdata “streaming” (utile pour limiter les flux inter-clusters et garder une rétention locale par environnement) est ici : https://learn.netdata.cloud/docs/streaming

Bases de données : MySQL/MariaDB, PostgreSQL, Redis — métriques qui comptent vraiment

Sur PrestaShop, la DB reste souvent le facteur limitant, surtout sur catalogues denses, modules gourmands, ou pics de concurrence (soldes). Netdata sait collecter des métriques MySQL/MariaDB et PostgreSQL via ses collectors (souvent en se connectant en local). Évitez d’utiliser un compte DB “admin” : créez un utilisateur de monitoring avec les droits strictement nécessaires (PROCESS, REPLICATION CLIENT, lecture performance_schema selon votre version) et limitez l’accès à localhost.

Sur MySQL/MariaDB, les graphes utiles (au-delà du “CPU DB”) sont :

• Threads_running / Threads_connected (symptôme de saturation applicative ou de pool côté PHP).
• Innodb_row_lock_time / locks (contention, transactions longues, cron mal conçu).
• Buffer pool hit rate (si vous swappez ou lisez disque à chaque requête, vous êtes déjà en panne “soft”).
• Slow_queries (ou mieux : performance_schema + digest, si vous avez un pipeline pour ça).

Lecture pratique (pour éviter les fausses pistes) :

Symptôme visible	Métrique(s) qui confirment	Hypothèse la plus probable	Action typique
Pages lentes aléatoires	Innodb_row_lock_time, Threads_running	Transactions longues / locks	Identifier requêtes, réduire transactions, index ciblés
Lenteur “globale” en pic	buffer pool hit rate ↓, iowait ↑	DB lit trop sur disque	Ajuster buffer pool, réduire working set, revoir indexes
Timeouts intermittents	Connections, erreurs, pics de Threads_connected	Trop de connexions ou pool mal réglé	Pool côté app, max_connections, files d’attente

Ce sont exactement les signaux qui vous évitent de “tuner PHP” alors que vous avez un index manquant ou un tri (ORDER BY) non couvert. Pour une approche maintenance, recoupez avec Base de données PrestaShop : routine de maintenance et nettoyage automatisé.

Sur PostgreSQL, surveillez : connections, xact_commit/xact_rollback, deadlocks, checkpoints, bgwriter (write pressure), et surtout replication lag si vous avez des read replicas. Un point souvent négligé : une hausse des checkpoints (ou des écritures “forcées”) peut donner une latence perçue côté front, même si le CPU est bas. Si vous hésitez encore entre moteurs, le comparatif PostgreSQL vs MySQL 2026 : performances, sécurité et cas d’usage vous donnera une grille plus solide que les débats “religieux”.

Sur Redis (souvent pour cache/sessions/locking), les métriques actionnables sont : taux de hit/miss, used_memory, evicted_keys, latence, et connected_clients. Exemple concret : sur un tunnel de commande, une hausse de evicted_keys corrélée à une augmentation du TTFB peut indiquer un dimensionnement RAM trop juste ou une politique d’éviction inadaptée. Si votre problème métier est la concurrence sur les stocks, vous avez un cas d’usage détaillé dans Performance e-commerce : prévenir la concurrence sur les stocks avec Redis.

Serveurs web et reverse proxies : Nginx, Apache, HAProxy, Varnish — instrumentation minimale

Netdata est efficace quand vous alimentez les collectors avec des endpoints de statut. Pour Nginx, la brique classique est stub_status (ou l’API Nginx Plus si vous l’avez). La règle : exposer l’endpoint uniquement en interne, sinon vous offrez des infos d’attaque (nombre de connexions, etc.).

« The ngxhttpstubstatusmodule module provides access to basic status information. » — NGINX documentation, https://nginx.org/en/docs/http/ngxhttpstubstatusmodule.html

Configuration Nginx typique :

location = /nginx_status {
  stub_status;
  allow 127.0.0.1;
  deny all;
}

Ensuite, Netdata peut collecter active connections, reading/writing/waiting, taux de requêtes. Ces métriques, croisées avec la latence upstream (PHP-FPM), vous donnent une vue claire : est-ce que Nginx attend le backend, ou est-ce que le front est saturé en sockets ? Si vous rencontrez des erreurs de descripteurs, corrélez aussi avec PrestaShop 9 : corriger l’erreur « too many open files ».

Pour Apache, l’équivalent est mod_status (/server-status) : scoreboards, workers occupés, requêtes en cours. Même logique : endpoint local-only + collecte régulière. C’est particulièrement utile si vous avez encore des stacks hybrides (Apache en reverse proxy, ou modules spécifiques), car la saturation “process/thread” est visible immédiatement.

Pour HAProxy, l’endpoint stats (ou socket) est indispensable : sessions, erreurs, retries, latence backend, saturation par backend. En PrestaShop, c’est souvent le meilleur détecteur de dégradation “réseau/SSL” vs “app”. Si vous êtes en phase de déploiement, le guide HAProxy 3.2 : déploiement systemd, configuration frontend/backend, ACL sert de base, puis Netdata vient instrumenter.

Pour Varnish, Netdata s’appuie sur varnishstat : hit rate, backend fetches, bans, threads, busy objects. C’est le combo minimal avec une vérification applicative (ex. header X-Cache/X-Varnish). Un pattern “signal fort” : si le hit rate baisse pendant un pic alors que le trafic augmente, vous pouvez être face à (a) un mauvais VCL, (b) trop de variations (cookies, query params), ou (c) des bans trop agressifs. Si vous êtes sur PrestaShop en Docker, la mise en place et la validation des headers sont détaillées dans PrestaShop Docker : configurer Varnish VCL et valider le cache X-Cache.

Alerting Netdata : règles “health”, seuils réalistes, export vers Grafana/Prometheus

Netdata intègre un système d’alerting (health) basé sur des expressions et des fenêtres temporelles. Dans un contexte e-commerce, évitez les alertes “bruit” (CPU > 80% sur 10s) et privilégiez les symptômes : latence DB, backlog PHP-FPM, erreurs 5xx, saturation file descriptors, timeouts upstream, réplication en retard. Vos seuils doivent être calibrés sur votre baseline (jour normal vs opérations commerciales), sinon vous finissez par couper les notifications.

Une méthode simple pour calibrer sans vous perdre :

1. Choisir 5–8 alertes “P1” maximum (celles qui justifient un réveil).
2. Pour chaque alerte, définir : symptôme, impact client, métriques de confirmation, action immédiate (rollback, scale, purge cache, read-only…).
3. Faire une semaine de “mode observation” (warn-only), puis resserrer.

Exemple d’alarme simple (à adapter à votre naming de charts) :

alarm: nginx_waiting_too_high
on: nginx.connections
lookup: average -1m unaligned of waiting
every: 10s
warn: $this > 200
crit: $this > 500
info: "Trop de connexions Nginx en attente (backends lents ou saturation)."

Deux idées d’alertes “haut rendement” en e-commerce (souvent plus utiles que CPU) :

• Erreurs applicatives vues par le reverse proxy : 5xx backend, retries HAProxy, timeouts upstream.
• Saturation OS : file descriptors, iowait durable, pression mémoire (swap-in, OOM kill), retransmits réseau.

L’exploitation doit se faire avec un runbook : quoi vérifier, dans quel ordre, comment rollback. Sur PrestaShop, un runbook réaliste pointe vers : état du cache (Varnish/Redis), saturation PHP-FPM/OPcache, locks DB, et erreurs applicatives. Pour structurer ça, la méthode de Audit performance PrestaShop : méthode en 6 étapes reproductibles est directement réutilisable.

Enfin, si vous avez besoin de dashboards transverse, Netdata s’intègre très bien dans une chaîne où Grafana est la couche de visualisation commune. Deux options propres :

• Exposer Netdata en format Prometheus/OpenMetrics et laisser Prometheus (ou un agent compatible remote_write) scrapper/ingérer.
• Utiliser Netdata pour le “temps réel” et exporter seulement les métriques critiques vers votre stockage long-terme.

Si vous n’avez pas encore de Grafana propre, partez d’une installation reproductible : Grafana sur Ubuntu : installation APT et configuration initiale. Le piège classique est de vouloir tout centraliser trop tôt : commencez par fiabiliser la collecte (Netdata agents), puis industrialisez l’historisation et les SLO.

Pour boucler la boucle côté performance applicative, gardez en tête que les graphes infra ne remplacent pas les métriques métier (taux de conversion, erreurs checkout, latence de recherche). La valeur de Netdata monitoring est de vous donner une preuve rapide : « c’est la DB », « c’est le cache », « c’est le réseau », « c’est le kernel ». Et cette preuve doit ensuite être traduite en action corrective mesurable (TTFB, 95e percentile, taux d’erreurs), comme discuté dans TTFB PrestaShop : réduire le Time To First Byte sous 200 ms et Performance PrestaShop : benchmarks et optimisation PHP-FPM, OPCache, MySQL.