4 ans 2 mois 13 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées, les commandes ne sont peut-être plus valides. Cet article a été publié il y a, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées, les commandes ne sont peut-être plus valides.

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 :

Journal de connexion adsl : --------------------------- Date Etat Débit (kb/s) -- -- -- 08/07/2016 à 22:39:08 Connexion 735 / 689 08/07/2016 à 22:38:02 Déconnexion 07/07/2016 à 12:22:34 Connexion 1725 / 1025 07/07/2016 à 11:53:20 Déconnexion 07/07/2016 à 11:48:43 Connexion 2038 / 726 07/07/2016 à 11:47:47 Déconnexion 07/07/2016 à 10:22:05 Connexion 1443 / 711 07/07/2016 à 10:21:09 Déconnexion 07/07/2016 à 10:05:51 Connexion 2528 / 248 07/07/2016 à 08:13:12 Déconnexion 07/07/2016 à 08:11:53 Connexion 2188 / 714 07/07/2016 à 08:10:57 Déconnexion 07/07/2016 à 08:09:47 Connexion 1963 / 722 07/07/2016 à 08:08:51 Déconnexion 07/07/2016 à 07:10:38 Connexion 287 / 605 07/07/2016 à 07:09:42 Déconnexion 07/07/2016 à 07:07:55 Connexion 3056 / 248 07/07/2016 à 07:07:25 Déconnexion 07/07/2016 à 07:07:12 Connexion 2264 / 214 07/07/2016 à 07:00:17 Déconnexion 07/07/2016 à 06:32:59 Connexion 2786 / 220 07/07/2016 à 06:29:23 Déconnexion 07/07/2016 à 06:29:00 Connexion 2252 / 230 07/07/2016 à 06:02:32 Déconnexion 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 Journal de connexion adsl : --------------------------- Date Etat Débit (kb/s) -- -- -- 08/07/2016 à 22:39:08 Connexion 735 / 689 08/07/2016 à 22:38:02 Déconnexion 07/07/2016 à 12:22:34 Connexion 1725 / 1025 07/07/2016 à 11:53:20 Déconnexion 07/07/2016 à 11:48:43 Connexion 2038 / 726 07/07/2016 à 11:47:47 Déconnexion 07/07/2016 à 10:22:05 Connexion 1443 / 711 07/07/2016 à 10:21:09 Déconnexion 07/07/2016 à 10:05:51 Connexion 2528 / 248 07/07/2016 à 08:13:12 Déconnexion 07/07/2016 à 08:11:53 Connexion 2188 / 714 07/07/2016 à 08:10:57 Déconnexion 07/07/2016 à 08:09:47 Connexion 1963 / 722 07/07/2016 à 08:08:51 Déconnexion 07/07/2016 à 07:10:38 Connexion 287 / 605 07/07/2016 à 07:09:42 Déconnexion 07/07/2016 à 07:07:55 Connexion 3056 / 248 07/07/2016 à 07:07:25 Déconnexion 07/07/2016 à 07:07:12 Connexion 2264 / 214 07/07/2016 à 07:00:17 Déconnexion 07/07/2016 à 06:32:59 Connexion 2786 / 220 07/07/2016 à 06:29:23 Déconnexion 07/07/2016 à 06:29:00 Connexion 2252 / 230 07/07/2016 à 06:02:32 Déconnexion

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 :

[[inputs.exec]] commands = ["/etc/telegraf/scripts/download.py"] timeout = "10s" name_override = "download" data_format = "value" data_type = "integer" [[inputs.exec]] commands = ["/etc/telegraf/scripts/upload.py"] timeout = "10s" name_override = "upload" data_format = "value" data_type = "integer" 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 [[inputs.exec] ] commands = ["/etc/telegraf/scripts/download.py"] timeout = "10s" name_override = "download" data_format = "value" data_type = "integer" [[inputs.exec] ] commands = ["/etc/telegraf/scripts/upload.py"] timeout = "10s" name_override = "upload" data_format = "value" data_type = "integer"

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 :

> show measurements; name: measurements ------------------ name download upload > select * from download name: download -------------- time host value 1468147411000000000 Seboss666_Pi 2396 1468147426000000000 Seboss666_Pi 2396 1468147442000000000 Seboss666_Pi 2396 1468147456000000000 Seboss666_Pi 2396 1468147471000000000 Seboss666_Pi 2396 > select * from upload name: upload ------------ time host value 1468147411000000000 Seboss666_Pi 689 1468147426000000000 Seboss666_Pi 689 1468147442000000000 Seboss666_Pi 689 1468147456000000000 Seboss666_Pi 689 1468147471000000000 Seboss666_Pi 689 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 > show measurements; name: measurements ------------------ name download upload > select * from download name: download -------------- time host value 1468147411000000000 Seboss666_Pi 2396 1468147426000000000 Seboss666_Pi 2396 1468147442000000000 Seboss666_Pi 2396 1468147456000000000 Seboss666_Pi 2396 1468147471000000000 Seboss666_Pi 2396 > select * from upload name: upload ------------ time host value 1468147411000000000 Seboss666_Pi 689 1468147426000000000 Seboss666_Pi 689 1468147442000000000 Seboss666_Pi 689 1468147456000000000 Seboss666_Pi 689 1468147471000000000 Seboss666_Pi 689

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 :

#!/usr/bin/python # -*- coding: utf-8 -*- import urllib2 import re brut = urllib2.urlopen("http://mafreebox.freebox.fr/pub/fbx_info.txt") dlrate = re.search(".*ATM.*", brut.read()).group().split()[2] print dlrate 1 2 3 4 5 6 7 8 9 #!/usr/bin/python # -*- coding: utf-8 -*- import urllib2 import re brut = urllib2 . urlopen ( "http://mafreebox.freebox.fr/pub/fbx_info.txt" ) dlrate = re . search ( ".*ATM.*" , brut . read ( ) ) . group ( ) . split ( ) [ 2 ] print dlrate

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

#!/usr/bin/python # -*- coding: utf-8 -*- import urllib2 import re brut = urllib2.urlopen("http://mafreebox.freebox.fr/pub/fbx_info.txt") ulrate = re.search(".*ATM.*", brut.read()).group().split()[4] print ulrate 1 2 3 4 5 6 7 8 9 #!/usr/bin/python # -*- coding: utf-8 -*- import urllib2 import re brut = urllib2 . urlopen ( "http://mafreebox.freebox.fr/pub/fbx_info.txt" ) ulrate = re . search ( ".*ATM.*" , brut . read ( ) ) . group ( ) . split ( ) [ 4 ] print ulrate

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

$ telegraf -test -config /etc/telegraf/telegraf.conf -config-directory /etc/telegraf/telegraf.d * Plugin: exec, Collection 1 > download,host=Seboss666_Pi value=2396i 1468147209024691076 * Plugin: exec, Collection 1 > upload,host=Seboss666_Pi value=689i 1468147209903473597 1 2 3 4 5 $ telegraf - test - config / etc / telegraf / telegraf .conf - config - directory / etc / telegraf / telegraf .d * Plugin : exec , Collection 1 > download , host = Seboss666_Pi value = 2396i 1468147209024691076 * Plugin : exec , Collection 1 > upload , host = Seboss666_Pi value = 689i 1468147209903473597

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 :

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

Et 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.

Attention à 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 ? 😀