Monitoring de synchronisation ADSL avec Telegraf, InfluxDB, Grafana, et un peu d’huile de coude

closeCet article a été publié il y a 7 ans 9 mois 16 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

Avec les problèmes à répétition que rencontre la connexion ADSL de ma mère depuis un an, et la Freebox n’enregistrant que les douze derniers évènements de déconnexion/connexion, j’ai cherché une solution pour collecter plus longuement ces infos et en disposer sous forme visuelle claire. Après avoir lu l’article de Guillaume sur ce genre de solution, et disposant d’un Raspberry Pi B+ en pré-retraite, je me suis dit qu’elle était toute indiquée pour le but recherché. Récit d’un petit voyage pas toujours tranquille.

Le contexte

Depuis un peu plus d’un an, la connexion entre parfois en mode asthmatique avec des quintes de toux, comprendre des grosses crises de déconnexions, particulièrement violentes, et parfois prolongées. Petit florilège avant le début de mes tests :

On voit les dégâts, aussi bien sur les débits que sur la stabilité elle-même, avec un record à 2h de coupure entre 8h et 10h le 7 Juillet. Et ça arrive de manière apparemment totalement aléatoire, des périodes de stabilité de trois semaines ont été constatées déjà. Je veux donc pouvoir récupérer ces données de manière simple et visuelle.

Pourquoi pas Munin ou une solution maison ?

Munin est intéressant et c’est la solution que l’on utilise avec Arowan pour le monitoring du serveur physique et des VMs qui sont sous notre contrôle, mais il a tendance à lisser les résultats quand on remonte dans le passé, donc il n’est plus possible de scruter correctement une période qui remonte à plus d’un mois. Non, j’avais besoin d’une solution qui ne dégrade pas les données dans le temps.

Et la solution maison, certes, ça aurait été poilant mais j’ai franchement la flemme de me coller au dev d’une solution de graphes à partir d’un jeu de données. Et comme tout bon flemmard qui se respecte, quand les solutions existent déjà, pourquoi se priver ?

Réutiliser l’existant au maximum

Ou presque, en effet, je ne vais pas détailler toute l’installation que j’ai faite, l’article de Guillaume est assez clair là-dessus, d’autant plus que dans le premier jet de ce « Proof of Concept », j’ai vraiment organisé les confs comme un porcho. Aussi, pour l’instant, derrière la box, point de reverse-proxy, j’attaque Grafana en direct sur son port, et j’ai besoin d’un tunnel SSH pour ça.

Pour la collecte des valeurs de synchros, je ne lancerai pas de speedtests frénétiques en permanence, je me suis basé sur ce que j’avais fait dans l’article sur la récupération des infos de la Freebox V5/Crystal, on se rend compte que l’article était déjà motivé par des problèmes récurrents à l’époque. J’ai par contre dû prendre la version en Python, de manière tout à fait étrange curl et wget me renvoyaient un blob que grep considérait comme binaire. Un changement côté Freebox peut-être, pas pris le temps de chercher.

Mais passons aux choses sérieuses.

Les limites de l’infrastructure proposée

Il y a un gros bémol à l’installation que j’ai faite pour l’instant : tout est stocké sur la carte SD du Raspberry Pi, en dehors de la lenteur de la solution, il me faut dépendre de la connexion en question pour afficher les graphes, ce qui, les jours où la synchro montante tombe aussi bas que 250kbps, devient juste impossible. Et rien n’est sauvegardé pour l’instant.

Il faudrait donc à terme déporter InfluxDB ainsi que Grafana pour ne laisser que le collecteur Telegraf sur le Pi, ce qui limite les problèmes d’accès aux données collectées.

Vous êtes prévenu.

Quel format pour l’input de Telegraf ?

Ce qui est intéressant, c’est que plusieurs formats peuvent être renvoyés à Telegraf pour qu’il stocke les données dans InfluxDB. Je cherche à récupérer simplement les valeurs, une pour le débit descendant (download), l’autre pour le débit montant (upload), tout aussi important mais tellement délaissé par les vendeurs de Minitel et les amateurs de concours de grosses bites. Voici le fichier inputs.conf que j’ai placé dans /etc/telegraf/telegraf.d :

L’input exec permet de lancer n’importe quel script et d’en exploiter les données. Il faut évidemment adapter la sortie de son script à sa finalité, et comme je n’ai pas réussi à envoyer du JSON (qui est parfaitement supporté si on se documente un peu), je me suis rabattu sur une valeur simple, en forçant l’intitulé. Petit aperçu dans InfluxDB :

Voyons comment j’ai pu extraire ces infos pour les stocker dans Influx.

Le script de récupération des données

Le script pour récupérer la valeur du débit déscendant est le suivant, il est beaucoup plus simple que celui de mon article précédent :

Pour l’équivalent du débit montant, remplacer le [2] par [4], et paf, ça fait des Chocapic :

En testant le bon fonctionnement de la configuration, on obtient un truc dans le genre :

Le problème de Grafana sur Raspberry Pi

J’ai découvert au dernier moment que Grafana n’était pas packagé pour Raspberry Pi (Debian Arm pour être plus précis). Chiant, je me suis rabattu sur ce dépôt Github qui propose un binaire compilé sur Pi 2, mais après avoir souffert en dépendances non résolues, j’ai lâché l’affaire, d’autant que je n’avais pas envie de me manger deux heures de recherches et essais foireux.

Quand je parlais de déporter le bordel sur un truc moins tendu, jusqu’à ce moment-là je m’attendais pas à ce que ça soit aussi vrai. Je me suis au final rabattu sur mon laptop, les repos Manjaro proposant Grafana dans community. Tant que je reste sur un réseau local, ça passe tranquille, faudra pousser le concept une fois l’installation réelle stabilisée, fiabilisée, et surtout terminée. Ça suffit pour faire ses premiers pas.

Le Dashboard

Je suis allé au plus vite, au diable la gestion des utilisateurs vu que je suis en local sur le laptop, j’ai poussé au plus pressé, j’ai ajouté mon data source :

grafana_datasource_rpiEnsuite, j’ai configuré un nouveau dashboard, avec une seule ligne, qui regroupe les deux valeurs que je récupère :

grafana_metricsEt voilà, quelques options réglées plus tard, comme les valeurs courantes, les mini/maxi, les légendes&co, j’ai une solution pour afficher de manière propre les données. Bonne fonctionnalité de Grafana, on peut zoomer dans les graphes pour avoir les détails, dans la mesure où vous prenez vos données assez finement.

grafana_final_graphAttention à l’espace disque

Pas de grafana, qui stocke les paramètres de vos dashboards dans une bases de données SQLite particulièrement légère, non je parle d’InfluxDB ainsi que de Telegraf, son log surtout. Encore que pour ce dernier, un fichier de conf pour logrotate devrait vous assurer que la taille n’augmente pas trop, à raison d’une rotation tous les 6 jours. Quant à InfluxDB, pour les données récoltées, il y a 3,7Mo pour le graphe obtenu ci-dessus. Ça vous parait beaucoup ? Mais c’est que je prend une mesure toutes les 15 secondes aussi.

A terme, je pourrais grandement réduire cette fréquence à environ une minute, ou alors au moins 30 secondes, sachant qu’il faut environ une minute pour qu’une resynchronisation aie lieu en cas de coupure.

Un premier jet pratique, qui ne demande qu’à s’améliorer (et à réutiliser ailleurs ?)

Dans tous les cas, et pour pouvoir considérer la consultation des graphes en toute circonstance, il me faudrait déporter InfluxDB et Grafana plutôt sur le serveur chez OVH. Pour s’assurer que ça fonctionne bien, il faudrait considérer l’authentification, la connexion par SSL (histoire de chiffrer correctement la connexion entre Telegraf et InfluxDB), bref, blinder l’archi, tuner le polling, une bonne base pour bricoler et creuser un peu plus.

Si vous pensez pouvoir vous resservir, ou améliorer ce dispositif (par exemple en m’expliquant comment lui faire accepter du JSON, ou comment le formater pour qu’il l’accepte), voire trouver un usage sympa du triptyque Telegraf/InfluxDB/Grafana, y’a les commentaires pour partager tout ça, je suis curieux de lire vos avis. D’ailleurs, ça me fait penser que ce n’est pas le seul genre de dispositif à trois composants qu’on voit ces dernières années. Ça vous dit quelque chose, ELK ? 😀

11 Commentaires
Le plus ancien
Le plus récent
Commentaires en ligne
Afficher tous les commentaires
paul
paul
12/07/2016 08:57

Je dirais de faire attention à cette valeur : metric_buffer_limit. Car si tu déportes ton influxdb et que ta liaison entre ton telegraf et ton influxdb est dead … pas de graph.

J’utilise les trois sur mon serveur dans docker et c’est vrai que c’est top. Tout marche nickel. J’ai même maintenant une petite préférence pour telegraf comparé à collectd.

Guillaume
12/07/2016 12:43

Belle mise en œuvre de Telegraf 🙂
Ce petit outil permet vraiment d’ingérer toutes sortes d’input !

J’ajoute un lien vers ton article sur le mien 😉

xhark
14/07/2016 22:55

Joli ! je suppose que tu as une v5 car sur la v6 y’a déjà un graph intégré 🙂

Erwann
Erwann
15/07/2016 11:02

Merci pour cette proposition de monitoring qui supplée à l’absence d’agent SNMP sur les FreeBox (je ne sais d’ailleurs pas si les autres FAI activent l’agent SNMP sur leurs box). Pour information, depuis 2003, après LibertySurf, Tiscali, Alice, j’ai depuis 15 mois une FreeBox Revolution et j’ai connu rarement mais aléatoirement des semaines difficiles, dans un village à 2750 m du NRA. Je crains qu’actuellement les liaisons ADSL ne fassent les frais d’une infrastructure cuivre historique « un peu » âgée. Free a toujours été coopératif dans la recherche des causes des pannes. Mon impression est que le réseau cuivre – surtout… Lire la suite »

momo
momo
22/03/2017 10:44

Article très intéressant. As-tu eu l’occasion de tester un ELK ou Splunk ? Un retour d’expérience la dessus ? Je réfléchis à une solution facile à mettre en place pour un ensemble d’applications fournissant des logs et des APIs Rest pour récupérer des métriques.

Merci d’avance

momo
momo
29/03/2017 15:15
Répondre à  Seboss666

Merci de ta réponse néanmoins. Graylog je ne connaissais pas. A ce que je vois les outils ne manquent pas pour faire du monitoring. Reste à faire le bon choix en fonction de notre environnement et de nos spécificités

Alain
Alain
06/10/2017 11:13

Très intéressant, merci d’avoir pris le temps de partager!