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 techniquementPermalink
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.
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.
Pourquoi Netdata ?Permalink
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 !
Aspects négatifPermalink
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.
ConclusionPermalink
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 