Introduction
Depuis bien longtemps maintenant, Cacti était (et reste encore) une référence pour la métrologie des infrastructures informatiques. Agrémenté de quelques plug-ins, il pouvait même devenir un outil de monitoring suffisamment puissant pour répondre à bien des besoins sans avoir nécessairement un intérêt à bifurquer vers une solution axée “entreprise” avec les frais qui en découlent. Cependant, la lenteur de son développement et le manque d’amélioration majeure depuis de nombreuses années ont mené de nombreux utilisateurs à se lancer dans la quête d’un remplaçant.
Un peu d’histoire
Il y a maintenant quelques années que Cacti peine à trouver son rythme de croisière. Certes, il est fonctionnel comme tel, mais imposait tout de même une certaine dose de nostalgie à chacun de ses lancements avec son interface old school qui piquait un peu les yeux (chose largement améliorée avec la version 1.0 sortie en début d’année 2017). Les graphs seront tout à fait fonctionnels et ne sont pas particulièrement déplaisants à l’oeil, mais l’ensemble de l’outil, sa manière de fonctionner et sa méthode de développement (relativement lente, pour rester poli) font de lui un outil mal adapté aux besoins extrêmement souples nécessaires dans notre monde de gestionnaire d’infrastructure 2.0.
Cacti traverse actuellement une phase de restructuration profonde de son code afin de l’amener à quelque chose de plus adapté à notre décennie. Tout d’abord, les quelques membres du coeur de développement, appelé The Cacti Group, ont décidé au début de l’année 2016 de migrer le code sur GitHub (enfin, mais un peu tard). Lors de l’opération, certains développeurs au coeur de l’outil ont reconnu que Cacti souffrait désormais beaucoup de son âge avancé sans grandes améliorations et nécessitait un vrai coup de jeune sur beaucoup d’aspects. The Cacti Group a décidé de conserver l’outil le plus proche possible de ce qui était connu, mais d’améliorer toute la machinerie qu’il y avait derrière en intégrant par exemple nativement un très grand nombre de plug-ins populaires (mais sans THold, ni MacTrack) et en tentant de réécrire complètement le code qui génère l’interface graphique. C’est un peu réducteur de ma part de ne tenir compte que de ces éléments, mais dans le fond c’est l’impression qui ressort depuis la première release. La version 1.0.2 étant désormais disponible, il est possible de découvrir de ses propres yeux l’évolution de l’outil. Il est intéressant de noter que la quasi-totalité des changements appliqués au code est générée par un seul utilisateur de GitHub et que l’activité depuis 2016 est relativement faiblarde avec un peu plus de 30 committers (en comparaison, LibreNMS en compte plusieurs centaines).
GitHub est donc un très bon moyen de se rendre compte de l’intérêt généré par un projet et de lui prendre le pouls. Le nombre de membres suivant l’activité du projet, le nombre de problèmes ouverts ou encore le nombre de commits réalisé permettent de se faire une très bonne idée de l’état de santé de celui-ci. Malheureusement, Cacti ne semble pas intéressé beaucoup de monde sur GitHub malgré le fait qu’il est relativement populaire auprès des équipes réseau. Très probablement, nous avons trouvé une partie de la source du problème. Les utilisateurs de Cacti (comme moi), venant souvent du monde du réseau (pas comme moi), sont généralement très peu enclins à sortir des sentiers battus et aiment utiliser une solution clé en main, facile à déployer sans avoir à se soucier du code se trouvant derrière. Bien des gens dans le monde du réseau n’aiment pas particulièrement les tâches système (oui, je vais en fâcher plus d’un, mais c’est très souvent la réalité). Donc la solution la plus simple pour déployer Cacti reste l’utilisation d’un repository comme EPEL par exemple, mais qui très souvent reste à la traine sur les versions de Cacti disponibles, qui lui-même, souffre déjà d’un développement très lent… Bref, vous avez probablement compris.
Les débuts de LibreNMS
Comment faire pour se séparer d’un outil aussi utile, aussi commun, mais qui dérange surtout par son côté très légèrement abandonware ? Cette question n’est clairement pas évidente et pour réussir à tirer des conclusions, il m’aura fallu tester un nombre considérable d’outils en tout genre (PRTG, Nagios, NAV, Observium…) parfois complètement à l’opposé de nos besoins et parfois très proches. Lors de la phase de recherche qui a duré environ une année tout de même (oui, c’était une activité annexe et pas vraiment un besoin vital), j’ai eu la chance d’atterrir sur le projet LibreNMS qui s’est annoncé comme le remplaçant idéal pour nos besoins.
LibreNMS
LibreNMS est un logiciel open source sous licence GPLv3 disponible sur GitHub qui trouve ses origines dans Observium, un autre logiciel du type NMS (Network Management Software). LibreNMS est donc un fork lointain d’Observium et conserve encore quelques traits avec le logiciel original. L’origine de la scission du logiciel en deux projets distincts provient principalement du fait que certains membres de la communauté d’Observium n’étaient pas satisfaits de la tournure que prenait le projet en expliquant ne pas être en accord avec les priorités et les valeurs de l’équipe de développement malgré le fait qu’ils appréciaient grandement l’outil. Derrière ce résumé édulcoré présenté sur le site, l’équipe de LibreNMS ne dit pas que certains développeurs d’Observium souffrent d’une mauvaise réputation et ne semblent pas très enclins à tolérer les nouveaux venus ni les personnes ayant un avis différent, ce qui peut poser problème dans le cadre d’un projet « public ».
À contrecœur, LibreNMS était donc né en 2013 pour notre plus grand plaisir grâce à Paul Gear, désormais chez Canonical (Ubuntu). LibreNMS se distingue désormais complètement d’Observium en possédant une communauté extrêmement bien rodée qui est menée par un petit groupe de développeurs passionnés ne cherchant qu’à améliorer l’outil en continu. Neil Lathwood, principal contributeur du projet désormais (mais très loin d’être seul), possède pas moins de 1’800 commits pour plusieurs millions de lignes de codes éditées. Tony Murray, arrivé dans le projet plus récemment est déjà à près de 700 commits pour 870’000 lignes de code éditées. C’est vous dire si le projet possède des membres passionnés !
Les utilisateurs généreux peuvent offrir de façon anonyme les statistiques de leurs équipements. Grâce à ce site, on peut apprendre que de très nombreux équipements sont actuellement contrôlés par LibreNMS (à l’heure ou j’écris ces lignes, plus de 110’000), et ce, uniquement pour les utilisateurs faisant la démarche d’autoriser les statistiques, donc probablement une infime minorité. Dans ces statistiques on peut voir que la large majorité est des équipements Cisco dans lesquels on trouve tout de même pas loin de 4’000 ASA, près de 400 Cisco Wireless LAN Controller, et 17’000 switches/routeurs sous IOS. Il reste encore un peu de place pour environ 15’000 serveurs Linux et 8’000 serveurs Windows…
LibreNMS, ça fait quoi ?
LibreNMS permet avant tout de remplacer une bonne partie des fonctions de Cacti. C’est-à-dire qu’il permet de réaliser la métrologie d’infrastructures informatiques en tous genres, tout particulièrement des équipements réseau et serveurs Linux/Windows, mais pas uniquement. Avec le temps il permet de remonter des métriques de presque toutes les sources SNMP. Lorsqu’un équipement est inconnu par LibreNMS, il sera tout de même possible de l’ajouter en tant qu’équipement générique et il pourra alors extraire les informations standardisées comme les interfaces réseau et son uptime.
Aperçu de base (CPU, RAM, Disk)
Cependant, je vous rassure tout de suite, il devient de plus en plus rare de trouver des équipements n’étant pas supportés. L’équipe de développement et les centaines de contributeurs ont mis le paquet pour ajouter et continué d’ajouter, à peu près tout ce que demande les utilisateurs. Il suffit de donner un coup d’oeil dans l’historique des pull requests du projet pour se rendre compte du chemin parcouru en très peu de temps. Pour résumer, LibreNMS supporte et supportera vos équipements si l’information existe dans son implémentation du protocole SNMP, c’est quasi certain.
LibreNMS possède un dashboard entièrement personnalisable permettant de mettre en avant les graphiques les plus intéressants ainsi que de nombreuses autres informations comme les alertes en cours, ou une vue de vos équipements sur une carte permettant à un NOC d’avoir toujours un oeil sur l’état de ses équipements. Le dashboard permet aussi de mettre en avant les interfaces réseau ou les équipements les plus sollicités ou encore d’afficher les derniers messages de son service log intégré.
Donc dans les informations de base, il est possible de remonter tout ce qui concerne les interfaces réseau, en incluant les port-channels, vPC ainsi que la liste des vlans associés par exemple. L’outil sait aussi afficher nativement l’était du trafic « live » sur une interface réseau choisie. Dans son fonctionnement de base, LibreNMS se rapproche beaucoup de Cacti en réalisant un polling toutes les 5 minutes par défaut (configurable à 1 minute). La fonction « live » permet donc de se renseigner sur l’état d’une interface sans avoir besoin d’attendre les 5 minutes standards, qui parfois ne permettent pas de voir les piques de trafic très courts.
LibreNMS est aussi capable de remonter tous les capteurs d’état connus comme les ventilateurs, la température ou le statut du VSS sur des équipements Cisco par exemple.
Aperçu du trafic global d’un switch
Support avancé de certains équipements
Dans le cas où les constructeurs prennent la peine d’envoyer un maximum d’information par SNMP, LibreNMS permettra alors d’afficher des informations avancées sur l’état de celles-ci. Par exemple, sur un contrôleur Wi-Fi Cisco du type Wireless LAN Controller, il est possible d’afficher le nombre d’utilisateurs connectés sur les différents SSID, mais aussi de visualiser l’état de chacune des antennes avec son nombre de clients ainsi que l’état des interférences.
Autre exemple, sur les équipements possédants des protocoles de routage, LibreNMS affichera l’état de la connexion. Le menu routing résumera alors l’ensemble des connexions eBGP/iBGP ou OSPF. Il conservera l’état de la connexion ainsi que sa stabilité et son trafic.
Couplé à un UPS gérant la RFC1628 (la majorité), tous les graphiques standards de la norme apparaitront quasi-automatiquement afin de visualiser en détail l’ensemble des points de mesure de l’équipement (autonomie, input, output, puissance, fréquences…).
Sur des appliances Infoblox DDI (IP, DNS, DHCP), on pourra afficher les statistiques sur la majorité de ses fonctionnalités. Comme le nombre de requêtes DNS/DHCP par exemple. Sur des équipements avancés comme les firewalls ou les contrôleurs Wi-Fi il est possible, en général, remonter le nombre d’utilisateurs connectés sur leurs services ou tout simplement le nombre de sessions ouvertes par type de protocole.
Module d’alertes et de notifications
LibreNMS possède aussi un puissant moteur d’alerting composé de plusieurs sous-modules qui pourront, au premier abord, semblait un peu compliqué à prendre en main, mais qui sera au final un outil redoutable. L’outil est tellement personnalisable, que l’on peut récupérer le contenu de l’ensemble des tables existantes dans la base de données SQL…
Création d’une règle d’alerte
Il est ainsi possible de créer des règles qui seront envoyées au module de notifications qui permettra de se faire alerter par une multitude de méthodes différentes (Email, API, Slack, SMS…). Grâce à cette méthode très souple, il est possible de programmer des règles pour à peu près tout et n’importe quoi.
On peut par exemple facilement créer une règle pour déclencher un avertissement lorsqu’un volume est rempli à plus de 80% et utiliser une alerte critique dès que le seuil de 90% est atteint. Un « volume » peut être un bootflash sur un équipement Cisco, tout comme le disque d’un serveur Windows/Linux ou encore un datastore sur un serveur ESXi.
Recherche de MAC addresses et d’adresses IP
Parmi les fonctions supplémentaires sortant du cadre strict de la métrologie, LibreNMS sait récupérer les tables ARP et FDB des équipements compatibles afin de constituer une base de données des MAC addresses et des IP quand elles sont disponibles. Cela ne fonctionne pas avec tout et semble limité aux équipements possédants des interfaces en L2 dans les réseaux adéquats, mais cela peut convenir déjà à un bon nombre de personnes.
Recherche de MAC addresses et d’adresses IP
Lorsque l’on parle de recherche d’addresses MAC, il est évident que l’on peut retourner le problème dans tous les sens. LibreNMS se base sur l’historisation des tables ARP/FBD qui permet ensuite de rechercher IP ou MAC ou simplement afficher la table.
Monitoring des services (via les plug-ins Nagios)
LibreNMS possède un module permettant de monitorer les services et non plus les équipements ou serveurs directement par SNMP. Cela signifie qu’il est possible d’utiliser un test sur du contenu HTTP avec un parseur afin de vérifier qu’un service web est bien en ligne et actif par exemple. Le cas échéant, il est possible d’envoyer une alerte au système de notification.
Cette fonctionnalité qui sort un peu du cadre strict du monitoring d’équipements a été ajoutée, car un très grand nombre d’utilisateurs monitor des serveurs Windows et Linux qui, forcément, hébergent de nombreux services. Pour mener à bien cette partie du projet, LibreNMS utilise comme base les plug-ins Nagios. Ceux-ci sont disponibles librement au téléchargement sur Internet et intégré à de nombreux repositories, comme EPEL.
Ajout d’un nouveau service avec paramètres Nagios
Depuis LibreNMS il sera donc possible de contrôler de nombreux services HTTP, LDAP, SMTP, IMAP, SMB, DHCP, DNS… et de les lier à vos équipements ajoutés par SNMP afin d’obtenir un « set » de monitoring relativement complet.
En utilisant les options avancées de certains de ces modules, il est possible par exemple de vérifier les dates de validité de certificats SSL, le temps de réponse moyen et de valider qu’il est possible de s’authentifier.
Ce morceau n’est clairement pas le coeur de l’outil, mais permet de s’épargner un outil supplémentaire dans beaucoup de cas en offrant la possibilité de tout vérifier depuis un unique logiciel de monitoring.
Exemple de service LDAP lié à une machine virtuelle monitorée en SNMP
L’un des points forts de ce module étant de tester depuis LibreNMS les services d’un serveur qui est déjà monitoré pour sa partie SNMP. Par exemple, si vous ajoutez tous vos contrôleurs de domaine Active Directory à LibreNMS en SNMP et que vous ajoutez ensuite un service LDAP/LDAPS à contrôler, il sera possible de le lier aux contrôleurs de domaine ajouté en SNMP. En effectuant ce lien entre les deux services, un nouvel onglet apparaitra dans le dashboard principal des contrôleurs de domaine et affichera la liste des services liés à celui-ci ainsi que leur état.
Intégration avancée et API
LibreNMS offre un très grand nombre de fonctionnalités relativement ciblées qui permettent à l’outil d’offrir le maximum de flexibilité. Il est par exemple possible de le coupler à des outils de sauvegarde de configuration comme Oxidized ou RANCiD. En couplant les deux outils, les configurations des équipements apparaitront directement sur LibreNMS avec l’historisation des versions. Il est aussi possible de populer automatiquement ces deux outils depuis ici afin d’éviter d’avoir à le faire deux fois.
Derrière ces fonctionnalités avancées se cache une puissante API permettant d’accéder à une très grande partie des informations de LibreNMS. Il est possible de sortir les graphs directement depuis celle-ci afin de les intégrer à d’autres outils ou encore d’obtenir des informations de trafic sur un port en particulier.
Autre élément intéressant, LibreNMS intègre un serveur syslog (relativement basic) permettant de concentrer toutes les informations de ses équipements sur une seule et même interface de gestion. Le module syslog s’intègre à l’ensemble de LibreNMS et permet de déclencher des alertes comme le ferait un message SNMP. Il saura donc répondre aux petites et moyennes installations qui ne nécessitent pas des fonctionnalités poussées ou des techniques d’archivage de logs avancées.
Plus le nombre d’équipements grandira et plus les notifications seront importantes, c’est pourquoi l’équipe a prévu un module de maintenance permettant de couper les notifications à des dates précises ou lors de périodes récurrentes afin d’éviter de recevoir des messages de faux positif qui pourrait noyer de vraies informations.
Comment débuter ?
Dans le souci de répondre au maximum des attentes des utilisateurs, l’équipe au coeur du développement a mis en ligne un très grand nombre de ressources permettant de bien débuter avec LibreNMS, mais aussi pour permettre de tirer le plein potentiel de l’outil. Porte d’entrée indispensable, le site hébergeant les documentations donnera toutes les indications nécessaires au déploiement de la solution de différentes manières. La communauté ainsi que l’équipe des développeurs principaux sont disponibles sur Discord (alternative à Slack/Hangouts) pour les questions ne pouvant pas attendre. Un forum d’aide en ligne est quant à lui disponible pour les questions moins urgentes ou nécessitant plus de débats. Vient ensuite l’éternelle partie « Issues » sur GitHub permettant de remonter les bugs.
Pour conclure
LibreNMS est donc un outil relativement avancé, tout de même perfectible sur de nombreux points, mais qui, au final, pourra répondre à de nombreux besoins. Loin d’avoir fait le tour de l’ensemble de ses fonctionnalités dans cette présentation, vous pouvez découvrir l’outil au travers du site de démonstration (demo/demo) qui est disponible. Il permet de se rendre compte de l’étendue des fonctionnalités avant de peut-être franchir le pas !
Florent Bruchez