Netdata : intégrer Prometheus, SNMP et StatsD pour tout surveiller

Table des matières :

Netdata comme couche temps réel au-dessus d’un stack e-commerce (et ses limites)

Sur une stack PrestaShop moderne (ex. PrestaShop 9.2, PHP 8.3, Nginx, PHP-FPM, MariaDB, Redis), la plupart des incidents « incompréhensibles » sont en réalité des problèmes de saturation, de latence ou d’erreurs qui auraient été visibles en métriques 2 à 5 minutes avant l’impact utilisateur. Netdata a un avantage concret : il produit des séries temporelles à très haute résolution avec un coût d’installation faible, et donne une vue « animée » des symptômes (CPU steal, iowait, backlog PHP-FPM, threads MySQL, congestions réseau) sans devoir passer immédiatement par une stack d’observabilité complète.

Dans un contexte e-commerce (pics « soldes », campagnes SEA, emailings, Black Friday), cette vue temps réel est particulièrement utile parce que les incidents sont souvent progressifs : la latence monte d’abord, puis les timeouts et les 5xx arrivent ensuite. Un exemple typique côté PrestaShop :

TTFB qui grimpe sans hausse de trafic → souvent iowait (disque), contention DB, cache qui décroche.
Checkout lent uniquement → saturation PHP-FPM sur un pool précis, ou latence DB sur des requêtes liées au panier.
Erreur 500 intermittente → max_children atteint, OOM killer, redémarrages PHP-FPM, ou timeouts upstream Nginx.

Netdata rend ces signaux lisibles « minute 0 », là où une stack orientée historique nécessite souvent de trouver le bon dashboard ou d’écrire la requête.

Netdata n’est pas un remplacement « drop-in » de Prometheus. Son stockage local (DBEngine) est optimisé pour la haute fréquence et la rétention courte/moyenne, là où Prometheus excelle pour l’historique, la corrélation long terme et l’écosystème d’alerting via PromQL. Dans la pratique, Netdata est très efficace comme poste de pilotage temps réel, et Prometheus (ou une TSDB compatible) comme réservoir long terme.

Limites à garder en tête (pour éviter les déceptions) :

Historique long terme : Netdata est excellent pour « ce qui se passe maintenant / il y a 2h », mais pour « comparer cette semaine vs le mois dernier » ou faire des SLO sur 30 jours, Prometheus est plus naturel.
Cardinalité : Netdata peut ingérer des métriques Prometheus, mais si vous avalez des séries ultra-labellisées, vous pouvez dégrader l’agent lui-même (mémoire, disque, CPU).
Gouvernance : « tout collecter » ne vaut pas « tout comprendre ». Sans convention de nommage et sans métriques stables, vous obtenez des graphiques inutilisables.

La philosophie reste celle des SRE. Dans Site Reliability Engineering (Beyer et al., O’Reilly, 2016), le chapitre sur le monitoring explique que le monitoring est l’un des moyens principaux permettant aux responsables de service de suivre la santé et la disponibilité d’un système (« Monitoring is one of the primary means by which service owners keep track of a system’s health and availability. »). Traduction opérationnelle : sans monitoring exploitable, vous faites du diagnostic à l’aveugle, et vous finissez sur des heuristiques (« redémarre PHP-FPM ») plutôt que sur des actions ciblées. Netdata + Prometheus + SNMP + StatsD est justement une manière pragmatique d’aligner infra, réseau et applicatif autour des mêmes signaux — sans exiger d’emblée une plateforme d’observabilité lourde.

Architecture cible : unifier Prometheus, SNMP et StatsD autour de Netdata

Quand on dit “Netdata : intégrer Prometheus, SNMP et StatsD pour tout surveiller”, le point clé n’est pas l’outil, mais le modèle de collecte. Prometheus est principalement en pull (scrape de endpoints /metrics), StatsD est historiquement en push UDP (fire-and-forget), SNMP est du polling sur des agents réseau (switch, firewall, onduleur, hyperviseur). Une architecture réaliste doit accepter ces trois patterns, sinon vous aurez des trous de métriques.

Rappel officiel (utile pour cadrer le vocabulaire) : la doc Prometheus définit le projet comme « an open-source systems monitoring and alerting toolkit originally built at SoundCloud » (Prometheus Documentation, section Overview : Prometheus Overview). Autrement dit : Prometheus est une brique d’agrégation/alerting et de requêtage, pas une UI temps réel orientée « troubleshooting minute 0 ». Netdata comble précisément cet angle.

Une manière simple de « poser l’architecture » est de clarifier qui collecte quoi et pour quel horizon :

Source	Protocole / pattern	Typique en e-commerce	Valeur principale	Horizon
Netdata collectors (OS/services)	local, haute fréquence	CPU, RAM, IO, réseau, cgroups, services	diagnostic instantané	minutes → heures/jours
Exporters Prometheus	pull `/metrics`	MySQL, Redis, Nginx, PHP-FPM exporter	alerting + historisation	jours → mois
SNMP (via exporter ou collector)	polling	switch, firewall, UPS, hyperviseur	fiabilité matériel/réseau/énergie	jours → mois
StatsD (dans l’app)	push UDP	checkout, paiement, API, hooks	métriques applicatives & métier	minutes → mois (si centralisé)

Le pattern qui marche bien en prod e-commerce :

Netdata Agent sur chaque nœud (VM, bare-metal, conteneur host-network), pour les métriques OS et services.
Collecte Prometheus côté Netdata (Netdata scrappe des exporters existants : nodeexporter, mysqldexporter, php-fpm exporter, etc.).
SNMP : soit collecté nativement par Netdata (si vous standardisez ce collector), soit via Prometheus snmp_exporter (recommandé quand vous avez déjà des modules SNMP et une gouvernance OID).
StatsD : Netdata comme daemon StatsD local pour instrumenter l’app (PrestaShop / modules) sans introduire un agent supplémentaire.

Deux points qui font souvent la différence en production (et qui évitent des « incohérences » difficiles à expliquer) :

Synchronisation temporelle : assurez NTP/Chrony partout (nœuds, Prometheus, machines de management). Sans horodatage cohérent, la corrélation « réseau → PHP-FPM → DB » devient trompeuse.
Convention de noms : décidez tôt de vos préfixes (ex. prestashop.), de vos unités (_ms, _total), et de ce qui est interdit (ex. IDs de commande, d’utilisateur, de produit).

Ce découpage évite un piège courant : mettre Prometheus partout “par principe”, puis se retrouver avec des dashboards illisibles pour l’analyse instantanée d’un incident (ou, pire, des trous parce que les scrapes échouent au moment où le nœud est saturé).

Intégrer Prometheus : scrapes d’exporters et exposition des métriques Netdata

Pré-requis (exemples testés en contexte 2026) : Debian 12 (systemd), Netdata Agent récent (branche stable), accès root, et un Prometheus (2.x) accessible sur le réseau d’admin. Côté boutique, gardez en tête que PrestaShop ne fournit pas de métriques natives exploitables : votre vérité vient de PHP-FPM, MySQL/MariaDB, Redis, et de votre instrumentation applicative (voir StatsD plus bas). Pour la partie Netdata “collectors”, la référence interne du site est déjà publiée : Netdata : activer et configurer les collectors pour monitoring temps réel.

À ce stade, l’objectif n’est pas « faire du Prometheus dans Netdata » ou l’inverse, mais d’obtenir :

un écran incident unique (Netdata) pour le temps réel ;
une capacité d’analyse rétrospective (Prometheus) pour comprendre tendances, régressions et SLO.

1) Faire scraper des endpoints Prometheus par Netdata (approche « j’agrège »)

Le cas concret : vous avez déjà des exporters Prometheus (ex. mysqld_exporter, php-fpm_exporter, redis_exporter) parce que votre équipe SRE les utilise, mais vous voulez les voir en temps réel dans Netdata, sur le même écran que l’iowait et la saturation CPU. Netdata sait ingérer des endpoints Prometheus via son collector dédié (le plus souvent dans le plugin go.d). L’idée n’est pas de remplacer PromQL, mais de réduire le mean time to understand pendant l’incident.

Exemple de fichier (schéma indicatif : vérifiez le nom exact du fichier selon votre installation Netdata, typiquement sous /etc/netdata/go.d/ ou /etc/netdata/go.d/prometheus.conf) :

jobs:
  - name: node_exporter_local
    url: http://127.0.0.1:9100/metrics

  - name: mysqld_exporter_local
    url: http://127.0.0.1:9104/metrics

  - name: redis_exporter_local
    url: http://127.0.0.1:9121/metrics

Point de vigilance : côté Prometheus, la cardinalité est “contrôlée” par les labels ; côté Netdata, si vous ingérez des métriques très labellisées (ex. par path, user_id, product_id), vous allez créer une explosion de séries (RAM, CPU, disque). En e-commerce, c’est un anti-pattern : limitez-vous à des métriques agrégées (pool PHP-FPM, DB, cache, queue).

Checklist rapide « anti-explosion » avant d’ajouter un endpoint Prometheus dans Netdata :

Éviter toute métrique labellisée par identifiant (commande, panier, client, SKU, IP).
Préférer les métriques par pool (PHP-FPM), par instance DB, par rôle (frontend/admin/worker) plutôt que par route.
Valider le coût : activer l’ingestion, observer RAM/CPU Netdata pendant 10–15 minutes, puis décider.

2) Exposer Netdata au format Prometheus (approche « je centralise dans Prometheus »)

L’autre sens est tout aussi utile : vous gardez Prometheus comme source long terme et moteur d’alerting, mais vous exposez les métriques Netdata (OS + services) au format Prometheus. Concrètement, Prometheus va scrapper un endpoint Netdata dédié, et vous pourrez écrire des alertes PromQL dessus. Pour les alertes, vous avez un article interne à relier : Prometheus : configuration des alertes, métriques et requêtes PromQL.

Exemple de job Prometheus (à adapter à votre réseau) :

scrape_configs:
  - job_name: 'netdata'
    metrics_path: '/api/v1/allmetrics'
    params:
      format: ['prometheus']
    static_configs:
      - targets:
          - 'shop-1.internal:19999'
          - 'shop-2.internal:19999'

Deux détails qui évitent des surprises :

Scrape interval : Prometheus n’a pas besoin de scrapper Netdata à 1 seconde. Gardez Netdata pour la seconde-by-seconde, et scrappez à 10–30s selon votre stratégie d’alerting (et selon le coût acceptable).
Séparation des usages : si vous alertez avec Prometheus, écrivez des règles sur des signaux « stables » (taux d’erreur, saturation durable), pas sur des micro-spikes.

Risque sécurité évident : l’interface Netdata (port 19999 par défaut) ne doit pas être exposée publiquement. Mettez-la derrière un reverse proxy (TLS + auth), ou limitez par firewall aux IP d’admin et au Prometheus. Si vous êtes déjà dans une démarche de durcissement, reliez cela à Symfony : sécuriser un serveur PHP avec hardening et gestion CVE (les principes réseau/TLS/auth restent identiques).

Enfin, note de conformité (utile en Europe/France) : si vos métriques ou labels peuvent contenir des données directement ou indirectement personnelles (par exemple un identifiant client), vous créez un risque RGPD inutile. Le règlement (UE) 2016/679 (RGPD) rappelle dans son article 32 l’obligation de mettre en œuvre des mesures techniques et organisationnelles appropriées pour la sécurité du traitement. Concrètement : évitez d’envoyer des identifiants dans les métriques, segmentez l’accès aux dashboards, et conservez des durées de rétention cohérentes avec l’objectif.

SNMP : superviser réseau et énergie sans bricoler des scripts maison

SNMP n’est pas “old school”, c’est simplement le protocole le plus répandu pour obtenir des compteurs fiables sur du matériel réseau/énergie : erreurs interfaces, débit, CRC, température, état des alimentations, charge onduleur, etc. En e-commerce, l’intérêt est direct : beaucoup d’« erreurs 500 » et de lenteurs sont en réalité des problèmes réseau (perte, duplex mismatch, saturation uplink) ou des incidents d’alimentation/UPS qui dégradent la perf. Sur la partie diagnostic incident, vous pouvez relier côté applicatif à Erreur 500 PrestaShop : 10 causes fréquentes et solutions rapides : sans métriques réseau, vous incriminez PHP alors que c’est un switch qui drop.

Ce que SNMP apporte « de plus » que des checks ping/HTTP :

des compteurs (octets, erreurs, discards) qui permettent de dire quand le problème a commencé et à quel rythme il s’aggrave ;
des états (alimentation, ventilateurs, température) qui expliquent des dégradations progressives (throttling, erreurs, instabilité) ;
une visibilité sur des dépendances « hors serveurs » (switch TOR, firewall, lien opérateur, UPS) qui ne publient pas d’endpoint Prometheus.

Sur le plan sécurité, évitez SNMPv2c sur des réseaux non maîtrisés : la community est un secret en clair. Si vous devez y rester (matériel legacy), segmentez : VLAN de management, ACL strictes, pas de routage depuis Internet, et rotation des communities. SNMPv3 (authPriv) est préférable, mais plus long à déployer (gestion des users, auth, privacy). Dans tous les cas, documentez qui a accès et pourquoi.

Option recommandée : SNMP via snmp_exporter Prometheus, puis ingestion dans Netdata

Si vous avez déjà Prometheus, snmp_exporter est la voie la plus industrialisable : vous versionnez les modules (OIDs) et vous gardez un modèle uniforme. Repo officiel : snmp_exporter on GitHub. Le flux est simple : snmp_exporter poll en SNMP, expose en /metrics, Netdata scrappe cet endpoint comme n’importe quel exporter Prometheus.

Exemple minimal (Prometheus) :

scrape_configs:
  - job_name: 'snmp'
    static_configs:
      - targets:
          - 10.0.10.2  # switch
          - 10.0.10.3  # ups
    metrics_path: /snmp
    params:
      module: [if_mib]
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: snmp-exporter.internal:9116

Ensuite, côté Netdata, vous ajoutez un job Prometheus pointant sur http://snmp-exporter.internal:9116/metrics (ou sur le endpoint spécifique si vous préférez). Le gain pratique : vous pouvez corréler erreurs interface (ifInErrors, ifOutErrors) et latence checkout (StatsD ou exporter applicatif) sans multiplier les outils.

Deux bonnes pratiques SNMP qui améliorent la qualité des graphes :

Fréquence : 30s à 60s est souvent un bon compromis (réseau). Trop rapide surcharge les équipements et l’exporter ; trop lent masque les micro-coupures.
Compteurs 64-bit : sur des liens > 1Gbps, utilisez les compteurs haute capacité (souvent ifHCInOctets/ifHCOutOctets) pour éviter les resets/overflows qui « cassent » les courbes.

Mini-scénario de corrélation (typique) : votre équipe voit une hausse de prestashop.checkout.validate_order_ms (StatsD) et suspecte la DB. Dans Netdata, vous notez simultanément une hausse de retransmissions TCP côté serveur et, via SNMP, une montée de ifInErrors sur le port uplink du switch. Action : corriger le lien (câble/SFP/duplex), au lieu d’augmenter des max_children PHP-FPM (qui ne ferait qu’augmenter la pression).

StatsD : instrumenter PrestaShop et vos modules (latence, erreurs, métier)

Le cœur PrestaShop n’est pas pensé pour l’observabilité : vous avez des logs, quelques pages de diagnostic, mais pas de métriques applicatives standardisées. Pour obtenir des signaux type SRE (latency / traffic / errors / saturation), StatsD est une option pragmatique : facile à émettre depuis PHP, peu intrusif, compatible UDP, et Netdata sait recevoir/agréger. C’est typiquement ce qui manque quand vous faites un audit performance checkout : vous savez que “c’est lent”, mais pas où (contrôleur, hook, appel API, requête SQL).

Côté Netdata, l’approche saine est d’activer StatsD uniquement en local (sur le serveur applicatif), et de limiter les namespaces. Exemple de configuration (indicative) dans /etc/netdata/netdata.conf :

[statsd]
  enabled = yes
  listen = udp:127.0.0.1:8125

N’ouvrez pas UDP 8125 au réseau entier “pour aller vite”. StatsD n’a pas de notion d’auth, et vous vous exposez à de l’injection de métriques (pollution dashboards, voire déni de service si vous acceptez trop de paquets). Si vous devez centraliser, faites-le via un réseau privé + filtrage, ou préférez une solution chiffrée.

Pour que StatsD reste maintenable, imposez quelques règles simples (elles évitent 80% des dérives) :

Noms stables et lisibles : prestashop.checkout.*, prestashop.payment.*, prestashop.search.*.
Unités explicites : suffixes _ms, _bytes, _total.
Pas d’étiquettes dynamiques dans le nom : pas de order_123, pas de user_456, pas de chemin URL brut.
Échantillonnage (si besoin) : sur des endpoints très fréquents, vous pouvez sampler côté client (ex. 0,1) pour réduire la charge, tout en gardant une tendance exploitable.

Exemple concret : métriques checkout PrestaShop 9.2 / PHP 8.3

Dans un module, vous pouvez instrumenter un temps de traitement autour d’un hook critique (ex. actionValidateOrder) et compter les erreurs de paiement. Exemple simplifié (pseudo-code) avec un client StatsD PHP ; l’important est la stabilité des noms (pas de labels dynamiques type order_id) :

$statsd->timing('prestashop.checkout.validate_order_ms', $durationMs);
$statsd->increment('prestashop.checkout.payment_error_total');
$statsd->gauge('prestashop.cart.items', $itemsCount);

Ce trio est déjà exploitable : latence (timing), erreurs (counter), charge (gauge). Ensuite, vous corrélez dans Netdata avec PHP-FPM (listen queue, max children reached), et côté base avec des indicateurs MySQL (threads running, slow queries).

Quelques métriques additionnelles, « peu nombreuses mais très rentables », qui collent bien à une boutique FR/EU (paiement, TVA, transporteurs, ERP) :

prestashop.payment.provider_timeout_total : timeouts vers PSP (utile pour distinguer incident interne vs externe).
prestashop.webhook.incoming_total et prestashop.webhook.error_total : pour les intégrations (ERP, marketplaces).
prestashop.search.no_result_total : indicateur produit/SEO (attention à ne pas lier à l’utilisateur).
prestashop.cron.duration_ms + prestashop.cron.error_total : pour détecter les tâches qui déraillent avant d’impacter le front.

Pour relier ces symptômes au reste du tuning, l’article interne pertinent est Optimisation PrestaShop : audit performance checkout et plan d’action.

Corrélation et alerting : transformer des courbes en décisions (et éviter les fausses alertes)

Netdata fournit des alertes (Health) et surtout une corrélation visuelle extrêmement rapide : vous voyez simultanément la saturation CPU, l’iowait, le réseau, les erreurs applicatives StatsD, et les métriques issues de Prometheus exporters. C’est ce qui fait gagner du temps quand vous cherchez l’origine d’un “PrestaShop lent” : est-ce un pool PHP-FPM sous-dimensionné ? un MySQL en mutex contention ? un Redis qui swap ? ou un lien réseau instable ? Pour l’axe diagnostic infra, reliez à PrestaShop lent : diagnostic TTFB, bots et optimisation serveur.

Là où il faut être strict : l’alerting doit être actionnable. Un seuil CPU à 90% sans contexte est souvent une fausse alerte (CPU à 90% peut être OK si la latence reste stable). Préférez des alertes sur saturation réelle et impact utilisateur. Une grille simple, très « e-commerce » :

Symptôme utilisateur : hausse latence checkout / hausse 5xx / timeouts paiement.
Cause probable : saturation PHP-FPM (queue), DB (threads, locks), cache (hit ratio), réseau (retransmits/erreurs SNMP), stockage (iowait).
Action : augmenter/ajuster pool, optimiser requête/module, restaurer cache, corriger réseau, corriger IO.

Côté PHP-FPM par exemple, les alertes les plus utiles ne sont pas « CPU haut », mais :

queue qui monte et ne redescend pas ;
max_children atteint (saturation franche) ;
augmentation simultanée du temps de réponse + montée de la queue (corrélation forte).

Côté cache, une dégradation du hit ratio Redis/Varnish a généralement un impact direct sur la latence : pour la stratégie, reliez à Cache PrestaShop : stratégie 2026 OPcache, Redis, Varnish et CDN.

Pour l’historique et les alertes complexes, laissez Prometheus jouer son rôle : Netdata vous aide à comprendre le présent, Prometheus vous permet d’exprimer des SLO/SLA sur des fenêtres longues. Exemple : alerter si le p95 de prestashop.checkout.validate_order_ms dépasse 1200 ms pendant 15 minutes, tout en filtrant les périodes de maintenance.

Même sans entrer dans une formalisation complète des SLO, vous pouvez déjà éviter les fausses alertes avec deux garde-fous :

fenêtre temporelle : déclencher sur une durée (ex. 10–15 min), pas sur un point ;
double condition : ex. latence et taux d’erreur, ou latence et saturation (queue).

Netdata n’empêche pas ça ; il vous évite juste de perdre 30 minutes à “construire la preuve” pendant l’incident.

Mise en production : ports, ressources, conteneurs, et garde-fous

Sur un serveur PrestaShop (Debian 12, PHP 8.3), Netdata consomme typiquement quelques centaines de Mo selon la rétention et le nombre de charts. Le risque n’est pas tant CPU que IO et RAM si vous laissez des collectors inutiles ou si vous ingérez des métriques trop cardinalisées (Prometheus) ou trop variées (StatsD). Appliquez la même discipline que pour PHP-FPM : vous dimensionnez, vous mesurez, vous ajustez. Sur le plan purement serveur, l’article interne qui cadre bien le contexte infra est Serveur dédié PrestaShop : config Nginx PHP-FPM MariaDB Redis.

Garde-fous simples (souvent suffisants) :

Désactiver ce qui n’est pas utile : collectors non pertinents (ex. Kubernetes si vous êtes sur VM simple).
Limiter l’ingestion StatsD : quelques dizaines de métriques bien choisies valent mieux que 500 métriques instables.
Surveiller Netdata lui-même : RAM, CPU, IO du processus Netdata/DBEngine (sinon vous créez un « observateur qui perturbe »).

Exposition réseau : par défaut, le dashboard Netdata écoute sur 19999. En prod, la règle est simple : pas d’exposition Internet. Reverse proxy (Nginx) + TLS + auth, et filtrage IP. Pour StatsD, écoutez en 127.0.0.1 sauf raison solide. Pour SNMP, n’autorisez le polling que depuis votre réseau de supervision. Si vous faites du durcissement conteneurs, la logique est identique : capabilities minimales, réseau restreint, secrets hors image (voir CIS Benchmark Docker : exigences clés pour images conteneurisées conformes).

Un petit tableau « ports et exposition » (utile pour valider avec l’équipe réseau/sécu) :

Composant	Port(s)	Doit être accessible depuis	Recommandation
Netdata UI/API	19999/TCP	réseau d’admin + Prometheus	firewall + reverse proxy TLS + auth
Prometheus exporters locaux	divers (9100, 9104, 9121…)	localhost ou réseau d’admin	privilégier `127.0.0.1` si possible
StatsD (Netdata)	8125/UDP	localhost uniquement	ne pas exposer publiquement
SNMP (équipements)	161/UDP	snmp_exporter / poller	VLAN mgmt + ACL, SNMPv3 si possible
snmp_exporter	9116/TCP	Prometheus/Netdata	réseau d’admin uniquement

En environnement Docker/Kubernetes, évitez l’erreur “je mets Netdata en conteneur sans accès host” : vous perdez l’intérêt (métriques kernel/cgroups, fs, réseau). Si vous devez conteneuriser, documentez précisément les mounts (/proc, /sys), le mode réseau, et les permissions. Côté orchestration, vous pouvez vous appuyer sur des patterns déjà couverts sur le site : Docker Compose : orchestrer des services multi-conteneurs en production et, si vous migrez, Migration PrestaShop vers Kubernetes : checklist GitOps et pièges courants.

Enfin, ne confondez pas “tout surveiller” avec “tout collecter”. Le but est d’avoir une couverture forte sur : saturation (CPU/RAM/IO), disponibilité (health checks), performance (latences applicatives), erreurs (5xx, exceptions), et dépendances (DB/cache/réseau). Avec Netdata + Prometheus + SNMP + StatsD, vous avez une chaîne cohérente — à condition de garder la maîtrise de la cardinalité, des ports, et de la gouvernance des métriques.