Monitorer les performances de son VPS avec Netdata

Sur un VPS, une hausse de charge, un manque de mémoire ou un disque saturé peut rapidement ralentir un site, une base de données ou une API. Les commandes comme top, free ou iostat donnent une photographie utile, mais elles montrent difficilement l’évolution d’un problème et les relations entre plusieurs ressources.

Netdata fournit un monitoring très détaillé en temps réel. Son agent collecte des métriques chaque seconde, génère automatiquement des tableaux de bord et signale les comportements anormaux. Il convient aussi bien à un VPS personnel qu’à un serveur de production, à condition de sécuriser strictement l’accès à son interface.

Ce que Netdata permet de surveiller

Une installation standard détecte automatiquement la majorité des ressources et services présents sur le VPS. Le tableau de bord affiche notamment :

• l’utilisation de chaque coeur CPU, la charge système et les changements de contexte ;
• la RAM disponible, les caches, les buffers et l’utilisation du swap ;
• les entrées et sorties disque, la latence, le débit et l’espace disponible ;
• le trafic réseau, les erreurs, les paquets perdus et les connexions ;
• les processus actifs et leur consommation ;
• les températures matérielles lorsque les capteurs sont accessibles ;
• les services systemd et leur état ;
• les conteneurs Docker et leurs ressources ;
• les métriques de services comme Nginx, Apache, MySQL, PostgreSQL ou Redis lorsqu’un collecteur compatible est configuré.

Les graphiques sont créés automatiquement et actualisés avec des métriques à la seconde. Netdata conserve également un historique local, ce qui permet de remonter dans le temps avant un incident.

L’outil inclut des alertes préconfigurées et des fonctions de détection d’anomalies. Il peut ainsi signaler une saturation CPU, une pression mémoire, un espace disque faible, une hausse inhabituelle de latence ou l’arrêt d’un service. Malgré ce niveau de détail, l’agent reste relativement léger. Sa consommation dépend surtout du nombre de métriques collectées et de la durée de rétention.

Prérequis

Pour installer Netdata, il faut disposer :

• d’un VPS Linux compatible ;
• d’un accès SSH ;
• d’un compte root ou des droits sudo ;
• d’assez d’espace disque pour conserver les métriques.

Les VPS TalCloud constituent une base adaptée à ce type de supervision grâce à leur stockage NVMe, leurs serveurs situés en France, leur protection Anti-DDoS Netrix et leur support humain, à partir de 4,99 € par mois.

Installer Netdata avec le script officiel

La méthode recommandée par le projet consiste à télécharger puis exécuter son script Kickstart. Avec curl :

curl -Ss https://get.netdata.cloud/kickstart.sh -o /tmp/netdata-kickstart.sh
sudo sh /tmp/netdata-kickstart.sh

Le script détecte la distribution, installe les dépendances nécessaires et choisit une méthode d’installation appropriée. Il installe également l’agent Netdata et configure son démarrage automatique.

Vérifiez ensuite le service :

sudo systemctl status netdata

Si nécessaire, activez-le et démarrez-le immédiatement :

sudo systemctl enable --now netdata

Netdata lance alors un serveur web qui écoute normalement sur le port TCP 19999.

Une installation depuis les paquets de la distribution reste possible :

sudo apt update
sudo apt install netdata

Cette solution s’intègre bien au gestionnaire de paquets, mais la version fournie par Debian ou Ubuntu peut être plus ancienne que celle proposée par le projet Netdata. Sur Fedora ou une distribution utilisant DNF, le nom du paquet et sa disponibilité dépendent des dépôts activés.

Sécuriser impérativement le port 19999

Le tableau de bord Netdata ne doit pas être exposé directement sur Internet. Il révèle de nombreuses informations sur le VPS : ressources matérielles, interfaces réseau, processus, services, conteneurs, noms de disques et comportement de la charge.

La solution la plus simple consiste à limiter l’écoute à l’interface locale. Ouvrez le fichier /etc/netdata/netdata.conf :

sudo nano /etc/netdata/netdata.conf

Ajoutez ou modifiez la section suivante :

[web]
    bind to = 127.0.0.1

Redémarrez ensuite l’agent :

sudo systemctl restart netdata

Vérifiez que le port n’écoute que localement :

sudo ss -lntp | grep 19999

Une adresse 127.0.0.1:19999 indique que l’interface n’est pas accessible directement depuis Internet. Le pare-feu du VPS doit également refuser les connexions publiques vers ce port.

Deux autres architectures sont possibles :

• placer Netdata derrière un reverse proxy Nginx ou Apache avec HTTPS et authentification Basic ;
• rendre l’interface accessible uniquement à travers un VPN privé, par exemple WireGuard.

Un reverse proxy convient à une équipe qui souhaite utiliser un nom de domaine, mais il doit impérativement imposer une authentification et TLS. Un VPN offre une isolation réseau plus forte lorsque plusieurs administrateurs ou plusieurs serveurs doivent être supervisés.

Accéder au tableau de bord par tunnel SSH

Le tunnel SSH est généralement l’option la plus simple et la plus sûre pour un seul VPS. Depuis le poste de l’administrateur, lancez :

ssh -L 19999:127.0.0.1:19999 utilisateur@adresse-du-vps

Tant que cette connexion reste ouverte, le navigateur local peut accéder au tableau de bord à cette adresse :

http://127.0.0.1:19999

Le port 19999 n’est alors jamais publié. Les requêtes passent dans la connexion SSH chiffrée et rejoignent l’agent via l’interface locale du VPS.

Si le port local est déjà utilisé, choisissez-en un autre, par exemple 29999 :

ssh -L 29999:127.0.0.1:19999 utilisateur@adresse-du-vps

L’adresse locale devient alors http://127.0.0.1:29999.

Comprendre le tableau de bord

La page d’accueil présente une vue générale de l’état du serveur. Les indicateurs les plus importants sont regroupés par catégories : CPU, mémoire, disques, réseau, processus, applications et conteneurs.

Commencez par rapprocher plusieurs graphiques. Une charge élevée accompagnée d’une utilisation CPU faible peut indiquer des processus bloqués sur les entrées et sorties. Une hausse du swap associée à une baisse de la mémoire disponible signale plutôt une pression sur la RAM. Une latence disque élevée peut expliquer le ralentissement simultané d’une base de données et d’un serveur web.

Les alarmes actives apparaissent dans la zone de notification. Elles possèdent généralement plusieurs niveaux, dont avertissement et critique. Avant de modifier un seuil, observez le comportement normal du VPS sur plusieurs jours afin d’éviter les faux positifs.

Les graphiques permettent de sélectionner une période et de consulter l’historique. Cette fonction est précieuse après un incident : elle aide à déterminer si la saturation est soudaine, progressive ou récurrente.

Configurer les alertes et notifications

Netdata installe de nombreuses règles de santé par défaut. Leur état peut être contrôlé avec :

sudo systemctl status netdata
sudo journalctl -u netdata

Les fichiers de configuration se trouvent généralement sous /etc/netdata. Pour personnaliser les canaux de notification, utilisez le fichier health_alarm_notify.conf. Selon le mode d’installation, l’outil d’édition fourni peut être appelé ainsi :

cd /etc/netdata
sudo ./edit-config health_alarm_notify.conf

Ce fichier permet notamment de configurer l’envoi vers un serveur de messagerie, Discord ou Slack. Les paramètres exacts dépendent du canal retenu : adresse du destinataire, webhook, identifiant de salon ou méthode d’envoi des courriels.

Protégez ce fichier, car il peut contenir des secrets :

sudo chmod 600 /etc/netdata/health_alarm_notify.conf

Après toute modification, redémarrez Netdata et contrôlez son journal. Il est préférable de tester les notifications avant de compter dessus pour un serveur de production.

Utiliser Netdata Cloud en option

Netdata Cloud permet d’agréger plusieurs agents dans une interface centralisée. Cette option facilite la supervision d’un parc de VPS, la consultation des alertes et la navigation entre plusieurs noeuds.

Elle implique cependant l’utilisation d’un service tiers. Il faut donc examiner les données transmises, les conditions de traitement et leur compatibilité avec la politique interne ou les obligations RGPD de l’organisation.

L’inscription à Netdata Cloud n’est pas obligatoire. L’agent local, son tableau de bord et ses alertes restent utilisables de manière autonome. Pour une infrastructure qui doit limiter les échanges avec des services externes, le mode local derrière SSH, VPN ou reverse proxy constitue une solution complète.

Limiter la consommation et la rétention

Netdata conserve des métriques sur le VPS. Sur une petite machine, une rétention longue ou un grand nombre de collecteurs peut augmenter l’utilisation de la RAM et du disque.

La configuration du moteur de stockage et de la rétention se règle dans netdata.conf. Avant toute modification, mesurez l’espace réellement consommé :

sudo du -sh /var/cache/netdata /var/lib/netdata

Réduisez la rétention si l’historique dépasse vos besoins. Désactivez également les collecteurs inutiles, par exemple ceux liés à des services absents du VPS. Conservez toutefois assez d’historique pour analyser les incidents survenus pendant la nuit ou le week-end.

Après un ajustement, redémarrez le service et surveillez sa consommation :

sudo systemctl restart netdata
sudo systemctl status netdata

Mettre à jour ou désinstaller Netdata

Une installation réalisée par Kickstart configure généralement le mécanisme de mise à jour de Netdata. Pour relancer manuellement l’installation ou mettre l’agent à niveau, exécutez de nouveau le script officiel :

curl -Ss https://get.netdata.cloud/kickstart.sh -o /tmp/netdata-kickstart.sh
sudo sh /tmp/netdata-kickstart.sh

Avec un paquet de distribution, utilisez le gestionnaire habituel :

sudo apt update
sudo apt upgrade netdata

Pour désinstaller une version installée par APT :

sudo apt purge netdata
sudo apt autoremove

Une installation native réalisée par Kickstart fournit généralement un script de désinstallation :

sudo /usr/libexec/netdata/netdata-uninstaller.sh --yes

Son emplacement peut varier selon la distribution et la méthode d’installation. Avant une désinstallation définitive, sauvegardez les configurations personnalisées de /etc/netdata, puis vérifiez que le service et le port 19999 ne sont plus actifs.