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 DataBase, 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.



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 ! 

GG pour les travaux, c'est ouf de faire ça en 3 semaines et en plus en venant d'arriver dans la structure !

Merci ! 
Effectivement 3 semaines c'est super chaud, et il y a encore plein de pistes d'amélioration pour rendre tout ça plus puissant

Concernant les alertes arrivant dans le canal de discussion, il n'y en a pas trop qui arrivent ?
Comment est effectuée la prise en charge ? Quelqu'un est dédié pour surveiller ce canal et gérer ces alertes ?
Est-ce qu'il y a un outil ITSM pour la gestion des alertes ? Je ne sais pas comment c'est géré actuellement mais ça laisse une belle opportunité d'améliorer encore plus le système ce que tu as mis en place

Malheureusement si, il y a au moins 1 alerte toutes les 5 minutes (les messages sont envoyé par batch pour pas flood le canal), mais l'idée derrière serait de faire en sorte de faire un suivi plus poussé de ces alertes (en les comptabilisant par exemple) pour pouvoir avoir de l'analyse automatique

Pour le moment, la prise en charge est difficile voire même impossible, comme il n'y a pas d'outil d'analyse, très peu probable de dire si un modem est en dessous du seuil d'alerte souvent ou non, à part en consultant son graphique, mais comme il y a différent seuil d'alerte, il est possible de se concentrer sur les modems qui sont sur un seuil critique d'alerte, on estime que le seuil critique engendre la perte de connexion, le modem décroche, mais évidemment, ce serait beaucoup mieux de s'en rendre compte avant d'atteindre ce seuil.

Et non, pas d'outil ITSM, il faudrait établir une stratégie pour prendre en compte ces alertes de façon plus utile qu'actuellement.

Félicitations Maiiwen__ pour tout ton travail et merci pour ton post détaillé afin de nous faire découvrir J.A.R.V.I.S. C'est toujours intéressant de savoir ce qu'il se passe dans les coulisses d'Orne THD .

C'est avant tout le but d'un stage : découvrir.

Mon but c'est pas que vous subissiez le stage avec des tickets/support, suivre bêtement un tech, d'installer un pauvre windows, car c'est la meilleure façon d'avoir qqn de démotivé (et ça se sent à la soutenance).

Mon but c'est de vous faire découvrir des choses totalement nouvelles, d'apparence banales, mais souvent complexes, mais finalement quand vous arrivez au bout du truc, avec vos connaissances et ce que je vous apprends, vous vous prenez un shoot de fierté et de reconnaissance toussa et vous kiffez. C'est ça qui permet de tirer les gens vers le haut, et d'avoir des soutenances de stage au top.

La preuve avec ce topic

Pour le coup, énormément de découvertes, et honnêtement je pense qu'on peut pas rêver mieux pour un stage. Ça fait beaucoup évoluer positivement de se confronter à des choses nouvelles. Avec le risque cependant d'aller beaucoup trop loin pour les attendus de certaines formations 

Après, les alertes c'est pas au point, etc, mais ça t'a permis de découvrir le SNMP, les bases de données de temps, de faire des liaisons avec le SI, etc. Chaque jour tu as monté une marche. C'est ça qui nous fait avancer, et c'est ce que je veux et peut souhaiter de mieux pour chacun.

C'est pas encore au point mais il y a tellement de possibilités à développer pour que ce soit plus utile !

Là où Maiiwen__ apporte sa patte c'est de pousser ça jusqu'à l'abonné précis, avec de l'historique (alors que jusqu'à présent on ne prenait que la mesure à l'instant T). Car même si sur la masse, c'est bien, mais je ne peux pas m'en contenter. Il faut que le service soit excellent chez tout le monde. Et justement, on pourra cibler le dépannage suivant les récurrences, etc.

Techniquement il faut aussi dire qu'il est possible de faire de la masse également avec le système de dashboard d'InfluxDB, on peut imaginer afficher chaque jour le résumé de la journée précédente, avec ça, on peut extraire les modems qui ont été au moins une fois en dessous d'un seuil, et ainsi soit les afficher sur une carte, soit afficher le graphique pour voir les modems qui ont été le plus en galère. Ce qui permet de vérifier la stabilité sur une journée plutôt qu'à l'instant T.

Et encore une fois, félicitations ! Il y en a du talent dans nos communes

Il faut dire qu'en voyant le #PTDQ, on a envie d'y participer

Félicitations Maiiwen__ pour tout ton travail et merci pour ton post détaillé afin de nous faire découvrir J.A.R.V.I.S. C'est toujours intéressant de savoir ce qu'il se passe dans les coulisses d'Orne THD .

Merci ! Et pas de quoi, J.A.R.V.I.S. est un outil superbe et de pouvoir vous le faire découvrir est pour moi très important

En somme, c'est du SNMP + InfluxDB + Grafana.

C'est assez classique comme stack.

Pas de Grafana, non. La version 2 de l'UI d'InfluxDB inclut par défaut un système de graphs/dashboard. Et pour la page de statistiques, j'ai utilisé Giraffe, la librairie de visualisation utilisée dans InfluxDB.

Pas de Grafana, non. La version 2 de l'UI d'InfluxDB inclut par défaut un système de graphs/dashboard. Et pour la page de statistiques, j'ai utilisé Giraffe, la librairie de visualisation utilisée dans InfluxDB.

l'inconvénient c'est que tu es "vendor-locked" et tu t'empêches potentiellement d'agréger dans les dashboards d'autres sources de données que ce qui provient d'influxdb. Grafana offre plus de flexibilité je trouve.