Hello World : voici banshee
banshee est une supervision libre, conçue pour dire vrai le jour où tout va mal. Ce qu’elle est, ce qui la distingue, et où en est le projet : un serveur central bien avancé, et le poller pour prochaine étape.
Par Benjamin5 min de lecture
Bienvenue sur le blog de banshee. Nous y publierons l’avancement du projet, le contenu de chaque version et des articles techniques.
Pourquoi banshee
Dans beaucoup d’équipes, la supervision coûte plus de temps qu’elle n’en fait gagner. Les contrôles s’accumulent au fil des années, écrits dans des langages différents, chacun avec ses options et son format de sortie, et une mise à jour peut changer ce qu’un contrôle rapporte sans que personne le remarque. Leur maintenance repose souvent sur une seule personne. Surtout, l’état affiché n’est pas toujours vérifié : un voyant vert peut n’être que le dernier état connu.
banshee part d’une exigence simple : un outil de supervision doit dire vrai le jour où tout va mal. Chaque choix du projet se mesure à cette règle.
Ce qu’est banshee
banshee se compose de deux programmes. Le master est le serveur central. Il tient l’inventaire de ce qui est surveillé, les réglages, les comptes et les droits, ainsi que l’interface web. Le poller sera le programme de collecte. Installé au plus près des équipements, dans un datacenter, chez un client ou sur le serveur surveillé lui-même, il les interrogera en SNMP, en SSH ou en HTTPS et jugera leurs réponses. Chacun de ses contrôles s’appelle une sonde.
Le poller ouvre toujours la connexion vers le master, jamais l’inverse. Superviser un site distant ne demandera donc ni port entrant ni VPN, puisque le poller sort vers le master comme un navigateur sort vers un site web.
Ce qui la distingue
- Un état vérifié. Chaque résultat portera son âge. Un résultat qui n’est pas renouvelé à temps sera marqué périmé, et un poller qui cesse de donner signe de vie se verra aussitôt.
- Des alertes qui se lisent. Un problème n’alertera qu’une fois confirmé, et chaque alerte dira pourquoi en une phrase, par exemple « eth0 à 93 %, au-delà de 90 % depuis 5 min ».
- Une configuration à l’écran. Les surveillances qu’un collecteur propose se cochent, leurs seuils sont facultatifs, et un réglage posé sur un dossier vaut pour tout ce qu’il contient.
- Une collecte qui lit sans modifier. Ce qu’une sonde envoie à un équipement est écrit dans son code, relu avant d’être déployé, et un master compromis ne pourra pas prendre la main sur les pollers.
Pour les équipes techniques
Ce qu’une sonde sait faire est décrit par son collecteur, écrit en Keen, le langage de banshee. Keen est un langage simplifié, inclus dans banshee et sans dépendance au système, que la plupart des administrateurs lisent sans apprentissage, et tous les collecteurs suivent le même plan, ce qui facilite la relecture d’un code écrit par d’autres. Voici l’essentiel d’un collecteur d’onduleur interrogé en SNMP :
need('protocol:snmp');
output('charge', 'number', array('label' => 'Battery charge', 'unit' => '%'));
output('runtime', 'number', array('label' => 'Time left on battery', 'unit' => 'min'));
watch.below('charge-low', 'Battery not charged', 'charge', array('warning' => 80, 'critical' => 50));
watch.below('runtime-short', 'Little time left on battery', 'runtime', array('warning' => 15, 'critical' => 5));
value('charge', snmp.get('1.3.6.1.2.1.33.1.2.4.0'));
value('runtime', snmp.get('1.3.6.1.2.1.33.1.2.3.0')); Les deux lignes watch.below sont des surveillances, des cas d’usage nommés en clair avec des seuils proposés par l’auteur. Sur la page d’une sonde, l’administrateur cochera celles qui l’intéressent et ajustera les seuils au besoin. Un seuil laissé vide ne déclenche rien, et il n’y a ni option de greffon à retrouver dans une aide, ni expression régulière à écrire.
Après chaque mesure, le poller jugera, et la surveillance la plus grave l’emportera. Le moteur de jugement, déjà écrit et testé, couvre les cas courants : seuil haut ou bas, hausse, absence d’activité, écart à l’habitude, valeur attendue, ou instance qui s’écarte des autres, comme un disque plus lent que ses voisins.
Le master vérifie chaque collecteur à l’enregistrement et signale chaque faute à sa ligne. Les collecteurs se partagent par des dépôts, des sites web qui publient des collections. Le Magasin de banshee cherche dans les dépôts que l’administrateur a ajoutés et récupère un collecteur ou une collection entière. Aucune mise à jour n’est automatique : chaque version est conservée, se compare à une autre et se rétablit en un clic.
Pour les décideurs
banshee est libre, sous licence AGPL-3.0. Il n’en existe qu’une édition, la même pour tous, sans licence par hôte ni par sonde. Son coût de licence est nul, quelle que soit la taille du parc.
Elle s’installe sur vos serveurs, et vos données y restent. Chaque collecteur est un code lisible que vous conservez, si bien que rien ne vous lie au projet le jour où vous décidez de changer d’outil.
La configuration se fait à l’écran plutôt que dans des fichiers. Toute une équipe peut ainsi exploiter la supervision, sans dépendre d’un seul expert.
L’architecture est dimensionnée pour 80 000 hôtes et 600 000 sondes. Cette cible, volontairement très au-delà des besoins courants, sert à vérifier qu’aucun choix technique ne bloquera la croissance d’un parc. L’inventaire a déjà été éprouvé avec 680 001 dossiers, hôtes et sondes.
Où en est le projet
Le projet avance dans un ordre défini : le serveur central d’abord, puis le poller, puis l’ensemble. Le serveur central est bien avancé. Il gère aujourd’hui :
- l’inventaire, un arbre de dossiers, d’hôtes et de sondes, où l’écran indique d’où vient chaque réglage ;
- les comptes avec double facteur, les groupes, et les droits posés sur l’arbre ;
- les secrets, chiffrés dans un coffre doté d’une clé de secours ;
- les collecteurs, avec leur éditeur, leurs versions et le Magasin ;
- le profil TLS de chaque connexion chiffrée, choisi par un mode nommé d’après le parc concerné, de « Récent » à « Windows 2008 et plus, Linux après 2010 ».
banshee ne supervise pas encore de parc en production. La collecte arrivera avec le poller, qui est la prochaine grande étape ; avec lui viendront les résultats et les états à l’écran, puis les alertes par courrier électronique. Nous ne donnons pas de date. Le serveur central a été conçu pour l’accueillir : l’inventaire sait déjà quel poller collecte quel hôte, et chaque collecteur déclare ce dont il a besoin.
S’impliquer
- Pour une question, un retour d’expérience ou un parc à superviser, contactez l’équipe.
- Les sponsors financent le développement et figurent sur ce site : devenir sponsor.
- Nous constituons un réseau de partenaires qui déploieront banshee et accompagneront les entreprises qui l’adoptent : devenir partenaire.
- Le flux RSS annonce chaque nouvel article.
À lire aussi
-
6 min de lecture
Community : la supervision se partage
Pourquoi j’ai voulu un dépôt public de collecteurs dès le départ, ce qu’il change au quotidien, et pourquoi je pense qu’une sonde devrait se partager comme une image Docker plutôt que se vendre en pack.
Lire l’article