L’ensemble de la supervision du r\u00e9seau de SCANI a \u00e9t\u00e9 refondue cet \u00e9t\u00e9. Il faut savoir que ce qui existait avant avait \u00e9t\u00e9 mont\u00e9 bribe par bribe, en fonction de l’arriv\u00e9e des besoins, que ce n’\u00e9tait pas toujours exhaustif (par exemple, les 4 machines jouant le r\u00f4le de serveurs DNS pour l’ensemble des membres n’\u00e9taient pas surveill\u00e9es) et, surtout, que c’\u00e9tait de plus en plus gourmand en ressources techniques.<\/p>\n
Cette ancienne supervision fonctionnait sur la m\u00eame machine que le syst\u00e8me d’information technique et cartographique de la coop\u00e9rative. Du coup, depuis d\u00e9but 2018, tout \u00e7a \u00e9tait fortement ralenti, puisqu’\u00e0 chaque nouvelle antenne install\u00e9e correspondait un nouveau test de supervision mis en place.<\/p>\n
Un appel a bonnes id\u00e9es et \u00e0 \u00ab\u00a0propose quelque chose\u00a0\u00bb avait donc \u00e9t\u00e9 lanc\u00e9 et c’est Benjamin qui s’y est coll\u00e9. Bruno a ensuite mis sa patte pour la mise en production et les d\u00e9veloppements n\u00e9cessaires dans le syst\u00e8me d’information.<\/p>\n
L’ancienne plateforme tournait sur la base d’un Nagios agr\u00e9ment\u00e9 du plugin pnp4nagios pour la partie graphiques historiques. Les pr\u00e9requis pour la nouvelle \u00e9taient les suivants :<\/p>\n
Le choix, pour la nouvelle plateforme, s’est port\u00e9 sur Zabbix. Il a une m\u00e9thode de fonctionnement assez contre-intuitive quand on vient du monde de la supervision des ann\u00e9es 1990, mais il faut reconna\u00eetre qu’il cochait pas mal de cases de notre liste. Voil\u00e0 en gros comment \u00e7a fonctionne :<\/p>\n
Le tout est agr\u00e9ment\u00e9 de notions de template, ce qui permet de cr\u00e9er par exemple la supervision id\u00e9ale de tel type d’\u00e9quipement et ensuite de l’appliquer en s\u00e9rie \u00e0 des centaines d’\u00e9quipements. Lorsqu’on modifie le template, tout le monde suit.<\/p>\n
Il y a \u00e9galement un principe de discovery bien utile pour les choses qui peuvent varier d’un \u00e9quipement \u00e0 un autre. On s’en sert surtout pour la supervision des partitions de disques dur (qui ne sont pas toutes les m\u00eames sur toutes les machines) ou des interfaces r\u00e9seau (dont le nombre varie d’une antenne \u00e0 une autre). Une fois bien configur\u00e9, tout \u00e7a est transparent dans l’usage quotidien de l’outil, \u00e7a change des fichiers de configurations qui font 12000 kilom\u00e8tres de long.<\/p>\n
Du coup, mise en pratique !<\/p>\n
Premier objectif : parvenir \u00e0 extraire des antennes du r\u00e9seau au moins autant d’information que ce qu’on avait avant. Une inf\u00e2me mixture de requ\u00eates SNMP et de lancement de scripts SSH et HTTPS \u00e9tait n\u00e9cessaire jusqu’\u00e0 pr\u00e9sent, mais on a trouv\u00e9 toutes les OID n\u00e9cessaires pour extraire ce dont on avait besoin en SNMP. Un socle commun de templates a \u00e9t\u00e9 mont\u00e9 \u00e0 partir de ce qu’on a trouv\u00e9 en ligne, et trois d\u00e9riv\u00e9s, pour les antennes Ubiquiti g\u00e9n\u00e9ration M, AC et AirFiber ont ensuite \u00e9t\u00e9 mont\u00e9s par dessus.<\/p>\n
Pour la faire courte, on r\u00e9cup\u00e8re donc :<\/p>\n
De tout \u00e7a, on sort un certain nombre de triggers :<\/p>\n
Toutes les notifications issues de ces triggers sont ensuite envoy\u00e9s \u00e0 un script local \u00e0 la machine de supervision qui va questionner le syst\u00e8me d’information pour savoir ce qu’il convient de faire avec l’alerte. Le SI dispose de plusieurs groupes de notification Telegram, secteur g\u00e9ographique par secteur g\u00e9ographique, et indique donc \u00e0 la supervision \u00e0 quel groupe Telegram il faut envoyer le message pour que les personnes concern\u00e9es le re\u00e7oivent. Il peut, bien entendu, envoyer une info \u00e0 plusieurs groupes en m\u00eame temps.<\/p>\n
Dans tous les cas, Zabbix garde l’historique des triggers qui se sont d\u00e9clench\u00e9s, m\u00eame si aucune alerte n’a \u00e9t\u00e9 \u00e9mise, pour permettre d’aller consulter les historiques.<\/p>\n
Outre les antennes, on supervise aussi les routeurs et divers switchs du r\u00e9seau ainsi que les quelques machines virtuelles dont on se sert. Il reste un peu de travail \u00e0 faire de ce c\u00f4t\u00e9 pour \u00eatre alert\u00e9s convenablement de certains probl\u00e8mes.<\/p>\n
L’empilement de tout \u00e7a donne 1300 \u00e9quipements supervis\u00e9s pour 106054 sources de donn\u00e9es (mises \u00e0 jour entre une fois par minute et une fois par jour, en fonction des sources) et 30230 triggers susceptibles de se d\u00e9clencher en fonction des donn\u00e9es r\u00e9colt\u00e9es.<\/p>\n
La machine virtuelle qui g\u00e8re tout \u00e7a dispose de 150Go d’espace disque, de 6Go de ram et de 8 vCPU et r\u00e9colte une moyenne de 320 valeurs par seconde.<\/p>\n
En face de Zabbix lui m\u00eame, le syst\u00e8me d’information lui envoi ses directives de configuration via l’API (telle antenne doit \u00eatre supervis\u00e9e, telle autre a chang\u00e9 de nom, celle-ci a chang\u00e9 de mod\u00e8le et on doit donc lui appliquer d’autres types de tests, …), r\u00e9cup\u00e8re, \u00e0 la demande, divers graphiques qui sont affich\u00e9s sur la cartographie (qualit\u00e9 des liens, d\u00e9bit, …). On a \u00e9galement un script qui va r\u00e9cup\u00e9rer, toujours via l’API, l’ensemble des information de qualit\u00e9 de liens pour constituer la carte globale du r\u00e9seau et, bien s\u00fbr, celui qui aiguille les alertes vers les groupes Telegram.<\/p>\n
Au chapitre \u00ab\u00a0tout n’est pas rose dans Zabbix\u00a0\u00bb :<\/p>\n
En bref, on est plut\u00f4t content, on a gagn\u00e9 en source de donn\u00e9es et en clart\u00e9 de pr\u00e9sentation, mais on regrette fortement RRDTools qui \u00e9tait un outil de stockage et de pr\u00e9sentation de donn\u00e9es tr\u00e8s performant et peu gourmand, \u00e0 la fois en temps processeur et en espace disque.<\/p>\n