[TUTO] Monitoring réseau (Telegraf + InfluxDB 1.8 + Grafana)

oracle7 · le 27 décembre 2021

Bonjour,

Comme sur tout forum, il est d'usage que les nouveaux membres passent par la rubrique [PRESENTATION] pour faire la leur. Certains ici, y sont sensibles et de plus cela facilite les réponses en fonction du niveau de compétences du membre et de ses équipements. Cela dit, rassures-toi il n'est pas trop tard pour bien faire ...
il y a 14 minutes, pateretwo a dit :

user: 1027:65536

Tu peux préciser STP ? c'est un utilisateur du groupe docker ?
"777" sur quoi ?
il y a 16 minutes, pateretwo a dit :

- /volume1/docker/grafana/config/grafana.ini:/etc/grafana/grafana.ini

OK pourquoi pas, mais qu'as-tu mis exactement des ce fichier "grafana.ini" ? C'est juste par curiosité ...

Cordialement

oracle7😉

.Shad. · le 27 décembre 2021

il y a 29 minutes, pateretwo a dit :

pour grafana pourquoi ne pas faire un

user: 1027:65536

ce qui est moins moche que le 777

Alors dans l'absolu ça peut marcher effectivement, le souci que tu peux rencontrer c'est qu'en faisant ça, littéralement c'est un utilisateur 1027:65536 qui va exécuter Grafana à l'intérieur du conteneur.

Si un script ou une commande avait par exemple pour permissions :

-rwxr-xr-- root root script.sh

Tu serais incapable de l'exécuter.

Par contre, Telegraf a été récemment mis à jour pour être exécuté avec un utilisateur non-root, du coup tu peux être certain que l'image va gérer les permissions comme il faut, et que par exemple 1027:65536 sera capable de faire ce qu'il a à faire au sein du conteneur.

A ma connaissance, Grafana s'exécute par défaut avec l'utilisateur root.

Modifié le 27 décembre 2021 par .Shad.

pateretwo · le 27 décembre 2021

Il y a 7 heures, oracle7 a dit :

Bonjour,

Comme sur tout forum, il est d'usage que les nouveaux membres passent par la rubrique [PRESENTATION] pour faire la leur. Certains ici, y sont sensibles et de plus cela facilite les réponses en fonction du niveau de compétences du membre et de ses équipements. Cela dit, rassures-toi il n'est pas trop tard pour bien faire ...

oui pardon j'etais dans le feu de l'action je n'ai pas pris le temps. Mais j'ai deja du me presenter avec un autre pseudo dont j'ai perdu le mdp et qu'apres 3 essais le forum m'a bloqué ca me saoulait d'attendre 1h pour pouvoir en reessayer un.

Il y a 7 heures, oracle7 a dit :

Tu peux préciser STP ? c'est un utilisateur du groupe docker ?

oui tout a fait a mettre dans le docker-compose comme pour influx

Il y a 7 heures, oracle7 a dit :

"777" sur quoi ?

dans le tutorial Shad met le repertoire data de grafana en 777 ce qui personnellement ne me plait pas trop donc j'ai essayé de trouver pq on devait faire ça

Il y a 7 heures, oracle7 a dit :

OK pourquoi pas, mais qu'as-tu mis exactement des ce fichier "grafana.ini" ? C'est juste par curiosité ...

la perso j'ai juste mis ma conf SMTP mais je n'ai pas regardé en detail ce qu'on pouvait modifier encore mais je pense qu'il y a pas mal de choses.

De maniere generale je ne laisse pas un fichier de conf dans le container je prefere toujours le sortir, c'est plus propre.

Il y a 7 heures, .Shad. a dit :
Si un script ou une commande avait par exemple pour permissions :
-rwxr-xr-- root root script.sh
Tu serais incapable de l'exécuter.

c'est pas faux. ce 777 me chiffonait

je trouve que le docker de grafana est un peu crado 😕

Jeff777 · le 28 décembre 2021

Il y a 21 heures, oracle7 a dit :
INFLUXDB_DB=nas_telegraf

Bonjour @oracle7,

C'est normal que influxdb fasse appel à "nas_telegraf" et que dans la suite du docker-compose tu as "telegraf" ??

Modifié le 28 décembre 2021 par Jeff777

oracle7 · le 28 décembre 2021

@Jeff777

Bonjour,

il y a 25 minutes, Jeff777 a dit :

C'est normal que influxdb fasse appel à "nas_telegraf" et que dans la suite du docker-compose tu as "telegraf" ??

Je crains que tu n'ais lu trop vite mon fichier docker-compose 🤪 Peut-être un peu de fatigue après les fêtes ?🤣

Dans la partie InfluxDB (environnement) on désigne la base de donnée "INFLUXDB_DB" à utiliser et qui est nommée "nas_telegraf".

Ensuite c'est la partie liée au conteneur telegraf.

Cordialement

oracle7😉

Jeff777 · le 28 décembre 2021

il y a 20 minutes, oracle7 a dit :

Peut-être un peu de fatigue après les fêtes ?

non je suis tout simplement pas au top en docker-compose😳 .

Par contre je note que tu es toujours en DSM6.2 et que @.Shad. et moi sommes en DSM7. C'est peut-être cela le problème.

oracle7 · le 28 décembre 2021

@Jeff777

Bonjour,

il y a 45 minutes, Jeff777 a dit :

C'est peut-être cela le problème.

Franchement je n'en suis pas convaincu et je ne vois pas pourquoi cela serait lié à la version de DSM : il y a quand même une certaine continuité et ce n'est pas une régression volontaire qu'aurait introduit Synology, non ?, mais l'avenir me fera ou pas revoir la chose ... Wait and see ...

Cordialement

oracle7😉

Dimebag Darrell · le 30 décembre 2021

Bonjour tout le monde,

Pour ma part, je suis tjs dans ces versions
1.8.5 : influxdb
1.18.1 : telegraf

Je n'ai pas fait de mise à jour des versions, est-ce nécessaire ?

Belle journée à tout le monde

oracle7 · le 30 décembre 2021

@Dimebag Darrell

Bonjour,

Je suis toujours sous DSM6 avec :

InfluxDB 1.8.10
Telegraf 1.21.1
grafana 8.3.3

Et je n'ai aucun soucis. Maintenant c'est toi qui voit ...

Cordialement

oracle7😉

Dimebag Darrell · le 30 décembre 2021

@oracle7
Merci pour l'info, de mon coté, je n'ai aucun problème, simplement est ce que ça vaut la peine de faire les dernières mise à jour ?

.Shad. · le 30 décembre 2021

Pas spécialement besoin, surtout si n'ouvres pas ta stack vers l'extérieur.

Dimebag Darrell · le 30 décembre 2021

en effet, il reste uniquement accessible en interne

.Shad. · le 6 janvier 2022

J'ai ajouté les remarques de @oracle7 concernant l'inputs.docker
Pour Telegraf, voici le sujet qui traite des panic au niveau du parsing de MIB : https://github.com/influxdata/telegraf/issues/10290

J'ai testé la 1.21.2 toute fraîche, pour moi ça ne fonctionne toujours pas. Je reste en 1.20.4 en attendant.

@oracle7 : Concernant ceci dans ton docker-compose :

Plus précisément :

- "/volume1/docker/mibs/:/usr/share/snmp/mibs:ro"

Qui est propriétaire des mibs que tu as copié dans le dossier ? root:root ?
Le changement d'utilisateur (non-root vs root) depuis la 1.20.3 pourrait expliquer un permission denied que j'ai vu passer dans les logs, entre autres erreurs.

Encore que les mibs sont rw-r--r--, donc aucun problème pour lire les fichiers normalement...

MilesTEG1 · le 6 janvier 2022

Moi j'ai vu ça apparaitre dans le log de telegraf :

2022-01-06T03:29:45Z E! [inputs.docker] Error in plugin: error getting docker stats: Get "http://%2Fvar%2Frun%2Fdocker.sock/v1.21/containers/a463a9f31984857ddc9dec630d2ce3cc96ac9229187f851ecca9068443e4b066/stats?stream=0": context deadline exceeded

Une idée de ce que ça signifie ?

oracle7 · le 6 janvier 2022

@.Shad.

Bonjour,

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

Qui est propriétaire des mibs que tu as copié dans le dossier ? root:root ?

OUI root:root. J'ai recopié toutes les MIBs Synology dans ce répertoire

/volume1/docker/mibs/

afin d'y adjoindre les miennes (caméras HIK) sans problèmes (on en a déjà discuté). Ok, après une mise à jour DSM il faudra recommencer mais pas grave. Pour l'instant cela marche bien comme cela.🤗

Cordialement

oracle7😉

MilesTEG1 · le 19 janvier 2022

Le 27/12/2021 à 13:20, MilesTEG1 a dit :

Ok, merci pour les précisions.
Du coup je vais tenter la modification du groupe sur docker.sock.
Pour récapituler, mon groupe User-Docker à les droits d'accès sur le dossier docker, et sur un ou deux autres dossiers (pour Plex). Mes utilisateurs docker appartiennent à ce groupe docker.

Si je modifie le groupe de docker.sock, ça ne va pas engendrer de problème de sécurité ?

Le 27/12/2021 à 08:33, .Shad. a dit :
J'aurai du mal à te dire si j'ai créé ou pas ce groupe docker, je n'ai jamais remis à zéro mes NAS donc ça remonte à 2017.
Tu peux vérifier via :
cat /etc/group | grep docker
Autrement, contrairement à @oracle7 et pareillement à @Jeff777, mon conteneur telegraf ne fonctionne pas en 1.21.1, j'ai une panic error runtime, le problème que j'avais trouvé sur Github date d'il y a un an. Je vais essayer de voir de la semaine ce qui cloche, si tu pouvais mettre ton fichier compose @oracle7 pour voir s'il y a des divergences qui pourraient induire cette différence de comportement.

Bonjour,

En allant voir Grafana, je constate que les infos Docker ne sont plus présentes...
Je vais voir le log de telegraf, et à nouveau l'erreur de permissions... Hmmm, je pensais avoir fait le changement de permissions... enfin de groupe...
Je regarde et j'ai ceci :

srw-rw---- 1 root root   0 Jan 11 10:06 /var/run/docker.sock

C'est redevenu comme avant...
Et là je me souviens que j'ai fait deux MAJ de DSM, dont une qui a rebooté le NAS...

#!/bin/bash

# Script de modification du groupe sur /var/run/docker.sock
# Pour avoir le groupe Docker afin que telegraf fonctionne correctement

# Startup Script
echo -e "\n$(date "+%R:%S -") Script de modification du groupe sur /var/run/docker.sock"
echo -e "$(date "+%R:%S -") Lancement de la commande : sudo chown root:Docker-Users /var/run/docker.sock\n"

sudo chown root:Docker-Users /var/run/docker.sock

echo -e "Les permissions sont donc :\n\t$(ll /var/run/docker.sock)\n"
echo -e "$(date "+%R:%S -") Script terminé\n"

exit 0

Ok, faut que je fasse un script à lancer au démarrage pour changer le groupe du docker.sock...

Modifié le 19 janvier 2022 par MilesTEG1
Correction d'un bug dans le script

oracle7 · le 19 janvier 2022

@MilesTEG1

Bonjour,

Mon docker-compose est dans une de mes réponses en page 47 du présent post.

De mon coté mon fichier /var/run/docker.sock n'a pas bougé suite à la mise à jour Udp3 de DSM6 et j'ai toujours les droits suivants (0666) :

oracle7@MonNas:/var/run$ ll doc*
-rw-r--r-- 1 root root   5 Oct  6 15:42 docker.pid
srw-rw-rw- 1 root root   0 Oct  6 15:42 docker.sock

Et je n'ai jamais fait d'affectation de ce fichier au groupe docker comme je n'ai pas plus affectés les fichiers dard0 et renderD128 au groupe docker ????? Quelle utilité ?????

oracle7@MonNas:/dev/dri$ ll
total 0
drwxr-xr-x  2 root root       80 Oct  6 15:41 .
drwxr-xr-x 13 root root    19040 Oct  6 15:42 ..
crw-------  1 root root 226,   0 Oct  6 15:41 card0
crw-------  1 root root 226, 128 Oct  6 15:41 renderD128

Cordialement

oracle7😉

MilesTEG1 · le 19 janvier 2022

@oracle7 Et bien de mon coté, sans ce changement de groupe, Telegraf m'affiche des erreurs de permissions denied sur docker.sock, voir la page précédente.

PS : je suis en DSM7, je crois que tu es encore en 6.2, la différence doit être là ^^

oracle7 · le 19 janvier 2022

@MilesTEG1

Bonjour,

il y a 3 minutes, MilesTEG1 a dit :

la différence doit être là ^^

Possible, mais je ne le croît pas mais sans toutefois savoir te dire pourquoi, juste un ressenti ...😟 J'imagine plutôt l'effet de bord d'un autre paramétrage mais le quel ? Encore un truc à la c... comme d'hab ...

Maintenant du jour où je basculerais sous DSM7, c'est peut-être moi qui sera emm...🤪 ou pas si la solution a été trouvée d'ici là 🤗 Désolé de ne pouvoir t'aider plus sur ce coup là.

Cordialement

oracle7😉

MilesTEG1 · le 19 janvier 2022

@oracle7 T'inquiète 🙂
La solution utilisée pour contourner le problème fonctionne, et est même validée par le ponte @.Shad. donc tout va bien 😛

oracle7 · le 19 janvier 2022

@MilesTEG1

Bonjour,

il y a 4 minutes, MilesTEG1 a dit :

La solution utilisée pour contourner le problème fonctionne

Cela reste quand même qu'une voie de contournement qui ne solutionne pas le problème et qui plus est, t'oblige à rester sur une ancienne version de telegraf mais je suis d'accord c'est toujours mieux que rien du tout ...🤪

Cordialement

oracle7😉

Modifié le 19 janvier 2022 par oracle7

.Shad. · le 19 janvier 2022

il y a 45 minutes, oracle7 a dit :
srw-rw-rw- 1 root root   0 Oct  6 15:42 docker.sock

Je ne sais plus comment c'était sous DSM 6, mais je doute que tu aies nativement du 666 sur ce fichier-là, je pense que tu devais avoir initialement du 660 voir plutôt du 640. En l'état tout utilisateur du système peut utiliser et effacer ton fichier. Tu as dû étendre les permissions à un moment donné.

Le mieux étant de laisser root/root quand on a la possibilité, si pas, créer un groupe dédié à la manipulation de ce fichier, et attribuer ce groupe au fichier. C'est beaucoup plus sécurisé qu'un 666.

C'est d'ailleurs le système utilisé par DSM 7 pour renderD128, qui autrefois appartenait à root/root, et maintenant root/videodriver. Ainsi si besoin qu'un utilisateur accède à ce fichier on peut se servir du groupe, et ne plus modifier les permissions en 666. Les autres distributions Linux fonctionnent sur le même principe, au moins pour Ubuntu et Debian en tout cas.

renderD128 je pense que c'est pour le transcodage matériel avec Plex non ?

il y a 45 minutes, oracle7 a dit :
srw-rw-rw- 1 root root   0 Oct  6 15:42 docker.sock

Je ne sais plus comment c'était sous DSM 6, mais je doute que tu aies nativement du 666 sur ce fichier-là, je pense que tu devais avoir initialement du 660 voir plutôt du 640. En l'état tout utilisateur du système peut utiliser et effacer ton fichier. Tu as dû étendre les permissions à un moment donné.

Le mieux étant de laisser root/root quand on a la possibilité, si pas, créer un groupe dédié à la manipulation de ce fichier, et attribuer ce groupe au fichier. C'est beaucoup plus sécurisé qu'un 666.

C'est d'ailleurs le système utilisé par DSM 7 pour renderD128, qui autrefois appartenait à root/root, et maintenant root/videodriver. Ainsi si besoin qu'un utilisateur accède à ce fichier on peut se servir du groupe, et ne plus modifier les permissions en 666. Les autres distributions Linux fonctionnent sur le même principe, au moins pour Ubuntu et Debian en tout cas.

renderD128 je pense que c'est pour le transcodage matériel avec Plex non ?

il y a 3 minutes, oracle7 a dit :

Cela reste quand même qu'une voie de contournement qui ne solutionne pas le problème et qui plus est, t'oblige à rester sur une ancienne version de telegraf mais je suis d'accord c'est toujours mieux que rien du tout ...🤪

De mon côté ça ne marche pas mieux avec un chmod 666 avec la 1.21.2, donc pour moi le problème ne vient pas de là.
Mais d'où, je ne sais pas encore.

oracle7 · le 19 janvier 2022

@.Shad.

Bonjour,

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

mais je doute que tu aies nativement du 666 sur ce fichier-là, je pense que tu devais avoir initialement du 660 voir plutôt du 640. En l'état tout utilisateur du système peut utiliser et effacer ton fichier. Tu as dû étendre les permissions à un moment donné.

Oui, je l'avais fait suite à nos échanges. Cela dit comme les utilisateurs de mon système à ce niveau se résument à moi seul, ce n'est pas grave en soit. J'assume ...

Après, pour renderD128, je n'utilise pas cette m... de Plex mais Kodi sur des RPI qui ne lisent, via NFS, que les fichiers vidéos (quelques soient leur format) simplement stockés sur mon NAS et donc aucun souci contrairement à comme on peut le voir avec la multitude de post sur Plex ici, maintenant ce que j'en dit ...

Cordialement

oracle7😉

.Shad. · le 19 janvier 2022

il y a 4 minutes, oracle7 a dit :

Après, pour renderD128, je n'utilise pas cette m... de Plex mais Kodi sur des RPI qui ne lisent, via NFS, que les fichiers vidéos (quelques soient leur format) simplement stockés sur mon NAS et donc aucun souci contrairement à comme on peut le voir avec la multitude de post sur Plex ici, maintenant ce que j'en dit ...

J'expliquais juste à quoi ça servait.

oracle7 · le 19 janvier 2022

@.Shad.

Bonjour,

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

J'expliquais juste à quoi ça servait.

Je l'avais bien compris dans ce sens, j'ai juste digressé sur Plex ...😝

Cordialement

oracle7😉

Connexion

[TUTO] Monitoring réseau (Telegraf + InfluxDB 1.8 + Grafana)

Messages recommandés

Meilleurs contributeurs dans ce sujet

Jours populaires

Meilleurs contributeurs dans ce sujet

Jours populaires

Messages populaires

.Shad.

oracle7

.Shad.

Images postées

Rejoindre la conversation

Qui est en ligne 5 membres, 0 anonyme, 236 invités (Afficher la liste complète)

Contributeurs populaires

Annonces

Information importante