Aller au contenu

[TUTO] Monitoring de la Livebox4

oracle7

Par oracle7
dans Tutoriels

 Partager

Messages recommandés

oracle7 Grand Master

oracle7

Posté(e)
  • Auteur
Posté(e)

@MilesTEG1

Bonjour,

Si aucun panel n'affiche quoique ce soit, je pense que c'est un problème avec Grafana et en particulier avec la source de donnée indiquée pour chaque panel (edit panel et popup "Data source" dans l'entête juste avant la requête).

Vérifies, en principe cela devrait être "Livebox4_InfluxDB" (à moins que tu ne l'ai renommée) et ce n'est pas le script "livebox4.sh" qui est en cause car on voit bien qu'il écrit bien toutes tes données extraites de la LB4 dans la BD InfluxDB "livebox4_db".

Sinon, Quelle version du script utilises-tu ?

N'aurais-tu as changée l'@IP du conteneur InfluxDB (dans le network monitoring) sans mettre à jour le fichier "config.json" (§6.1 TUTO) pour le monitoring de la LB ?

Pour info je suis sous :

  • InfluxDB v1.8.10
  • telegraf v1.21.1
  • grafana v8.3.3

Cordialement

oracle7😉

0
Lien vers le commentaire
Partager sur d’autres sites
MilesTEG1 Veteran

MilesTEG1

Posté(e)
Posté(e)

@oracle7 Non seuls les panels dont j'ai mis la capture n'ont aucunes données. Les autres ont bien les données 🙂

Je vois que je vais pouvoir mettre telegraf à jour avec une version plus récente 🙂 .

edit : ha merde, non... ça me fait plein d'erreurs de permissions sur docker.sock... donc je vais rester sur la version 1.20.2... bon même avec la version la plus récente j'ai encore les données dans mes panels... du coup je peux rester avec cette dernière version... mais ça m'ennuie d'avoir ces erreurs de permissions...

Dans un des panels qui ne fonctionne pas, j'ai bien la bonne base de données :
kfAAf0w.png

 

En ce qui concerne la version du script, j'en sais rien en fait 😄  Mais dans le script c'est écrit : 

VERSION="1.0.1" # <version>.<revision majeure>.<revision mineure>
NOMPROG=`basename $0`
AUTEUR="oracle7"

Il y a plus récent ?

Pour l'adresse IP de influxDB, non, elle ne devrait pas avoir changée, mais je vais vérifier : à priori ça n'a pas changé 😉  à purée, si, enfin là avec la recréation des conteneurs suite à la MAJ de telegraf. Bon je modifie l'adresse IP dans le fichier de configuration.

(mais je suis sûr qu'avant mes manips de cette après-midi, l'IP n'avais pas changé...)

Bon en voulant exécuter à nouveau le script depuis le conteneur, j'ai cette erreur : 

telegraf@monitoring_telegraf_lb4:/opt/livebox4$ ./livebox4.sh 
Erreur : Le repertoire [ /opt/livebox4/data ] est inexistant et/ou n'a pas les droits d'ecriture suffisants.
telegraf@monitoring_telegraf_lb4:/opt/livebox4$ ls
config.json  data  data_json  livebox4.sh  log
telegraf@monitoring_telegraf_lb4:/opt/livebox4$ ls -la
total 116
drwxr-xr-x 1 1037 root      76 Mar 31  2021 .
drwxr-xr-x 1 root root      16 Dec 26 16:15 ..
-rwxr-xr-x 1 1037 users    232 Dec 26 16:11 config.json
drwxr-xr-x 1 1037 root     658 Mar  6  2021 data
drwxr-xr-x 1 1037 root     814 Mar  6  2021 data_json
-rwxr-xr-x 1 1026 users 111793 Mar 31  2021 livebox4.sh
drwxr-xr-x 1 1037 root     252 Dec 26 13:28 log

Le dossier est bien présent... Pour les permissions, je ne sais pas...

Qu'en penses-tu ?

edit : pour une raison que j'ignore, l'ID et le GUID mis dans le docker-compose ne correspondent pas à l'utilisateur qui a les permissions sur les dossiers...

Bon après recréation du conteneur avec les bonnes valeurs d'ID / GUID, (j'ai aussi vérifié les permissions dans DSM), mais j'ai toujours l'erreur au lancement du script : 

telegraf@monitoring_telegraf_lb4:/opt/livebox4$ ./livebox4.sh 
Erreur : Le repertoire [ /opt/livebox4/data ] est inexistant et/ou n'a pas les droits d'ecriture suffisants.

 

0
Lien vers le commentaire
Partager sur d’autres sites
oracle7 Grand Master

oracle7

Posté(e)
  • Auteur
Posté(e) (modifié)

@MilesTEG1

Bonjour,

il y a 52 minutes, MilesTEG1 a dit :

ça me fait plein d'erreurs de permissions sur docker.sock...

Sur le fichier "/var/run/docker.sock" j'ai les permissions "0666" pour "root/root".

Par rapport au TUTO dans le docker-compose.yml de telegraf_lb4 j'ai juste ajoutée cette ligne dans la partie "volumes:" : 

            - "/var/run/docker.sock:/var/run/docker.sock:ro"

Mon répertoire de montage dans le conteneur et correspondant à la ligne dans la partie "volumes:" : 

            - "/volume1/docker/livebox4:/opt/livebox4/"

a les droits "0775" pour "root/root".

Je vois que que tu n'as pas "joué" avec la rétention des données vu que tu es toujours en "autogen" contrairement à moi :

jxGp1a7.png

il y a 52 minutes, MilesTEG1 a dit :

Bon en voulant exécuter à nouveau le script depuis le conteneur, j'ai cette erreur :

...

Qu'en penses-tu ?

Pourquoi dans ton conteneur telegraf_lb4 tes fichiers config.json et livebox4.sh appartiennent-ils au group "users"  ? Moi j'ai ceci : 

root@monnas:~# docker exec -it telegraf_lb4 bash
I have no name!@telegraf_lb4:/$ cd /opt/livebox4/
I have no name!@telegraf_lb4:/opt/livebox4$ ls -al
total 116
drwxrwxrwx 1 root root     76 Jun 30 14:12 .
drwxr-xr-x 1 root root     16 Dec 23 01:31 ..
-rwxrwxrwx 1 root root    225 Mar  3  2021 config.json
drwxrwxrwx 1 root root    658 Mar  2  2021 data
drwxrwxrwx 1 root root    814 Mar  2  2021 data_json
-rwxrwxrwx 1 root root 113012 Jul  1 10:29 livebox4.sh
drwxrwxrwx 1 root root    252 Dec 26 13:00 log
I have no name!@telegraf_lb4:/opt/livebox4$

Le pourquoi de l'erreur est peut-être là, non ?

il y a 52 minutes, MilesTEG1 a dit :

Pour l'adresse IP de influxDB, non, elle ne devrait pas avoir changée, mais je vais vérifier : à priori ça n'a pas changé 😉  à purée, si, enfin là avec la recréation des conteneurs suite à la MAJ de telegraf. Bon je modifie l'adresse IP dans le fichier de configuration.

C'est pour éviter cela (changement @IP lors des recréations de conteneurs) que je leur donne à tous (mes services dans mes conteneurs) une @IP fixe : 

        networks:
            monitoring:
                ipv4_address: 172.20.0.6

dans mes fichiers docker-compose.yml (cf §3.2 du TUTO).

Cordialement

oracle7😉

Modifié par oracle7
0
Lien vers le commentaire
Partager sur d’autres sites
MilesTEG1 Veteran

MilesTEG1

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

Sur le fichier "/var/run/docker.sock" j'ai les permissions "0666" pour "root/root".

 

Comment on a la version chiffrée des permissions ?
un ls -la me donne ça : 

srw-rw---- 1 root root 0 Dec 23 14:01 /var/run/docker.sock

 

Il y a 5 heures, .Shad. a dit :

Et le dossier monté sur le NAS correspondant à /opt/livebox4/data dans le conteneur a les droits adéquats par rapport à l'utilisateur qui exécute le conteneur ?

Oui, mon user Monitoring a les droits et est le propriétaire du dossier /docker/monitoring/livebox4

Le conteneur a été fait avec l'ID de l'utilisateur Monitoring.

Il y a 4 heures, oracle7 a dit :

Par rapport au TUTO dans le docker-compose.yml de telegraf_lb4 j'ai juste ajoutée cette ligne dans la partie "volumes:" : 

            - "/var/run/docker.sock:/var/run/docker.sock:ro"

À quoi ça sert de mettre ça dans le docker-compose d telegraf de la livebox ?

 

Il y a 4 heures, oracle7 a dit :

Je vois que que tu n'as pas "joué" avec la rétention des données vu que tu es toujours en "autogen" contrairement à moi :

Autant je vois comment passer sur rétention, mais comment je fais pour avoir le choix de la durée ??

 

Il y a 4 heures, oracle7 a dit :

Pourquoi dans ton conteneur telegraf_lb4 tes fichiers config.json et livebox4.sh appartiennent-ils au group "users"  ? Moi j'ai ceci :

Bah je sais pas... Peut-être parce que j'ai mis en propriétaire l'user monitoring... 

root@Syno-DS920Plus:~# docker exec -it monitoring_telegraf_lb4 bash
telegraf@monitoring_telegraf_lb4:/$ cd /opt/livebox4/
telegraf@monitoring_telegraf_lb4:/opt/livebox4$ ls -la
total 116
drwxr-xr-x 1 1037 root      76 Mar 31  2021 .
drwxr-xr-x 1 root root      16 Dec 26 16:25 ..
-rwxr-xr-x 1 1037 users    232 Dec 26 16:11 config.json
drwxr-xr-x 1 1037 root     658 Mar  6  2021 data
drwxr-xr-x 1 1037 root     814 Mar  6  2021 data_json
-rwxr-xr-x 1 1037 users 111793 Mar 31  2021 livebox4.sh
drwxr-xr-x 1 1037 root     252 Dec 26 13:28 log

J'ai tenté depuis le conteneur de modifier les permissions, et ça veut pas :
  

telegraf@monitoring_telegraf_lb4:/opt/livebox4$ chown root root ./*
chown: cannot access 'root': No such file or directory
chown: changing ownership of './config.json': Operation not permitted
chown: changing ownership of './data': Operation not permitted
chown: changing ownership of './data_json': Operation not permitted
chown: changing ownership of './livebox4.sh': Operation not permitted
chown: changing ownership of './log': Operation not permitted

 

Il y a 4 heures, oracle7 a dit :

C'est pour éviter cela (changement @IP lors des recréations de conteneurs) que je leur donne à tous (mes services dans mes conteneurs) une @IP fixe : 

        networks:
            monitoring:
                ipv4_address: 172.20.0.6

dans mes fichiers docker-compose.yml (cf §3.2 du TUTO).

Je vais probablement fixer moi aussi les IP pour pas que ça se reproduise XD

0
Lien vers le commentaire
Partager sur d’autres sites
MilesTEG1 Veteran

MilesTEG1

Posté(e)
Posté(e)

_______________________________

Bon j'ai déplacé les dossiers dans un autre dossier au-cas où, et j'ai recréé les 3 dossiers data, data_json et log depuis la CLI en SSH sur le NAS. Puis j'ai resuivi le tuto et je me suis rendu compte que le script livebox4.sh devait être lancé depuis le NAS et pas depuis l'intérieur du conteneur... j'en ai profité pour mettre les ip en dur pour chaque conteneur de la stack monitoring, en modifiant le fichier de conf de telegraf pour l'instance livebox4.

Bref, j'ai pas mieux dans Grafana...

Par contre, si je change autogen par default, j'ai quelque chose :

giyPGp0.png

En passant les panels qui n'avaient aucune données en default plutôt que autogen, j'ai des données (pour les autres qui avaient déjà des données, ils étaient déjà sur default).
Par contre en regardant les données affichées en détail, j'ai tout en double :
bdu8ypT.png

0
Lien vers le commentaire
Partager sur d’autres sites
oracle7 Grand Master

oracle7

Posté(e)
  • Auteur
Posté(e)

@MilesTEG1

Bonjour,

Il y a 15 heures, MilesTEG1 a dit :

Comment on a la version chiffrée des permissions ?

Dans WinSCP --> Clicdroit sur le fichier/dossier --> Propriétés.

Sinon et c'est valable pour tout système basé sur UNIX : la valeur des droits en octal se détermine tel que :

R = 4, W= 2 et X=1

Droits étendus pour les répertoires : SUID bit = 4, SGID bit = 2 et Stiky bit = 1

Et en sommant les valeurs pour respectivement le répertoire, le propriétaire, le groupe et les Autres/Tous. C'est à dire par exemple :

  • Droits = 0755 se traduit en :
    Droits étendus = 0 soit pas d'SUID, pas de SGID, pas de Stiky bit
    Propriétaire = 7 soit RWX donc 4+2+1
    Groupes = 5 soit RX donc 4 + 1
    Autres = 5 soit RW donc 4 + 1
  • Droits 0666 se traduit en :
    Droits étendus     = 0 soit pas d'SUID, pas de SGID, pas de Stiky bit
    Propriétaire = 6 soit RW donc 4 + 2
    Groupes = 6 soit RW donc 4 + 2
    Autres = 6 soit RW donc 4 + 2

Dans le cas de ton fichier var/run/docker.sock tu as (vu ton ls- al) les droits : 1660 alors que moi j'ai : 0666.

Il y a 15 heures, MilesTEG1 a dit :

Autant je vois comment passer sur rétention, mais comment je fais pour avoir le choix de la durée ??

Là c'est toi qui défini la durée lorsque tu crées la rétention (par ex ici 2w soit 15jours) : 

CREATE RETENTION POLICY "Retention15j" ON "nas_telegraf" DURATION 2w REPLICATION 1 DEFAULT

 

Il y a 15 heures, MilesTEG1 a dit :

Bah je sais pas... Peut-être parce que j'ai mis en propriétaire l'user monitoring...

Je n'en vois pas l'intérêt, laisses l'user standard soit root et donc par de user à spécifier pour les services Influx_DB et et telegraf dans le docker-compose.yml. Seule exception c'est le service grafana où tu précises l'utilisateur qui affichera tes panels. Chez moi c'est tout simplement mon utilisateur avec droits d'admin : " user: "1030:101" ".

Il y a 15 heures, MilesTEG1 a dit :

J'ai tenté depuis le conteneur de modifier les permissions, et ça veut pas :

Sauf erreur de ma part, ces permissions sont en quelque sorte "figées" lors de la création du conteneur. Elles sont recopiées depuis le dossier à  monter et affectées au dossier monté dans le conteneur. Il est donc illusoire de vouloir les modifier que se soit dans le conteneur (après création) comme dans le dossier d'origine à monter car elles ne seront pas recopiée dans le conteneur existant.

Il y a 14 heures, MilesTEG1 a dit :

Par contre en regardant les données affichées en détail, j'ai tout en double :

Ceci est normal à partir du moment où tu lances le script "livebox4.sh" en manuel avec l'option "-e" d'exécution. Tu crées ainsi des données supplémentaires à chacune de ces exécutions manuelles qui sont de fait affichées dans le panel. De toutes façons, ce n'est pas gênant quand tu le sais 😋 Ces doublons disparaitront d'eux même après les exécutions normales (en automatique) du script.

Cordialement

oracle7😉

 

0
Lien vers le commentaire
Partager sur d’autres sites
MilesTEG1 Veteran

MilesTEG1

Posté(e)
Posté(e)
il y a 49 minutes, oracle7 a dit :

Dans WinSCP --> Clicdroit sur le fichier/dossier --> Propriétés.

Sinon et c'est valable pour tout système basé sur UNIX : la valeur des droits en octal se détermine tel que :

R = 4, W= 2 et X=1

Droits étendus pour les répertoires : SUID bit = 4, SGID bit = 2 et Stiky bit = 1

Et en sommant les valeurs pour respectivement le répertoire, le propriétaire, le groupe et les Autres/Tous. C'est à dire par exemple :

  • Droits = 0755 se traduit en :
    Droits étendus = 0 soit pas d'SUID, pas de SGID, pas de Stiky bit
    Propriétaire = 7 soit RWX donc 4+2+1
    Groupes = 5 soit RX donc 4 + 1
    Autres = 5 soit RW donc 4 + 1
  • Droits 0666 se traduit en :
    Droits étendus     = 0 soit pas d'SUID, pas de SGID, pas de Stiky bit
    Propriétaire = 6 soit RW donc 4 + 2
    Groupes = 6 soit RW donc 4 + 2
    Autres = 6 soit RW donc 4 + 2

Dans le cas de ton fichier var/run/docker.sock tu as (vu ton ls- al) les droits : 1660 alors que moi j'ai : 0666.

Ok ! merci pour ces explications 🙂

Et effectivement, avec WinSCP je vois le masque appliqué 🙂 

il y a 53 minutes, oracle7 a dit :

Là c'est toi qui défini la durée lorsque tu crées la rétention (par ex ici 2w soit 15jours) : 

CREATE RETENTION POLICY "Retention15j" ON "nas_telegraf" DURATION 2w REPLICATION 1 DEFAULT

Il est effectivement possible que j'ai défini une politique de rétention, mais ça remonte à quelques mois, je ne me souviens plus trop 😮 

Faut que je regarde ce que j'ai mis ^^ Et potentiellement changer le nom pour refléter vraiment la durée ^^

il y a 57 minutes, oracle7 a dit :

Je n'en vois pas l'intérêt, laisses l'user standard soit root et donc par de user à spécifier pour les services Influx_DB et et telegraf dans le docker-compose.yml. Seule exception c'est le service grafana où tu précises l'utilisateur qui affichera tes panels. Chez moi c'est tout simplement mon utilisateur avec droits d'admin : " user: "1030:101" ".

J'affecte toujours un utilisateur à un service Docker. Je crois que @.Shad. avait conseillé ça 🙂

il y a 59 minutes, oracle7 a dit :

Sauf erreur de ma part, ces permissions sont en quelque sorte "figées" lors de la création du conteneur. Elles sont recopiées depuis le dossier à  monter et affectées au dossier monté dans le conteneur. Il est donc illusoire de vouloir les modifier que se soit dans le conteneur (après création) comme dans le dossier d'origine à monter car elles ne seront pas recopiée dans le conteneur existant.

Ha Ok, donc faut recréer complètement le conteneur plutôt que juste le redémarrer 🙂

il y a une heure, oracle7 a dit :

Ceci est normal à partir du moment où tu lances le script "livebox4.sh" en manuel avec l'option "-e" d'exécution. Tu crées ainsi des données supplémentaires à chacune de ces exécutions manuelles qui sont de fait affichées dans le panel. De toutes façons, ce n'est pas gênant quand tu le sais 😋 Ces doublons disparaitront d'eux même après les exécutions normales (en automatique) du script.

Ok, nickel alors ^^

Je retente encore une fois en fixant la version de telegraf à 1.20.4, et en mettant le groupe sur docker.sock.

 

Sinon tu ne m'as pas dit pourquoi tu mettais docker.sock en accès de telegraf de la LB4 ?

 

0
Lien vers le commentaire
Partager sur d’autres sites
oracle7 Grand Master

oracle7

Posté(e)
  • Auteur
Posté(e)

@MilesTEG1

Bonjour,

il y a 8 minutes, MilesTEG1 a dit :

J'affecte toujours un utilisateur à un service Docker. Je crois que @.Shad. avait conseillé ça

Ah bon ? personnellement je ne me souviens pas de cette recommandation.

il y a 9 minutes, MilesTEG1 a dit :

Ha Ok, donc faut recréer complètement le conteneur plutôt que juste le redémarrer

De ce que j'ai compris, redémarrer un conteneur ne fait que repartir sur les paramètres donnés à sa création. Donc si tu modifies des infos en amont, il faut systématiquement créer le conteneur : down puis up -d.

il y a 12 minutes, MilesTEG1 a dit :

Sinon tu ne m'as pas dit pourquoi tu mettais docker.sock en accès de telegraf de la LB4 ?

J'avais zappé désolé et tout simplement maintenant je dirais parce que je ne sais plus, alors plutôt que dire ces c...ies quant à sa présence ... En attendant cette ligne ne me gêne pas, alors elle reste jusqu'à ce qu'on me dise de façon argumentée qu'elle est inutile.

Cordialement

oracle7😉

 

0
Lien vers le commentaire
Partager sur d’autres sites

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.

×
 Partager
Aller sur la liste des sujets
×
×
  • 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.