Netdata pour voir ce qu’il se passe sur une infra, sans se prendre la tête

Netdata en bref

J’ai découvert Netdata grâce à leur vignette sur le landscape de la CNCF. Par curiosité, j’ai regardé un peu plus en détails ce qui est présenté comme Real-time performance monitoring, done right!.

Le monitoring

Je me suis pas mal intéréssé au monitoring, comment définir une bonne solution, quels sont les critères importants à considérer pour faire du monitoring efficace, quelles sont les solutions existantes, les pièges à éviter, etc.

J’ai eu l’occasion de lire Practical Monitoring de Mike Julian, qui est un ouvrage qui donne beaucoup de bons conseils et axes de considérations lors de la recherche d’une solution de monitoring efficace et moderne.

Parmi les idées intéressantes à retenir de ce livre, il y avait notamment le besoin d’avoir une solution qui soit peu couteuse en ressources, modifiable assez facilement, mais surtout qui remplisse plusieurs tâches :

• La collecte de données
• Le stockage de ces données
• La visualisation via des graphiques, des camemberts, etc
• L’alerting
• Le reporting

Netdata se présente comme une solution capable de répondre très efficacement aux 4 premières tâches évoquées ci-dessus, laissant le reporting de côté.

Regardons plus en détails ce qu’est Netdata

Netdata techniquement

Selon leur README sur github (qui est d’ailleurs l’un des plus beau README que j’ai pu voir sur github), Netdata est codé en C pour des performances optimales, avec possibilité d’avoir des plugins en Go, en Python ou en JS.

Netdata est prévu pour fonctionner de base avec une granularité de collecte à la seconde, ce qui est assez prometteur et innovant quand on compare aux autres solutions de monitoring, qui peine à atteindre les 10s.

En effet, une granularité de collecte plus grande introduit un coût supplémentaire pour l’infrastructure, et une quantité importante de données supplémentaires à traiter et stocker.

Architecture des composants de Netdata (sources : image / github)

Netdata se présente comme une brique unique s’occupant de gérer tout ce qui est nécéssaire pour son fonctionnement. Il est possible cependant d’utiliser certaines API de Netdata pour interfacer un composant tiers, ou bien utiliser les possibilités d’export des données offerts par Netdata.

Netdata en détails (sources : image / github)

La quantité de plugins, de données collectées, etc est vraiment impressionante !

Pourquoi Netdata ?

Regardons d’un point de vue technique un peu plus en détails certains aspects de Netdata.

Extrait du README :

• 1s granularity - The highest possible resolution for all metrics.
• Unlimited metrics - Netdata collects all the available metrics—the more, the better.
• 1% CPU utilization of a single core - It’s unbelievably optimized.
• A few MB of RAM - The low-memory round-robin option uses 25MB RAM, and you can resize it.
• Minimal disk I/O - While running, Netdata only writes historical metrics and reads error and access logs.
• Zero configuration - Netdata auto-detects everything, and can collect up to 10,000 metrics per server out of the box.
• Zero maintenance - You just run it. Netdata does the rest.
• Zero dependencies - Netdata runs a custom web server for its static web files and its web API (though its plugins may require additional libraries, depending on the applications monitored).
• Scales to infinity - You can install it on all your servers, containers, VMs, and IoT devices. Metrics are not centralized by default, so there is no limit.
• Several operating modes - Autonomous host monitoring (the default), headless data collector, forwarding proxy, store and forward proxy, central multi-host monitoring, in all possible configurations. Each node may have different metrics retention policies and run with or without health monitoring.

Beaucoup de belles promesses, et en réalité Netdata est capable d’en tenir la plupart !

1s granularity

Par défaut c’est le mode de fonctionnement et de collecte de Netdata, et sur tous les périphériques sur lesquels j’ai pu le tester, ça fonctionne parfaitement (laptops et serveurs, pas d’IoT ou similaire)

Unlimited metrics

Bon j’ai du mal à saisir en quoi c’est un argument pertinent, à quoi s’oppose-t-il ?

1% CPU utilization of a single core

Ben regardons avec Netdata quelle quantité de CPU il utilise réellement sur mon laptop :

Utilisation moyenne du CPU par Netdata, mesurée grâce à Netdata

En pratique on tourne plus autour du 1.5%, mais je chipote !

A few MB of RAM

Le Netdata sur mon laptop qui tourne depuis plusieurs dizaines d’heures consomme 450MB de RAM. Pas incroyable, mais pas non plus mauvais, sachant qu’il est possible d’avoir un controle plus poussé de l’utilisation de la RAM via la configuration, pour réduire la quantité de RAM.

Minimal disk I/O

En effet, Netdata ne fait quasiment pas d’I/O car de base les données sont stockées totalement en RAM. Et même en modifiant cette configuration, les opérations d’I/O sont assez légères et loin d’être aussi exigeante qu’un elasticsearch utilisé pour faire du monitoring par exemple.

Zero configuration

Alors oui, mais non. De base Netdata fonctionne effectivement bien sans configuration, et est capable de détecter pas mal de choses, mais il va falloir rentrer dans les fichiers de configurations pour :

• Certaines données qui ne peuvent s’auto-détecter (genre l’expiration des certificats x509)
• Les alarmes
• La base de données persistante
• Etc

C’est un peu une demie vérité. En revanche, il est vrai que l’on peut lancer un netdata sans configuration pour le tester ou dans une utilisation basique, et ça fonctionne très bien

Zero maintenance

Je pense que ce qu’ils signifient par le zéro maintenance, c’est l’absence de maintenance de l’application pour purger les données trop vieilles, ou la mise à jour de la configuration. Et dans ce cas, il faut avouer que Netdata se défend plutôt bien !

Zero dependencies

Ce que j’expliquais en intro, Netdata est totalement autonome, et c’est plaisant !

Démo rapide

Il est possible d’avoir un aperçu de Netdata en fonctionnement via leur site, ce qui est assez intéressant.

Par ailleurs, il est également très facile de lancer sa démo chez soi grâce à docker, puisqu’en un simple docker run, notre PC se fait monitorer :

docker run -d --name=netdata \
  -p 127.0.0.1:19999:19999 \
  -v /etc/passwd:/host/etc/passwd:ro \
  -v /etc/group:/host/etc/group:ro \
  -v /proc:/host/proc:ro \
  -v /sys:/host/sys:ro \
  -v /var/run/docker.sock:/var/run/docker.sock:ro \
  --cap-add SYS_PTRACE \
  --security-opt apparmor=unconfined \
  netdata/netdata

Une fois le conteneur lancé, il ne reste plus qu’à visiter http://127.0.0.1:19999 sur son navigateur pour avoir accès à son Netdata.

C’est assez pratique par ailleurs pour avoir une alerte sur son téléphone quand son laptop n’a plus de batterie, pour aller le brancher. Ca m’a servi plusieurs fois !

Edit du 2020-01-04 23:00:00 :
Voici un exemple d'alertes reçues sur Slack :

Alerte de Netdata sur Slack

Et à quoi ça ressemble sur le dashboard, avec sous la flèche bleue la pastille indiquant les alertes levées, et une alerte ouverte en pop-up :

Alerte de Netdata sur le dashboard

Aspects négatif

Voici quelques points noirs que j’ai pu relever avec Netdata après quelques mois d’utilisation :

• La pertinence des alertes n’est pas forcément incroyable. Sur notre infrastructure, nous avons reçu des centaines d’alertes chaque jour pour des broutilles, générant du bruit. Bien que les alertes (et leurs seuils) soient configurable assez facilement, il reste assez pénible d’être obligé de relever des seuils d’alertes peu pertinentes.

• La décentralisation de base est à double tranchant : s’il est pratique d’avoir des noeuds indépendant, un noeud indépendant qui tombe en rade n’enverra donc pas d’alerte par exemple. De plus, il faut configurer l’accès à chacun des dashboard de chaque noeud (genre une entre dans le reverse proxy par noeud), ce qui est aussi pénible par rapport à une interface unique.

• La non-pertinence de Netdata dans Kubernetes. Au moment où je l’ai testé (Octobre 2019), les metrics étaient trop brutes. Il n’y avait pas de metrics de haut-niveau pour montrer l’état du cluster k8s, mais que des metrics bas niveau de chacun des noeuds.

Conclusion

Netdata est actuellement une très bonne solution de monitoring. Il faut cependant prendre quelques heures pour le configurer correctement pour avoir des données pertinentes, et des alertes qui restent suffisament peu fréquentes pour être pertinentes.

L’attention particulière portée aux performances est vraiment agréable. On est loin d’avoir un truc dev à l’arrache en quatrième vitesse sans faire attention aux performances ou à l’architecture du logiciel. Des détails comme celui-ci sont vraiment très agréables à découvrir dans un projet du genre.

La documentation est assez complète et précise, rendant le tool utilisable. Les sources aussi sont claires et bien organisées, avec des bouts de README utiles qui se baladent à droite à gauche (exemple, exemple, ..)

L’interface est vraiment cool. Un poil minimaliste peut-être, mais très ergonomique et plutôt belle.

C’est un projet que je vais suivre de près, voire dans lequel je pourrai m’investir, tant je le trouve prometteur. Prenez 2 min pour y jeter un coup d’oeil ;)