Un serveur Netdata, c’est bien. Dix onglets de navigateur ouverts sur dix serveurs Netdata, c’est déjà moins glorieux. Bonne nouvelle : Netdata sait faire du streaming. Chaque machine (l’« enfant ») envoie ses métriques à un serveur central (le « parent »), et vous ne consultez plus qu’un seul tableau de bord. Voyons comment brancher tout ce petit monde, sans cloud obligatoire.

Cet article fait suite à l’installation de Netdata sur AlmaLinux 10 : ce serveur jouera le rôle de parent.

ATTENTION : Il y a une limitation de Netdata pour n’afficher que 5 noeuds !

Le principe en 30 secondes

• Le parent reçoit les métriques, les stocke et les affiche ;
• chaque enfant est un agent Netdata classique configuré pour envoyer ses données au parent ;
• les deux se reconnaissent grâce à une clé d’API partagée (un simple UUID) ;
• tout passe par le port 19999 du parent.

Prérequis

• Un parent Netdata fonctionnel (celui de l’article précédent) ;
• un ou plusieurs serveurs à superviser, avec accès sudo ;
• une connectivité réseau enfant → parent sur le port 19999.

1. Préparer le parent

Générez d’abord la clé d’API qui servira de mot de passe commun :

uuidgen

Notez le résultat, par exemple 11111111-2222-3333-4444-555555555555 (utilisez le vôtre, pas celui de l’exemple, sauf si vous aimez les surprises).

Éditez ensuite stream.conf :

sudo /etc/netdata/edit-config stream.conf

Ajoutez une section portant le nom de la clé :

[11111111-2222-3333-4444-555555555555]
    enabled = yes
    allow from = 192.168.1.*

allow from restreint les IP autorisées à utiliser cette clé : adaptez-le à votre réseau local, c’est une ceinture de sécurité gratuite.

Attention si vous avez suivi la partie « reverse proxy » de l’article précédent : avec bind to = 127.0.0.1, le parent n’écoute qu’en local et aucun enfant ne pourra le joindre. Dans netdata.conf, section [web], ajoutez l’IP du parent à la liste :

[web]
    bind to = 127.0.0.1 192.168.1.10

Ouvrez enfin le port, uniquement pour votre réseau local :

sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="192.168.1.0/24" port port="19999" protocol="tcp" accept'
sudo firewall-cmd --reload
sudo systemctl restart netdata

2. Installer l’agent sur chaque enfant

Même script que pour le parent, il détecte la distribution (AlmaLinux, Debian, Ubuntu…) tout seul :

wget -O /tmp/netdata-kickstart.sh https://get.netdata.cloud/kickstart.sh
sh /tmp/netdata-kickstart.sh --dont-wait

3. Connecter l’enfant au parent

Sur l’enfant :

sudo /etc/netdata/edit-config stream.conf

Dans la section [stream] en haut du fichier :

[stream]
    enabled = yes
    destination = 192.168.1.10:19999
    api key = 11111111-2222-3333-4444-555555555555

Remplacez l’IP par celle de votre parent (un nom d’hôte fonctionne aussi) et la clé par la vôtre, puis :

sudo systemctl restart netdata

Répétez l’opération sur chaque machine. Avec la même clé partout, c’est du copier-coller ; avec une clé par machine, c’est plus propre mais plus long. À vous de choisir votre niveau de rigueur.

4. Vérifier que ça circule

Ouvrez le dashboard du parent : vos nouveaux nœuds doivent apparaître dans la liste des machines, au bout de quelques secondes. En cas de silence radio, les logs parlent :

sudo journalctl -u netdata | grep -i stream

Les causes habituelles : pare-feu, allow from trop strict, clé d’API mal recopiée, ou parent qui n’écoute que sur 127.0.0.1 (oui, on a prévenu).

5. Chiffrer le flux (recommandé)

Par défaut, le flux circule en clair sur votre réseau. Sur un LAN de confiance, c’est tolérable ; dès que ça sort de la maison, non. Netdata gère TLS : il suffit d’ajouter :SSL à la destination sur l’enfant.

[stream]
    destination = 192.168.1.10:19999:SSL

Le parent doit alors avoir un certificat configuré pour son serveur web, et il faut redémarrer l’agent des deux côtés. Si le chiffrement échoue, remettez la configuration claire le temps de diagnostiquer, pas l’inverse.

Bonus : plusieurs parents pour la haute disponibilité

Un enfant peut connaître plusieurs parents, séparés par des espaces. Si le premier tombe, il bascule sur le suivant :

destination = 192.168.1.10:19999 192.168.1.11:19999

En résumé

1. Générer une clé d’API avec uuidgen ;
2. déclarer la clé sur le parent, ouvrir le port 19999 pour le LAN uniquement ;
3. installer l’agent sur chaque enfant ;
4. renseigner destination et api key dans leur stream.conf ;
5. vérifier dans le dashboard, puis chiffrer avec :SSL.

Résultat : un seul tableau de bord, tous vos serveurs, et plus aucune excuse pour ne pas savoir lequel est en train de surchauffer.