Netdata : activer et configurer les collectors pour monitoring temps réel

Table des matières :

1. Collector Netdata : définition, plugins et chaîne de collecte
2. Base d’installation et prérequis (Debian 12 / Ubuntu 24.04) + durcissement réseau
3. Activer les collectors utiles à une stack PrestaShop (Nginx, PHP‑FPM, MariaDB, Redis)
4. Redis, HAProxy et collectors « périphériques » qui évitent de diagnostiquer à l’aveugle
5. Réglages fins : fréquence, DB engine, overhead et isolation des credentials
6. Export, alerting et intégration avec Prometheus (sans dénaturer Netdata)
7. Dépannage : collector absent, charts vides, erreurs de droits

Netdata est rarement le problème. Les « collectors » mal choisis, mal configurés ou exposés sans contrôle, eux, le deviennent vite : sur une stack e‑commerce (PrestaShop + MariaDB + PHP‑FPM + reverse proxy), ils déterminent à la fois la qualité du diagnostic (latence, saturation, I/O) et l’empreinte CPU/RAM du monitoring.

Netdata se définit lui‑même comme un système de monitoring temps réel orienté performance et santé, avec une exploration interactive très fine. Référence officielle (README GitHub) : https://github.com/netdata/netdata

Dans une boutique PrestaShop, l’objectif n’est pas d’« avoir des graphes » : c’est de réduire le temps de diagnostic quand le checkout ralentit, quand le back‑office devient impraticable, ou quand des pics de trafic font apparaître des 502/504. La bonne approche consiste donc à :

• activer peu de collectors, mais très corrélés à vos symptômes (FPM, DB, cache, proxy),
• collecter en local et durcir l’exposition,
• garder une fréquence élevée uniquement là où elle a de la valeur (incidents, saturation), et ralentir le reste.

Collector Netdata : définition, plugins et chaîne de collecte

Un collector Netdata est une brique qui collecte des métriques (compteurs, jauges, timings) depuis une source (procfs, socket, API HTTP, commandes). Techniquement, Netdata regroupe ces collectors par plugins (binaires ou scripts) : proc.plugin (Linux /proc), apps.plugin (processus), go.d.plugin (modules Go), python.d.plugin, charts.d.plugin, ebpf.plugin, etc. Le vocabulaire important côté config : chart (graphique/serie), dimensions (sous‑séries), update_every / « update every » (période de collecte selon la syntaxe), labels (tags), et health (règles d’alerte Netdata).

Sur un serveur Debian/Ubuntu typique, l’agent tourne via systemd (service netdata) et écoute par défaut sur le port 19999. Les collectors produisent des charts en mémoire (mode dbengine ou ram) et l’UI/API lit ces séries sans passer par un TSDB externe (Prometheus, Influx, …) sauf si vous activez un exporter.

Deux points pratiques (souvent sous‑estimés) :

• Un collector “réseau” n’est jamais gratuit : si vous sondez 10 endpoints HTTP toutes les secondes (status, API, stats), vous ajoutez du bruit (connexions, parsing, TLS si mal placé) et vous créez des modes de panne (timeout, auth cassée, endpoint mis en cache).
• La qualité des métriques dépend de l’endpoint : un stub_status Nginx local et interdit au monde est excellent ; le même endpoint exposé derrière un reverse proxy qui met en cache, compresse ou transforme la réponse devient une source de métriques incohérentes.

Le point de vigilance : Netdata privilégie la granularité (seconde par seconde) et l’exploration interactive. C’est excellent pour diagnostiquer un incident en cours, mais si vous laissez « tout activé » sur un VPS sous‑dimensionné, vous payez un coût non négligeable (context switches, parsing, connexions) et vous augmentez la surface d’attaque (endpoints de status, credentials en clair, sockets Unix accessibles). Sur un environnement PrestaShop à charge variable, le bon compromis consiste à activer peu de collectors très pertinents (Nginx, PHP‑FPM, MariaDB, Redis, HAProxy) et à durcir l’exposition.

Enfin, gardez en tête le périmètre : Netdata est excellent pour l’infra et les démons, pas pour l’APM applicatif. Une latence PrestaShop peut venir d’un hook, d’une requête N+1, d’un module tiers, d’un cron, etc. Netdata vous aide surtout à distinguer rapidement : CPU vs I/O vs saturation de workers vs contention DB.

Base d’installation et prérequis (Debian 12 / Ubuntu 24.04) + durcissement réseau

Les exemples ci‑dessous sont pensés pour Debian 12 (bookworm) ou Ubuntu 24.04, avec une boutique PrestaShop 9.x servie par PHP 8.3 (PHP‑FPM). Le principe reste identique avec PrestaShop 8.x, mais les goulots changent (back‑office, recherche, imports). Si vous partez d’un serveur « propre », commencez par une base système cohérente (kernel récent, sysctl, I/O scheduler, limites fichiers) — cf. ce guide orienté gros catalogue : Serveur dédié PrestaShop : installation et optimisation Debian pour gros catalogue.

Pour installer Netdata, suivez la doc officielle (script kickstart, packages, ou build). Dans un contexte prod, je privilégie :

• installation via dépôts officiels Netdata (plus simple à patcher),
• service systemd activé,
• UI non exposée publiquement.

Durcissement minimal recommandé dès le départ (sinon vous finissez avec un dashboard « ouvert » sur Internet, et c’est objectivement une mauvaise idée) :

1) forcer l’écoute en local dans /etc/netdata/netdata.conf :

[web]
  bind to = 127.0.0.1
  default port = 19999

2) publier l’UI uniquement via un reverse proxy authentifié (Nginx/HAProxy) + TLS + IP allowlist. Si vous êtes déjà sur HAProxy, vous avez probablement la base pour faire proprement des ACL et health checks (utile aussi pour sécuriser l’accès à l’UI Netdata) : HAProxy : configuration avancée ACL, health checks et sticky sessions.

Astuce simple en environnement d’exploitation (équipes/astreinte) : si vous devez absolument rendre l’UI accessible à distance, préférez un VPN (WireGuard, IPsec) ou au minimum une allowlist d’IP fixes (bureau, bastion) plutôt qu’une exposition globale. Cela limite aussi les risques de fuite d’informations sensibles (noms de process, services internes, chemins).

3) vérifier ce que vous exposez : l’API Netdata donne accès à beaucoup de données (top processus, chemins, noms de services). Traitez ça comme une interface d’administration.

Activer les collectors utiles à une stack PrestaShop (Nginx, PHP‑FPM, MariaDB, Redis)

Pour rester pragmatique, voici un « noyau dur » de collectors qui couvre la majorité des incidents rencontrés en e‑commerce :

Composant	Collector / endpoint	Symptôme typique corrélé	Métriques à surveiller en priorité
Nginx	stub_status	montée connexions / saturation front	connexions actives, reading/writing/waiting
PHP‑FPM	/fpm_status?full	TTFB qui grimpe, 502/504	queue, max_children_reached, actifs/idle, slow
MariaDB	socket/TCP + user RO	pages lentes, back‑office lent	threads, connexions, InnoDB, locks, QPS
Redis	INFO	cache qui saute, DB qui prend tout	evictions, hits/misses, mémoire, clients
HAProxy (si présent)	stats CSV/socket	timeouts, backends down	erreurs, retries, sessions, timeouts

L’idée est de corréler rapidement : si Nginx reste « sain » mais que PHP‑FPM sature, vous n’ouvrez pas un chantier réseau ; si FPM est OK mais MySQL est en contention, vous basculez en analyse SQL.

Nginx : stub_status (signal faible mais immédiat)

Le collector Nginx le plus simple s’appuie sur stub_status. Ça ne remplace pas des métriques applicatives, mais vous donne immédiatement : connexions actives, requêtes, lecture/écriture/attente. Concrètement, ça répond à la question « est‑ce que le front est saturé ou c’est derrière ? ».

Côté Nginx (exemple), exposez un endpoint local :

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

Pour référence, la documentation du module est ici (source officielle Nginx) : https://nginx.org/en/docs/http/ngx_http_stub_status_module.html

Puis activez le module côté Netdata via go.d.plugin (emplacement courant : /etc/netdata/go.d/nginx.conf) :

jobs:
  - name: local
    url: http://127.0.0.1/nginx_stub_status

Limites importantes (à connaître pour éviter les fausses pistes) :

• stub_status n’indique pas la latence, seulement l’activité et le volume : vous verrez « ça bouge », pas « ça répond lentement ».
• Les compteurs sont globaux au worker / au serveur : si vous avez plusieurs vhosts, vous n’aurez pas une vue “par boutique” ou “par domaine”.

PHP‑FPM : status page et signaux de saturation (les vrais KPI)

Pour PrestaShop, le collector PHP‑FPM est souvent plus actionnable que Nginx. Les métriques clés : listen queue, max_children_reached, active/idle processes, slow requests. C’est là que vous voyez une montée en latence avant même que la 5xx explose.

Activez le status côté pool FPM (ex. /etc/php/8.3/fpm/pool.d/www.conf) :

pm.status_path = /fpm_status
ping.path = /fpm_ping

Exposez‑le localement via Nginx, filtré IP :

location = /fpm_status {
  include fastcgi_params;
  fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
  fastcgi_pass unix:/run/php/php8.3-fpm.sock;
  allow 127.0.0.1;
  deny all;
}

Puis configurez le collector (/etc/netdata/go.d/phpfpm.conf) :

jobs:
  - name: www
    url: http://127.0.0.1/fpm_status?full

Mini‑règle de lecture (très utile en prod) :

• Queue qui monte + idle ≈ 0 ⇒ vos workers sont occupés, le front “attend” FPM.
• max_children_reached qui augmente ⇒ vous atteignez la limite pm.max_children (saturation franche).
• “slow requests” qui augmente ⇒ ce n’est pas seulement “pas assez de workers”, c’est aussi “des requêtes PHP trop lentes”.

Exemple concret (dimensionnement rapide, sans sur‑optimiser) : si un worker PHP consomme ~150–250 Mo RSS en charge sur votre shop (modules, OPCache, etc.), et que vous avez 4 Go réellement disponibles pour FPM, un pm.max_children = 40 est probablement irréaliste (risque d’OOM + swap + effondrement). Netdata permet de visualiser le moment où « trop de workers » devient un problème système (swap, iowait, CPU steal sur VPS).

MariaDB/MySQL : threads, QPS, buffer pool et locks

Le cœur PrestaShop reste très dépendant de la base. Le collector MySQL/MariaDB de Netdata remonte (selon config) des métriques beaucoup plus fines que « CPU haut » : Threads_running, Connections, Questions, état InnoDB, buffer pool, I/O, temps de requêtes (selon versions). C’est précisément ce qui vous permet d’orienter un diagnostic vers : manque d’index, cache trop petit, locks, pool PHP‑FPM trop agressif.

Créez un user read-only dédié (exemple minimal) :

CREATE USER 'netdata'@'127.0.0.1' IDENTIFIED BY 'CHANGE_ME';
GRANT PROCESS, REPLICATION CLIENT, SHOW DATABASES, SHOW VIEW ON *.* TO 'netdata'@'127.0.0.1';
FLUSH PRIVILEGES;

Selon votre version MariaDB/MySQL et les métriques que vous voulez, il peut être nécessaire d’ajouter l’accès à performance_schema (certaines stats y vivent). Faites‑le de façon ciblée, et gardez le principe : lecture uniquement.

Puis configurez /etc/netdata/go.d/mysql.conf :

jobs:
  - name: mariadb-local
    dsn: netdata:CHANGE_ME@tcp(127.0.0.1:3306)/

Si votre DB est locale, une variante souvent plus “propre” (et plus simple à contrôler) consiste à passer par le socket Unix au lieu de TCP (et donc à travailler les permissions du socket) :

jobs:
  - name: mariadb-socket
    dsn: netdata:CHANGE_ME@unix(/run/mysqld/mysqld.sock)/

Interprétez ces métriques avec une démarche SQL réelle : Netdata vous dit où ça chauffe, mais ne remplace pas le slow query log et l’analyse d’index. Pour la partie MySQL « action », chaînez avec : PrestaShop MySQL : analyser slow query log et optimiser index.

Redis, HAProxy et collectors « périphériques » qui évitent de diagnostiquer à l’aveugle

Redis : evictions, hit ratio et latence implicite

Si vous utilisez Redis (sessions, cache, modules), le collector Redis est un filet de sécurité. Les métriques qui comptent : used_memory, mem_fragmentation_ratio, evicted_keys, keyspace_hits/misses, connected_clients, parfois instantaneous_ops_per_sec. Une montée de evicted_keys sur un pic de trafic explique souvent une dégradation brutale : le cache « saute », MySQL prend tout, PHP‑FPM sature, et l’infra suit.

Configuration type (/etc/netdata/go.d/redis.conf) :

jobs:
  - name: redis-local
    address: 127.0.0.1:6379
    timeout: 2

Lecture rapide (très utile lors d’un incident) :

• keyspace_misses qui grimpe en même temps que la latence ⇒ vos pages “refont” du SQL.
• evicted_keys > 0 ⇒ Redis manque de mémoire ou la politique d’éviction est inadaptée ; dans les deux cas, le cache devient instable.
• mem_fragmentation_ratio élevé et durable ⇒ vous pouvez avoir de la fragmentation mémoire (selon workload), donc “plus de RAM consommée” à volume de données constant.

Si Redis écoute sur socket Unix (souvent préférable), vous gagnez en perf et vous contrôlez mieux les ACL, mais il faut gérer les permissions : soit vous ajoutez netdata au groupe propriétaire du socket, soit vous posez une ACL (setfacl) ciblée. Ne faites pas un chmod 777 « pour que ça marche ».

HAProxy : erreurs backend, timeouts et sticky sessions qui cassent

Sur des architectures un peu sérieuses (multi‑instances web, blue/green, canary), HAProxy est l’endroit où les problèmes deviennent visibles : backends flapping, timeouts, saturation de connexion, sticky sessions mal configurées. Netdata peut collecter soit via page stats HTTP, soit via socket admin.

Si vous exposez les stats en HTTP, faites‑le en local et protégé :

• stats uri /haproxy?stats
• stats auth user:pass
• allowlist 127.0.0.1

Puis go.d/haproxy.conf :

jobs:
  - name: haproxy-local
    url: http://127.0.0.1:8404/haproxy?stats;csv
    username: user
    password: pass

Ce collector devient vraiment utile quand vous corrélez avec les symptômes front (TTFB, 504) et les métriques PHP‑FPM. Exemple de lecture “terrain” :

• erreurs 502/504 côté client + timeouts backend HAProxy ⇒ souci de disponibilité applicative (FPM, app, DB), pas seulement un problème Nginx.
• backends qui “flap” (UP/DOWN) ⇒ health checks trop agressifs ou serveurs réellement instables (OOM, restart FPM).

Si vous n’avez pas encore une config HAProxy propre, commencez par stabiliser l’existant : HAProxy 3.2 : déploiement LTS sur Ubuntu/Debian, compilation et systemd.

Collectors système à garder (et ceux à couper)

Netdata est très bon sur le socle Linux : CPU, load, RAM, swap, disk I/O, network, cgroups. Ces collectors sont généralement « gratuits » (procfs) et indispensables pour éviter les erreurs d’interprétation (ex. load haut dû à I/O wait, pas à CPU).

En revanche, soyez agressif sur ce que vous n’utilisez pas : Kubernetes, Postgres, RabbitMQ, Elasticsearch, etc. Désactiver des modules go.d inutiles réduit les scans et les connexions. La règle : pas de service ⇒ pas de collector.

Concrètement (méthode simple et réversible) : si un module go.d ne vous sert pas, renommez sa conf en dehors de *.conf (ex. xxx.conf.disabled), puis redémarrez Netdata. Vous évitez ainsi les “tentatives de connexion” en boucle et les erreurs de log qui masquent les vrais problèmes.

Enfin, sur PrestaShop, rappelez‑vous que le cœur ne vous fournit pas de métriques business exploitables en temps réel (sans instrumentation). Netdata couvre l’infra et les démons ; pour le code (controller lents, hooks, requêtes N+1), vous devez profiler ailleurs (Blackfire, Xdebug, APM). Pour relier infra et perf PrestaShop, gardez une approche bout‑en‑bout : PrestaShop performance : optimiser gros catalogues et Core Web Vitals.

Réglages fins : fréquence, DB engine, overhead et isolation des credentials

Paramètres globaux : update_every, rétention, mode mémoire

Le piège classique : laisser update_every = 1 partout, sur une machine qui n’a ni CPU ni I/O à donner. Netdata peut collecter à la seconde, mais vous n’êtes pas obligé. Le tuning dépend de votre objectif :

• incident live (checkout down) ⇒ 1s sur quelques collectors critiques,
• supervision « santé » ⇒ 2–5s suffit souvent,
• métriques MySQL détaillées ⇒ parfois 5–10s sans perte de signal.

Ces réglages se font dans netdata.conf et/ou par plugin. Les paramètres de base :

[global]
  update every = 1
  memory mode = dbengine

[db]
  mode = dbengine

dbengine est généralement le meilleur compromis (persistance + efficacité), mais consomme du disque. Sur de petits VPS, vous pouvez réduire la rétention et/ou baisser la fréquence. Deux leviers simples (souvent efficaces sans se compliquer la vie) :

• réduire la durée d’historique (utile si vous n’utilisez Netdata que comme “loupe” court terme),
• ralentir uniquement les collectors les plus bavards (DB, proxies, endpoints HTTP), tout en gardant le système en 1s si vous aimez le temps réel.

Le KPI à surveiller… c’est Netdata lui‑même : CPU du process netdata, I/O sur son répertoire de base, et nombre de charts. Si vous observez une hausse régulière du nombre de charts/dimensions, c’est souvent le signe d’une config trop large (services détectés automatiquement, modules activés par défaut, ou environnement qui “pullule” de daemons).

Credentials et permissions : évitez le « tout en clair et world-readable »

Beaucoup de collectors nécessitent des secrets (MySQL, HAProxy stats auth). Par défaut, les fichiers /etc/netdata/go.d/*.conf peuvent être lisibles par d’autres users selon votre politique. Fixez ça :

chown -R root:netdata /etc/netdata
chmod -R o-rwx /etc/netdata
find /etc/netdata -type f -name "*.conf" -exec chmod 640 {} \;

Pour les sockets Unix (PHP‑FPM, Redis, HAProxy), la difficulté vient souvent de là : l’agent netdata n’a pas accès. La solution propre n’est pas de relâcher les permissions globalement, mais d’ajouter netdata au bon groupe (ou ACL ciblées). Exemple :

usermod -aG www-data netdata
systemctl restart netdata

Point “GEO / conformité” (utile en pratique, surtout en équipes) : même si Netdata ne collecte pas “des données clients” au sens direct, l’UI peut afficher des noms de process, des chemins, des noms de services internes, parfois des éléments de configuration. Sur un hébergement en France/UE avec contraintes internes (RSSI, prestataires, DPA), évitez les expositions inutiles : accès restreint, journalisation d’accès au reverse proxy, et rotation des identifiants.

Cas réel (PrestaShop) : diagnostiquer une dégradation en 5 minutes

Scénario typique en prod : montée de trafic, TTFB qui grimpe, puis 502/504. Avec un set minimal de collectors :

1) PHP‑FPM : listen queue augmente + max_children_reached > 0 ⇒ pool saturé. 2) MySQL : Threads_running augmente, InnoDB row lock time (ou équivalent) grimpe ⇒ contention/queries lentes. 3) Redis : evicted_keys > 0 ⇒ cache qui ne tient pas, pression sur DB.

Ajoutez une vérification “système” qui évite beaucoup d’erreurs :

• si iowait monte fortement au même moment (disk I/O), ne “blâmez” pas uniquement MySQL : vous avez peut‑être une saturation disque (log bin, flush InnoDB, snapshots, volume réseau, etc.).
• si la swap s’active et que la latence explose, votre tuning FPM (ou un pic mémoire DB) est peut‑être le déclencheur.

L’action n’est pas « augmentez tout ». Vous validez d’abord l’hypothèse via le slow query log, puis vous corrigez (index, requête, pagination, cache applicatif), et ensuite vous ajustez FPM/DB. Autrement, vous masquez le problème et vous achetez du temps… jusqu’au prochain pic.

Export, alerting et intégration avec Prometheus (sans dénaturer Netdata)

Netdata a son propre moteur d’alerting (health checks) et peut notifier (mail, Slack, etc.), mais beaucoup d’équipes ont déjà un pipeline Prometheus/Alertmanager/Grafana. Dans ce cas, Netdata sert soit de « loupe temps réel », soit de source de métriques exportées.

« Prometheus is an open-source systems monitoring and alerting toolkit originally built at SoundCloud. » — Prometheus (site officiel) : https://prometheus.io/

Activer l’export Prometheus côté Netdata permet d’ingérer un sous‑ensemble des métriques dans votre stack existante, pour des alertes long terme (SLO, capacity planning). Ensuite, la configuration des règles et requêtes se traite côté Prometheus : Prometheus : configuration des alertes, métriques et requêtes PromQL.

Côté stratégie, évitez de dupliquer « tout Netdata dans Prometheus » : c’est coûteux (cardinalité, stockage) et souvent inutile. Exportez quelques séries stables et essentielles :

• saturation FPM (phpfpm_max_children_reached, queue),
• erreurs HTTP (Nginx/HAProxy),
• santé DB (connections, threads running, buffer pool pressure),
• I/O wait et saturation disque.

Un bon compromis (souvent efficace en e‑commerce) : Prometheus pour l’historique/alerting, Netdata pour le temps réel pendant l’incident. Vous gardez le meilleur des deux mondes sans exploser la volumétrie.

Dépannage : collector absent, charts vides, erreurs de droits

Quand un collector n’apparaît pas, ne partez pas dans des suppositions. Appliquez une routine reproductible :

1) vérifier l’état du service :

systemctl status netdata
journalctl -u netdata -n 200 --no-pager

2) lire les logs Netdata : souvent /var/log/netdata/error.log (ou via journal). Cherchez des erreurs de type permission denied, connection refused, timeout.

3) valider l’endpoint du service indépendamment :

• Nginx stub : curl -sS http://127.0.0.1/nginx_stub_status
• FPM status : curl -sS http://127.0.0.1/fpm_status?full
• HAProxy stats CSV : curl -u user:pass -sS http://127.0.0.1:8404/haproxy?stats\;csv | head

Astuce qui fait gagner du temps sur les problèmes de droits : testez les endpoints/sockets en tant que user netdata, pas seulement en root (sinon vous validez un accès que le collector n’a pas) :

sudo -u netdata curl -sS http://127.0.0.1/fpm_status?full | head

Les problèmes les plus fréquents en prod :

• endpoint accessible seulement en IPv6/IPv4 (mismatch),
• auth activée côté service mais pas côté collector,
• socket Unix non lisible par netdata,
• firewall local (nftables/ufw) trop strict même sur loopback (rare mais vu),
• sandbox systemd : certains durcissements empêchent l’accès à des chemins (selon distro/packaging).

Enfin, si vous voyez des charts mais « incohérents », le bug est souvent de votre côté : endpoint de status mis en cache, reverse proxy qui gzip/altère la réponse, ou un status PHP‑FPM exposé via une location qui passe par try_files (et renvoie du HTML). Gardez l’endpoint de métriques simple, local, non cacheable, et testable au curl.

Pour aller plus loin sur la supervision e‑commerce (infra + applicatif + alerting), vous pouvez compléter Netdata avec une brique d’alerting métier/ops selon vos flux (Slack/Discord/email), en restant pragmatique : PrestaShop : module d’alerting temps réel Slack, Discord et email.