L’ensemble de la supervision du réseau de SCANI a été refondue cet été. Il faut savoir que ce qui existait avant avait été monté bribe par bribe, en fonction de l’arrivée des besoins, que ce n’était pas toujours exhaustif (par exemple, les 4 machines jouant le rôle de serveurs DNS pour l’ensemble des membres n’étaient pas surveillées) et, surtout, que c’était de plus en plus gourmand en ressources techniques.

Cette ancienne supervision fonctionnait sur la même machine que le système d’information technique et cartographique de la coopérative. Du coup, depuis début 2018, tout ça était fortement ralenti, puisqu’à chaque nouvelle antenne installée correspondait un nouveau test de supervision mis en place.

Un appel a bonnes idées et à « propose quelque chose » avait donc été lancé et c’est Benjamin qui s’y est collé. Bruno a ensuite mis sa patte pour la mise en production et les développements nécessaires dans le système d’information.

L’ancienne plateforme tournait sur la base d’un Nagios agrémenté du plugin pnp4nagios pour la partie graphiques historiques. Les prérequis pour la nouvelle étaient les suivants :

• Scalabilité (la possibilité de monter en puissance sans avoir à tout refaire)
• Délégation du travail de supervision à plusieurs machines distantes (dans Zabbix, ce sont des proxy)
• Possibilité, au choix, de générer la configuration de la supervision automatiquement en conservant une partie manuelle, ou bien de discuter avec une API pour modifier la configuration globale existante (dans Zabbix, il y a une API, et on s’en est plutôt bien sorti)
• Interface moderne et moteur de génération de graphique personnalisable (là dessus, Zabbix a encore des progrès à faire)

Le choix, pour la nouvelle plateforme, s’est porté sur Zabbix. Il a une méthode de fonctionnement assez contre-intuitive quand on vient du monde de la supervision des années 1990, mais il faut reconnaître qu’il cochait pas mal de cases de notre liste. Voilà en gros comment ça fonctionne :

• Une première couche est constituée d’une liste de sources de données (items dans Zabbix), chacune raccrochée à un seul équipement. Cette source peut être un agent Zabbix propriétaire (donc on ne s’en sert pas sur les antennes), une requête SNMP (ce qu’on a choisi), et tout un tas d’autres agents, jusqu’au lancement d’un bête script qu’on peut écrire soi même.
• On doit, ensuite, réaliser des triggers. Ce sont des évènements qui se déclenche lorsqu’une ou plusieurs conditions sont remplies. Par exemple « le taux de paquets perdus à destination de cette machine est supérieur à 20% depuis plus de 20 minutes » ou bien « la mémoire disponible sur telle machine est inférieur à 5% », mais aussi des choses beaucoup plus rock’n’roll, comme « au rythme ou ça va ces 2 dernières heures, tel disque dur sera plein dans moins de 48h ». Bref, infiniment plus de possibilités que le simple « je collecte un chiffre et si il est plus grand ou plus petit que tel autre chiffre, ça envoi une alerte ».
• Et enfin, une dernière couche permet d’envoyer les alertes à X, Y ou Z personnes avec des médias différents (mail, jabber, script perso, …)

Le tout est agrémenté de notions de template, ce qui permet de créer par exemple la supervision idéale de tel type d’équipement et ensuite de l’appliquer en série à des centaines d’équipements. Lorsqu’on modifie le template, tout le monde suit.

Il y a également un principe de discovery bien utile pour les choses qui peuvent varier d’un équipement à un autre. On s’en sert surtout pour la supervision des partitions de disques dur (qui ne sont pas toutes les mêmes sur toutes les machines) ou des interfaces réseau (dont le nombre varie d’une antenne à une autre). Une fois bien configuré, tout ça est transparent dans l’usage quotidien de l’outil, ça change des fichiers de configurations qui font 12000 kilomètres de long.

Du coup, mise en pratique !

Premier objectif : parvenir à extraire des antennes du réseau au moins autant d’information que ce qu’on avait avant. Une infâme mixture de requêtes SNMP et de lancement de scripts SSH et HTTPS était nécessaire jusqu’à présent, mais on a trouvé toutes les OID nécessaires pour extraire ce dont on avait besoin en SNMP. Un socle commun de templates a été monté à partir de ce qu’on a trouvé en ligne, et trois dérivés, pour les antennes Ubiquiti génération M, AC et AirFiber ont ensuite été montés par dessus.

Pour la faire courte, on récupère donc :

• Les infos ICMP (RTT et Loss)
• La disponibilité SNMP et SSH
• Les infos radios (capacité RX, capacité TX, CCQ quand applicable, puissance d’émission, SSID, largeur de canal, force de signal reçue, noisefloor, RSSI, fréquence, distance du lien radio)
• Les infos système (hostname, location snmp, mémoire, disque, firmware, baseboard, uptime)
• Les infos réseau (débit, paquets, loss, discard, vitesse et nom de chaque interface)
• Une information « virtuelle » qui suit la formule suivante : (rx + tx) * RSSI / signal * -1 / (loss + 1) et qui permet d’obtenir une vue assez fidèle de la qualité de chaque liaison radio

De tout ça, on sort un certain nombre de triggers :

• Changement de paramètre (fréquence, largeur de canal, firmware, reboot, baseboard)
• Injoignabilité (plus de 10 minutes sans réponse au ping)
• Lien de faible qualité (signal < -80)
• Capacité RX ou TX qui rebondi à 6.5 (généralement signe que la fréquence utilisée est perturbée)
• Perte de paquets trop importante

Toutes les notifications issues de ces triggers sont ensuite envoyés à un script local à la machine de supervision qui va questionner le système d’information pour savoir ce qu’il convient de faire avec l’alerte. Le SI dispose de plusieurs groupes de notification Telegram, secteur géographique par secteur géographique, et indique donc à la supervision à quel groupe Telegram il faut envoyer le message pour que les personnes concernées le reçoivent. Il peut, bien entendu, envoyer une info à plusieurs groupes en même temps.

Dans tous les cas, Zabbix garde l’historique des triggers qui se sont déclenchés, même si aucune alerte n’a été émise, pour permettre d’aller consulter les historiques.

Outre les antennes, on supervise aussi les routeurs et divers switchs du réseau ainsi que les quelques machines virtuelles dont on se sert. Il reste un peu de travail à faire de ce côté pour être alertés convenablement de certains problèmes.

L’empilement de tout ça donne 1300 équipements supervisés pour 106054 sources de données (mises à jour entre une fois par minute et une fois par jour, en fonction des sources) et 30230 triggers susceptibles de se déclencher en fonction des données récoltées.

La machine virtuelle qui gère tout ça dispose de 150Go d’espace disque, de 6Go de ram et de 8 vCPU et récolte une moyenne de 320 valeurs par seconde.

En face de Zabbix lui même, le système d’information lui envoi ses directives de configuration via l’API (telle antenne doit être supervisée, telle autre a changé de nom, celle-ci a changé de modèle et on doit donc lui appliquer d’autres types de tests, …), récupère, à la demande, divers graphiques qui sont affichés sur la cartographie (qualité des liens, débit, …). On a également un script qui va récupérer, toujours via l’API, l’ensemble des information de qualité de liens pour constituer la carte globale du réseau et, bien sûr, celui qui aiguille les alertes vers les groupes Telegram.

Au chapitre « tout n’est pas rose dans Zabbix » :

• Contrairement à ce qu’on avait avant, l’historisation de donnée est beaucoup moins fine : soit on garde tout ce qui a été récolté (et on fait exploser la machine), soit on n’en garde que quelques jours et Zabbix fait ensuite des moyennes heure par heure (ou à une autre granularité, mais on n’a pas trouvé ou ça se changeait .. Bon, on n’a pas beaucoup cherché, il faut dire). Dans la plateforme précédente, on utilisait RRDTools, qui permettait par exemple de dire « on garde toute la récolte pendant 1 mois, puis on fait une moyenne sur 10 minutes pour 6 mois, puis sur 1 heure pour 1 an, puis sur un jour pour 10 ans » .. Et surtout, ce type de granularité était configurable source par source. La ou 10 ans de données de nos 1300 équipements pouvaient rentrer dans 60Go, il en faudra probablement 20 à 30 fois plus pour la même rétention dans Zabbix (mais en même temps, on collecte beaucoup plus d’infos)
• Le moteur de génération de graphiques souffre de grosses carences : impossible d’utiliser deux axes verticaux (un à gauche pour la latence et un à droite pour la perte par exemple) en indiquant des minima et maxima différents. Hardu, également, de faire un graphique de débit avec l’inbound en positif et l’outbound en négatif. Impossible d’inclure une interface réseau précise sur l’écran récapitulatif d’un équipement si celle-ci a été découverte automatiquement : soit on les met toutes, soit on n’en met pas. Bref, y’a encore du boulot ! On a contourné une partie des problèmes en installant Grafana (qui fera l’objet d’un article ultérieurement) et en intégrant manuellement certains graphiques issus de Zabbix dans des pages du système d’information (mais du coup, on perd les fonctionnalités de déplacement dans le temps et de zoom)
• La partie optimisation est incontournable et assez peu (ou mal) documentée. On a passé un bon mois avec un Zabbix qui plantait régulièrement, on a du renoncer aux triggers qui calculaient des moyennes mensuelles parce que ça faisait totalement exploser la machine quand ils étaient calculés et le nettoyage des anciennes valeurs est à présent géré par le partitionnement de MySQL plutôt que par Zabbix lui même.

En bref, on est plutôt content, on a gagné en source de données et en clarté de présentation, mais on regrette fortement RRDTools qui était un outil de stockage et de présentation de données très performant et peu gourmand, à la fois en temps processeur et en espace disque.

Un grand merci à @SteveDESTIVELLE qui a filé pas mal de coups de main pendant toute la phase de mise en production !