Aller au contenu

Messages recommandés

Posté(e)

Bonjour, @christophebe,

heureux que tu ais pu t'en sortir.

Effectivement, le :ro sur le répertoire ./py doit être enlevé au moins au moment de faire l'activation. Ensuite on peut le remettre. Je dois enfin recevoir une nouvelle Fbox fonctionnelle semaine prochaine. Je ferais alors les corrections nécessaires dans le script et le tuto pour prendre en compte les différentes remarques ( 1) "a" vs "ab" pour le register, 2) corrections pour les données xDSL, 3) correction :ro sur le dossier ./py)

Posté(e)

Bonjour @bruno78

De retour, j'ai repris le tuto et suis arrivé au bout en supprimant :ro 

J'ai bien l'accessibilité aux données dans le docker fbx_telegraf et influxdb et reçoit bien les données de telegraf et fbx_telegraf (je le vois dans le journal car je ne sais pas utiliser le terminal qui affiche no socket).

Par contre lorsque je crée un dashboard après avoir créé la nouvelle source de donnée, il m'est impossible d'accéder aux données de la freebox. Idem en utilisant tes fichiers .jason. J'ai "no data" dans toutes les vues.

Je suis en ADSL+ et la Freebox est en mode routeur avec un routeur en DMZ. Quel est le fichier que je dois utiliser ?

C'est bête d'échouer si près du but 😊

Posté(e)

Bonjour @Jeff777,

je reçois ma nouvelle Fbox en fin de journée théoriquement :-). Je vais pouvoir commencer à regarder.

Est-ce que ta source de données a été bien créée ? je suppose que oui mais bon ....

image.png.53155984cff9b8864625577969fd8a7b.png

Peux-tu stp faire une copie du journal si tu y vois des données ? surtout une copie des message du terminal ou du journal influxdb si possible

Bruno78

Posté(e)

Oui la source de donnée est crée et j'ai la même chose que toi concernant ta capture d'écran.

Curieusement  les données du journal influxdb disparaissent. J'ai été obligé de redémarrer le conteneur pour les voir :

Capture2.thumb.JPG.63355aca487db0b02c7f7d9876fdb435.JPG

Dans le terminal toujours la même notification :

Capture.JPG.63aac751875debe29078535977537af1.JPG

 

 

Posté(e) (modifié)

OK donc oui fbx_telegraf envoie bien des données vers influxdb toutes les 10 secondes. Par contre est-ce que fbx_telegraf récupère bien des données depuis le Fbox ? Quelque chose du côté du terminal ou du journal fbx_telegraf ?

Et du coup, depuis l'interface web grafana, tu obtiens bien les graphes du nas, mais pas ceux de la fbox ?

Peux-tu me monter un exemple de requête avec "nodata" ?

Peux-tu faire un aperçu de schéma réseau ?

 

Modifié par bruno78
Posté(e) (modifié)
il y a 52 minutes, bruno78 a dit :

Quelque chose du côté du terminal ou du journal fbx_telegraf ?

oui quelque chose :

Capture.thumb.JPG.86b187dff84b9a42eb995688c70df013.JPG

il y a 52 minutes, bruno78 a dit :

tu obtiens bien les graphes du nas, mais pas ceux de la fbox ?

Oui j'ai bien un graphe pour le NAS (J'ai fait un capture d'écran dans le tuto de Shad]

il y a 52 minutes, bruno78 a dit :

Peux-tu me monter un exemple de requête avec "nodata" ?

Edition du panneau firmware (les autres panneaux ont les réponses no data ou no data to show) :

Capture2.thumb.JPG.6a24068b63a6bb789dfb11f135a06ae1.JPG

 

Sinon dans le journal grafana j'ai ceci :

 

grafana                                                        
date,stream,content                                                      
2020-05-07 08:30:12,stdout,t=2020-05-07T08:30:12+0000 lvl=info msg="Request Completed" logger=context userId=1 orgId=1 uname=admin method=GET path=/api/dashboards/uid/V1x7Ot_Wk status=404 remote_addr=172.18.0.1 time_ms=106 size=33 referer=http://192.168.1.10:3000/dashboard/import          
                                                         
2020-05-07 08:30:12,stdout,t=2020-05-07T08:30:12+0000 lvl=eror msg="Dashboard not found" logger=context userId=1 orgId=1 uname=admin error="Dashboard not found" remote_addr=172.18.0.1                            
                                                         
2020-05-07 07:51:01,stdout,t=2020-05-07T07:51:01+0000 lvl=info msg="Request Completed" logger=context userId=1 orgId=1 uname=admin method=GET path=/api/datasources/proxy/1/query status=502 remote_addr=172.18.0.1 time_ms=5 size=0 referer="http://192.168.1.10:3000/d/-l-tGE3Zz/mondashboard?orgId=1&refresh=1m"      
                                                         
2020-05-07 07:51:01,stdout,t=2020-05-07T07:51:01+0000 lvl=eror msg="Data proxy error" logger=data-proxy-log userId=1 orgId=1 uname=admin path=/api/datasources/proxy/1/query remote_addr=172.18.0.1 referer="http://192.168.1.10:3000/d/-l-tGE3Zz/mondashboard?orgId=1&refresh=1m" error="http: proxy error: dial tcp 172.18.0.5:8086: connect: connection refused"
                                                         
2020-05-07 07:51:01,stdout,t=2020-05-07T07:51:01+0000 lvl=info msg="Request Completed" logger=context userId=1 orgId=1 uname=admin method=GET path=/api/datasources/proxy/1/query status=502 remote_addr=172.18.0.1 time_ms=4 size=0 referer="http://192.168.1.10:3000/d/-l-tGE3Zz/mondashboard?orgId=1&refresh=1m"      
                                                         
2020-05-07 07:51:01,stdout,t=2020-05-07T07:51:01+0000 lvl=eror msg="Data proxy error" logger=data-proxy-log userId=1 orgId=1 uname=admin path=/api/datasources/proxy/1/query remote_addr=172.18.0.1 referer="http://192.168.1.10:3000/d/-l-tGE3Zz/mondashboard?orgId=1&refresh=1m" error="http: proxy error: dial tcp 172.18.0.5:8086: connect: connection refused"
                                                         
2020-05-07 07:51:01,stdout,t=2020-05-07T07:51:01+0000 lvl=info msg="Request Completed" logger=context userId=1 orgId=1 uname=admin method=GET path=/api/datasources/proxy/1/query status=502 remote_addr=172.18.0.1 time_ms=6 size=0 referer="http://192.168.1.10:3000/d/-l-tGE3Zz/mondashboard?orgId=1&refresh=1m"      
                                                         
2020-05-07 07:51:01,stdout,t=2020-05-07T07:51:01+0000 lvl=eror msg="Data proxy error" logger=data-proxy-log userId=1 orgId=1 uname=admin path=/api/datasources/proxy/1/query remote_addr=172.18.0.1 referer="http://192.168.1.10:3000/d/-l-tGE3Zz/mondashboard?orgId=1&refresh=1m" error="http: proxy error: dial tcp 172.18.0.5:8086: connect: connection refused"
                                                         
2020-05-07 07:51:01,stdout,t=2020-05-07T07:51:01+0000 lvl=info msg="Request Completed" logger=context userId=1 orgId=1 uname=admin method=GET path=/api/datasources/proxy/1/query status=502 remote_addr=172.18.0.1 time_ms=6 size=0 referer="http://192.168.1.10:3000/d/-l-tGE3Zz/mondashboard?orgId=1&refresh=1m"      

 

Edit : J'ai un décalage de 2h sur tous les journaux docker. Je ne sais pas d'où cela vient.

Modifié par Jeff777
Posté(e) (modifié)

Salut,

@Jeff777 Tu peux essayer de te connecter en SSH sur le conteneur influx db et vérifier si la base de données est bien peuplée :

sudo docker exec -it <nom_du_conteneur_influxdb> influx -username <utilisateur_admin> -password <mot_de_passe_admin>

Puis :

USE fbx_telegraf
SHOW MEASUREMENTS

Tu devrais voir la liste des champs qu'on retrouve dans Grafana.
D'après les logs de ton conteneur fbx_telegraf, il y a une erreur au niveau de l'exécution du script et qui l'arrête de manière inopinée (exit code 1).

Si tu ne vois rien c'est qu'il y a un problème entre Telegraf et InfluxDB.

D'ailleurs remarque à @bruno78 également, on peut tout à fait utiliser le même conteneur telegraf que pour le NAS ou que ce soit d'autres. De manière générale j'essaie de mettre une instance telegraf par machine, mais là vu que le conteneur n'est pas directement hébergé sur la Freebox, on passe par une autre machine (ici le NAS), autant centraliser dans le même conteneur.

De ta dernière impression d'écran, il semble y avoir également un souci de communication entre Grafana et la datasource InfluxDB pour ta Freebox.

Est-ce que 172.18.0.5 est l'adresse IP de ton conteneur InfluxDB ?

EDIT : tes conteneurs doivent se baser sur l'heure UTC par défaut, c'est mon cas aussi d'ailleurs :

Capture.png

On peut régler ça je pense en montant dans les volumes de telegraf :

/etc/localtime:/etc/localtime:ro

 

Modifié par .Shad.
Posté(e)

Voilà ce que j'ai :

Capture.JPG.02c88240269997027e99da901b0cd8f2.JPG

il y a 49 minutes, .Shad. a dit :

Est-ce que 172.18.0.5 est l'adresse IP de ton conteneur InfluxDB ?

Euh...je ne sais pas où trouver l'info.

J'ai ceci. Et si je vais dans gérer je n'ai pas plus d'info :

Capture2.JPG.ff3c31f5bb9bc25e946de7d2083ce7a8.JPG

Ok pour l'heure. Je vais corriger

Posté(e)
Il y a 4 heures, Jeff777 a dit :

Euh...je ne sais pas où trouver l'info.

En SSH tu peux faire :

docker inspect <nom_du_conteneur>

Plutôt à la fin du fichier tu auras un champ IP_address :

Capture.png

Sinon tu as des interfaces comme portainer qui sont vraiment top pour avoir une vue d'ensemble de son système :

Capture2.png

Posté(e)

@Jeff777, @.Shad.,

passé ma matiné à remettre en ordre et reconfigurer ma nouvelle Fbox .... . Je remets en route fbx_telegraf, et je tombe sur un pb qui ressemble fort à ce que rencontre @Jeff777. Chez moi ce n'est pas systématique, j'ai des données de temps en temps, et parfois je n'en ai pas .... Je plonge dans le code Python .... je vous tiens au courant.

 

Posté(e) (modifié)

Bon alors voilà ce que j'ai constaté chez moi :

  • même messages d'erreur que @Jeff777 dans le journal,
  • ayant re-installé la nouvelle FBox, j'ai anticipé avant de tout rebranché et j'ai rentré les baux DHCP statiques pour être sûr de retrouver mon adressage .... Mauvaise idée.
  • dans ce cas, tant que la station concernée ne s'est pas connectée au moins 1 fois, le champ "host" de l'API reste vide, même si on a donné un nom à la station. Et dans ce cas le script python plante (le champ 'host' n'existe pas, il aurait été vide il n'y aurait pas eu de problème !), il n'y a pas de test.
  • Donc dans l'immédiat, je suggère de vérifier sur la Fbox, dans la table DHCP des baux statiques (pas celle des baux actifs) si il y a des entrées pour lesquelles il n'y a pas de nom : Il s'agit de la colonne de gauche. Par exemple ici on aurait
00:00:48:0F:1B:BD

00:00:48:0F:1B:BD
192.168.1.19
  • au lieu de lorsque la station a été connectée au moins une fois, alors on peut lui rentrer un nom, et là il n'y a plus de problème :
Epson Laser

00:00:48:0F:1B:BD
192.168.1.19

 

image.thumb.png.5c0a20f1d9bdf593e563aba5d59b89f6.png

 

Est-ce que cela correspond à votre cas ?

De mon côté je vais voir à intégrer un test dans le script pour ne plus tomber dans ce cas , en espérant que c'est la même chose chez vous.

Bruno78

Modifié par bruno78
Précisions
Posté(e)
il y a une heure, .Shad. a dit :

docker inspect <nom_du_conteneur>

Pour influxdb je trouve 172.18.0.4

Capture.JPG.fa8b60c7411822996c9377775136cc54.JPG

172.18.0.5 est l'IP de fbx_telegraf

Capture2.JPG.4ac5e4db3023ce266565b9631d32f900.JPG

il y a une heure, .Shad. a dit :

Sinon tu as des interfaces comme portainer

Oui j'ai vu cela et c'est dans ma "to do list" 😉

il y a une heure, bruno78 a dit :

je tombe sur un pb qui ressemble fort à ce que rencontre @Jeff777

Je ne suis donc pas seul comme disais Jacques BREL 😅

Posté(e)

@Jeff777

On peut en tout cas constater que dans la base de donnée nas_telegraf le measurement lié au script n'est pas repris, on a seulement ceux relevés par défaut par Telegraf (cpu, mem, etc...).
Du coup au vu des IP de tes conteneurs, je ne comprends pas bien pourquoi Grafana fait référence dans ses logs à 172.18.0.5, qui est l'IP du conteneur Telegraf. Les deux ne sont pas sensés communiquer, Telegraf alimente InfluxDB et Grafana accède aux données qui y sont stockées.

Normalement il te faut quelque chose ainsi, je reprends l'impression d'écran de mon tutoriel :

grafana_nas_datasource.thumb.PNG.d5b1b8f4c4b6cc7a261dbb3f74748bfd.PNG

Mais évidemment à la place de nas_telegraf ça doit être fbx_telegraf, est-ce que cette datasource est validée (message vert en bas de page) dans ta configuration ?

Posté(e) (modifié)
il y a 20 minutes, .Shad. a dit :

Mais évidemment à la place de nas_telegraf ça doit être fbx_telegraf

Capture.thumb.JPG.3cec9d392ef23cdb95ce0466594f9f22.JPG

Même résultat pour nas_telegraf et fbx_telegraf

il y a 33 minutes, bruno78 a dit :

Est-ce que cela correspond à votre cas ?

Ma freebox est en mode router avec seulement le player et le routeur ubiquiti connectés dessus.

Ils ont tout deux des baux statiques (192.168.0.1 pour le routeur et 192.168.0.12 pour le player) il y a aussi le téléphone de mon fils qui est connecté en WIFI et qui n'a pas de bail fixe.

Tous les autres périphériques dont les NAS sont sur le réseau de l'ubiquiti  (192.168.1.0/64) la plupart tous (dont les NAS) ont des baux fixes 

Modifié par Jeff777
Posté(e)

OK, donc sur ta freebox tu n'as aucun bail statique pour lequel le nom ne soit pas renseigné ?

Et du coup, le Wifi est'il activé sur la Fbox ? si tel n'est pas le cas, il faut remplacer "python3 freebox_050.py -SPHDIWX" par "python3 freebox_050.py -SPHDIX" dans le fichier telegraf.conf du docker fbx_telegraf. C'est à dire enlever le "W" qui demande des stats Wifi .... qui n'existent peut-être pas ? (encore un test qu'il faut que je rajoute dans le script python !)

Posté(e) (modifié)
il y a 25 minutes, bruno78 a dit :

OK, donc sur ta freebox tu n'as aucun bail statique pour lequel le nom ne soit pas renseigné ?

Tous les noms sont renseignés.

J'ai supprimé les baux statiques qui ne me servent plus.

J'ai redémarré le NAS et  la box pour voir.

Aucun changement sur les dashboards

 

 

il y a 25 minutes, bruno78 a dit :

Et du coup, le Wifi est'il activé sur la Fbox

Oui il l'est et j'ai un bail non statique sur le WIFI. Un des avantages de ne pas mettre la box en bridge c'est de conserver le WIFI.

Modifié par Jeff777
Posté(e) (modifié)

Si je fais mon propre dashboard,  j'arrive a voir des données mais je ne vois rien qui ressemble aux données des dashboards de @bruno78

Capture.JPG.e7b026985c71ee2860f37a2ea31c7095.JPG

il y a une heure, .Shad. a dit :

On peut en tout cas constater que dans la base de donnée nas_telegraf le measurement lié au script n'est pas repris,

@.Shad. tu voulais dire fbx_telegraf ?

Mais ma Freebox et mon NAS ne sont pas dans le même LAN c'est peut-être pour cela !

 

 

Modifié par Jeff777
Posté(e)

là c'est le cpu du docker fbx_telegraf que tu vas tracer.

Il faut sélectionner d'abord  FROM default  freebox , puis WHERE tag1 = (choisir dans la liste)  ....

image.png.7f8e28d7fea098531aaaecd2c9e83f1d.png

Posté(e) (modifié)

Oui mais je n'ai pas la liste déroulante même si je remplie les cases avec  freebox et tag1

Modifié par Jeff777
Posté(e)

Bonjour,

petite question à @Jeff777 au passage: en remontant l'historique, je me rends compte que tu as surement dû faire des docker-compose up -d depuis la customisation du docker ? Est-ce qu'à chaque fois tu as refais ensuite cette customisation ?

    docker exec -it fbx_telegraf apt update
    docker exec -it fbx_telegraf apt upgrade
    docker exec -it fbx_telegraf apt install -y software-properties-common
    docker exec -it fbx_telegraf wget https://bootstrap.pypa.io/get-pip.py
    docker exec -it fbx_telegraf python3 get-pip.py --prefix=/usr/local
    docker exec -it fbx_telegraf python3 -m pip install requests

 

En faisant depuis le ssh de ton NAS un docker exec -it fbx_telegraf python3 -V, tu verras vite si python est toujours là ou pas. Si il n'y a plus de python, alors cela confirme qu'il faut bien refaire la custo.

docker exec -it fbx_telegraf python3 -V
    Python 3.5.3

 

A priori je ne pense que ce soit un problème de communication entre la Fbox et fbx_telegraf puisque tu as réussi à faire l'association avec la Fbox.

Bruno78

Posté(e) (modifié)

Bonjour @bruno78

A priori ce n'est pas cela le pb 😞

Capture.JPG.fdbc246fb23785b4a57af3f2ffb8001c.JPG

 

Je vais recommencer du début. Quel fichier dois-je prendre freebox_50 51 ou 52 ?

Modifié par Jeff777
Posté(e)

Heu .... la je commence à sécher !

Prends le 052, sans oublier de corriger la ligne concernant la correction de l'authentification :  write_auth => with open(cfg_file, "a") as authFile ("a" au lieu de "ab") (ce sera corrigé dans la prochaine version)

En regardant ton log grafana, je vois cette ligne récurrente (1 sur 2) :

2020-05-07 07:51:01,stdout,t=2020-05-07T07:51:01+0000 lvl=eror msg="Data proxy error" logger=data-proxy-log userId=1 orgId=1 uname=admin path=/api/datasources/proxy/1/query remote_addr=172.18.0.1 referer="http://192.168.1.10:3000/d/-l-tGE3Zz/mondashboard?orgId=1&refresh=1m" error="http: proxy error: dial tcp 172.18.0.5:8086: connect: connection refused"

Un problème de mot de passe quelque part ?

Posté(e)
Il y a 12 heures, Jeff777 a dit :

tu voulais dire fbx_telegraf ?

Oui en effet, coquille.

@bruno78 Oui c'est ce que je notais plus haut, je ne vois pas ce que l'IP de Telegraf vient faire au niveau des logs de Grafana. Cependant sur l'impression d'écran où je lui demande d'afficher les measurements dans InfluxDB qu'il arrive à récolter les données par défaut liées au cpu, mem, etc... donc la liaison est bien établie entre Telegraf et InfluxDB. Et a priori il a aussi configuré correctement la datasource dans Grafana...

Et l'erreur des logs de Grafana correspond généralement à l'erreur qu'on a lorsqu'on valide une datasource, lui il a le message Datasource working.

Posté(e)
il y a 44 minutes, bruno78 a dit :

En regardant ton log grafana, je vois cette ligne récurrente (1 sur 2) :

oui j'ai vu cela mais cela concerne "mondashboard" celui issu du tuto de @.Shad. Et curieusement je n'ai aucun problème avec celui là.

Rejoindre la conversation

Vous pouvez publier maintenant et vous inscrire plus tard. Si vous avez un compte, connectez-vous maintenant pour publier avec votre compte.

Invité
Répondre à ce sujet…

×   Collé en tant que texte enrichi.   Coller en tant que texte brut à la place

  Seulement 75 émoticônes maximum sont autorisées.

×   Votre lien a été automatiquement intégré.   Afficher plutôt comme un lien

×   Votre contenu précédent a été rétabli.   Vider l’éditeur

×   Vous ne pouvez pas directement coller des images. Envoyez-les depuis votre ordinateur ou insérez-les depuis une URL.

×
×
  • Créer...

Information importante

Nous avons placé des cookies sur votre appareil pour aider à améliorer ce site. Vous pouvez choisir d’ajuster vos paramètres de cookie, sinon nous supposerons que vous êtes d’accord pour continuer.