Salut tout le monde !
Je commence par cette citation : «
J’ose le dire : ça pète des culs ! » -
Optix : 2022
Il y a un peu plus d’un mois, et dans le cadre de mon titre de développeuse web et web mobile, s’achevait mon stage du côté obscur de la force, l’objectif qu’Optix m’avait donné était à la fois simple d’apparence, mais extrêmement complexe.
Cet objectif était celui-ci : « Il te faut analyser le système de monitoring des modems des clients particuliers, et faire en sorte de l’améliorer en prenant en compte les besoins des équipes *
Fin de transmission* ».
Les premiers jours du stage, j’ai donc dû faire un peu de reconnaissance dans le projet existant, et pour tout vous dire, ça n’a pas été de tout repos ! Avec seulement quelques mois d’études dans le développement web, la masse déjà produite était pas loin de me submerger ! Heureusement, à force d’échanger avec les différents membres de l’équipe, j’ai pu construire un plan d’action pour pouvoir mettre en place une meilleure version de l’outil dénommé sobrement par son créateur :
J.A.R.V.I.S !
Pour commencer donc : voici un petit état des lieux : J.A.R.V.I.S est un outil de supervision des modems, il est interfacé avec le S.I. (Système d’Information) de OrneTHD pour pouvoir identifier chaque client en cas d’anomalie constatée sur son modem. Il surveille quelques données essentielles pour connaître le bon fonctionnement d’un modem (appelés plus tard : métriques).
Dans ces métriques, on y retrouve :
- les
FLAPS : c’est-à-dire le nombre de fois que la connexion du modem a été supprimée (= déconnexion de l’utilisateur),
- le
SNR : (
Signal
Noise
Ratio) étant le rapport signal bruit, plus ce rapport est élevé mieux c’est. Pour vulgariser le SNR, on peut prendre l’exemple d’une conférence, les auditeurs créent un bruit tandis que l’orateur crée un message, plus le message est prononcé avec un volume bas, moins les auditeurs perçoivent ce message, au contraire, plus le message est prononcé avec un volume élevé, mieux les auditeurs le perçoivent, ainsi le SNR est calculé : selon le niveau de bruit et la puissance du signal (le volume du message).
Ces métriques récupérées sont liées à chaque clients, et tout ceci est présenté sous la forme d’une carte (qui ne doit pas paraître inconnue à certains présents aux dernières portes ouvertes
) , par exemple :
Chaque point est un client, les points grisés sont des clients dont aucun modem n’est connecté, et les points verts jusqu’à rouge sont des clients disposant de modems, vert signifiant que les métriques sont bonnes, rouge signifiant que les métriques sont mauvaises, à noter que nous pouvons choisir quelle métrique analyser pour choisir entre FLAPS et SNR.
J.A.R.V.I.S dispose d’un moteur de recherche pour trier l’affichage selon différents paramètres : le CMTS, la rue, la ville, etc…
Ces métriques sont récupérés de cette manière : un script interroge périodiquement les différent CMTS en utilisant le protocole
SNMP (Simple Network Management Protocol), pour faire simple : c’est un protocole de communication qui permet, comme nous le faisons avec le protocole http pour le web, de communiquer avec les équipements réseau. Pour chaque CMTS, on traite les données récupérées pour leur donner du sens et les stocker dans une base de données, c’est à ce moment qu’on lie chaque client à son modem !
Maintenant que l’on sait comment tout ça fonctionne, on peut adapter J.A.R.V.I.S pour le booster et étendre ses capacités
.
Mais tout d’abord, il faut s’intéresser à quelle nouvelle fonctionnalité faut-il implanter, et la voici :
Il faut faire en sorte que les métriques puissent être consultées dans le temps, pour pouvoir identifier une panne périodique, lorsque vous signalez une coupure récurrente chaque soir par exemple !
Et pour, in fine :
permettre une intervention spontanée des équipes, sans même que l’abonné n’ait le temps de remarquer le dysfonctionnement !
Petite précision : mon stage dure trois semaines, 3 semaines pour rendre ça possible, ça me semblait à ce moment titanesque comme travail !
Pour pouvoir rendre ceci possible, il faut :- Trouver un moyen de récupérer les différentes métriques périodiquement (par exemple toutes les 5 minutes).
- Cette partie est simple, il suffit de s’inspirer de l’existant !
- Trouver un moyen de stocker ces métriques
- Cette partie est un peu moins drôle, en effet, il y a environ 8000 modems constamment connectés. Si l’on récupère seulement leur SNR, toutes les 5 minutes, ce ne sont pas moins 96000 entrées par heure, 2304000 par jour, 71424000 par mois. Il fallait se rendre à l’évidence : le type de base de données utilisée jusqu’alors (base de données relationnelle), n’était pas du tout conçue pour cette masse de données .
Pour cela, il faut s'intéresser aux bases de données dites «
TSDB » pour
Time
Series
Data
Base, signifiant bases de données de séries chronologiques dans la langue de Shakespeare. Ce type de base de données utilise le temps comme indice, contrairement aux bases de données relationnelles, qui utilisent un indice auto-généré unique comme indice, ce qui permet un accès au données plus rapide, cependant, cela limite drastiquement la quantité de données pouvant être stockées. Ces TSDB sont optimisées pour travailler avec le temps, à la manière du Tardis dans docteur who, il est donc facile de voyager dans le temps pour retrouver les métriques des modems.
C’est alors que débarque
InfluxDB, et selon Wikipédia : « InfluxDB est un système de gestion de base de données orientée séries temporelles hautes performances ». Parfait ! C’est exactement ce qu’il nous faut : de la performance ! Avec InfluxDB, on peut également utiliser l’outil «
Telegraf » et le plugin intégré capable de communiquer en
SNMP.
C’est ainsi que nous arrivons au jour 4 de mon stage, la première semaine est presque finie et je réussi à récupérer toutes les 5 minutes le SNR de tous les modems sur tous les CMTS et voici ce à quoi je suis confrontée :
Des lignes, des lignes, et encore des lignes
, chaque ligne correspond à un upstream (voie remontante au CMTS) contenant quelques informations :
Le temps, la valeur, des infos provenant du protocole SNMP, l’IP du CMTS (agent_host), l’hôte duquel provient les données, le nom du CMTS (hostname) et un indice généré par le CMTS contenant une partie identifiant le modem, une autre partie identifiant l’upstream concerné.
Problème : impossible de retrouver l’abonné avec ces informations. Il faudra aller chercher d’autres informations contenues dans ce qui est récupéré sur les CMTS, soit une adresse MAC, soit une adresse IP. Cette opération est gourmande en performance, si bien que les premiers essais se sont avérés chronophages (Plus de 15 minutes de génération pour 1 seul CMTS pour 1 heure de temps
), la génération du graph qui suit aurait pris un temps monstrueux à générer, mais avec la puissance de l'optimisation, j’ai pu faire baisser ce temps de génération à maximum 1 minute pour une heure de données affichées !
Ce dashboard affiche les IP sur chaque upstream, permettant donc de retrouver le modem en défaut, ou dans le cas où plusieurs upstream tombent, d’identifier la zone en défaut.
Et en avant première : voici une petite image d’illustration des bureaux d’OrneTHD lors de mes tests :
La deuxième semaine commence : les graphs globaux sont générés, maintenant je dois générer des graphs selon le client, afin que, depuis la carte de J.A.R.V.I.S, les équipes puissent consulter l’historique des métriques de chaque client.
De retour dans la génération de graphique, les premiers essais étaient également très complexes, mais cette fois, j’ai pu améliorer le temps de génération à plus d’une semaine en moins de 2 minutes, dans mes premiers tests, cette opération aurait pris une éternité !
En finalité, je peux afficher cette page qui suite, pour ce faire, il suffit de fournir à cette page l’adresse MAC/IP du modem ou de l’index et le nom du CMTS d’un upstream.
Elle permet aux équipes de sélectionner le lapse de temps désiré mais également de partager le graphique grâce au lien de partage à d’autres équipes. On récupère également toutes les informations du modem concerné mais aussi les informations du client liées au modem et les différentes métriques récupérées (ici, SNR et
RxPower, la puissance de réception du modem).
Cette page est accessible depuis la carte avec une nouvelle ligne ajoutée aux informations avec un lien direct vers les graphs
Pour finir la semaine, je remarque qu’il y a moyen de fixer des niveaux d’alertes avec influxDB et de récupérer ces alertes, je m’occupe donc de créer un système qui va récupérer toutes les alertes et les envoyer dans un canal de discussion dédié aux alertes, afin de prévenir les équipes que certaines métriques dépassent un seuil d’alerte.
Début de la 3ème et dernière semaine : Optix est de retour et je lui fait un compte rendu. Sa réaction, je cite : «
J’ose le dire : ça pète des culs ! ». Suivi d’un «
NOM DE DIEU !!! » lorsque je lui montre le système d’alerte
. On échange et j’identifie avec lui quelques derniers problèmes et pistes d’amélioration que je règlerais dans le courant de la dernière semaine.
Je m’occupe de faire en sorte que les points sur la carte ne concernent plus un client mais plutôt une adresse, ce qui permettra de consulter tous les abonnés d’une adresse, alors qu’auparavant, tous les points se superposent sur la carte, rendant impossible le fait de consulter les autres occupants d’un habitat collectif.
Je m’occupe également de créer un mode jour, afin que les techniciens sur le terrain puissent consulter plus aisément J.A.R.V.I.S.
Je m’occupe aussi de déployer l’outil pour que cela puisse être utilisable et je crée une mini documentation afin de pouvoir redéployer toute l’infra au besoin. Malheureusement, un autre objectif très important n’a pas pu encore être réalisé totalement : les techniciens sur le terrain n’ont toujours pas accès à J.A.R.V.I.S. :'(, mais ce n’est qu’une question de temps !
En conclusion : L’outil répondait au besoin de localiser les poches en défaut sur une carte et ainsi dépêcher des interventions ciblées sur zone. Désormais les améliorations apportées à J.A.R.V.I.S. permettent d’avoir un suivi temporel et ciblé des différentes métriques, ayant pour conséquence un diagnostic plus simple du point de vue de ces métriques. Aussi, avec le système d’alerte, il est possible d’être notifié lorsqu’un modem a des mauvaises métriques, et ainsi déclencher une intervention spontanée afin de résoudre le problème. Tout ça pour venir à bout des derniers modems hérétiques !
Pour finir, ça a été un vrai plaisir de travailler aux côté des différentes équipes, et je voudrais une fois de plus remercier Optix pour sa confiance et toutes les personnes qui m’ont accompagnée pendant ces trois semaines !
Merci pour votre attention !