.Shad. Posté(e) le 8 septembre 2020 Auteur Posté(e) le 8 septembre 2020 C'est dans la partie InfluxDB de Telegraf que ça se configure : ############################################################################### # OUTPUT PLUGINS # ############################################################################### # Configuration for sending metrics to InfluxDB [[outputs.influxdb]] ## The full HTTP or UDP URL for your InfluxDB instance. ## ## Multiple URLs can be specified for a single cluster, only ONE of the ## urls will be written to each interval. # urls = ["unix:///var/run/influxdb.sock"] # urls = ["udp://127.0.0.1:8089"] # urls = ["http://127.0.0.1:8086"] urls = ["http://influxdb:8086"] ## The target database for metrics; will be created as needed. ## For UDP url endpoint database needs to be configured on server side. database = "nas_telegraf" ## The value of this tag will be used to determine the database. If this ## tag is not set the 'database' option is used as the default. database_tag = "" ## If true, no CREATE DATABASE queries will be sent. Set to true when using ## Telegraf with a user without permissions to create databases or when the ## database already exists. skip_database_creation = true ## Name of existing retention policy to write to. Empty string writes to ## the default retention policy. Only takes effect when using HTTP. retention_policy = "" Il y a plusieurs paramètres, par défaut la durée est de 0s (infini). Si InfluxDB crée la base de donnée en amont à la création du conteneur, on ne peut pas définir la politique de rétention des données. Il faut dans ce cas-là laisser Telegraf la créer (skip_database_creation = false et supprimer les variables d'environnement liées à la création de la base de donnée nas_telegraf dans le tutoriel par exemple) et faire les réglages qu'on désire dans telegraf.conf C'est un sujet complexe que la gestion de la rétention des données : https://dzone.com/articles/simplifying-influxdb-shards-and-retention-policies Tu peux très bien la laisser sur une semaine, mais ça me semble court. Perso j'ai une année de suivi actuellement et dans les faits je n'ai remarqué aucune utilisation du stockage abusive de la part d'InfluxDB, mais j'imagine que ça dépend du nombre de périphériques qu'on supervise. 0 Citer
MilesTEG1 Posté(e) le 8 septembre 2020 Posté(e) le 8 septembre 2020 Il y a 9 heures, .Shad. a dit : 1/ La seule différence entre réseau externe et réseau interne (défini dans un fichier docker-compose) c'est que lorsque tu feras un docker-compose down pour le 2ème cas, le réseau sera également effacé. 2/ La 2ème option est totalement adaptée quand tu définis tous les services qui vont utiliser ce réseau dans un même fichier docker-compose.yml, à l'époque je ne m'intéressais à Docker que depuis 1 mois ou 2, si je devais refaire le tutoriel maintenant ce serait beaucoup plus "propre", mais ça permet à ceux qui s'intéressent à Docker de se confronter à autre chose que juste faire tourner une application. 😉 3/ Dans notre cas, il est clairement intéressant de regrouper les services au sein d'un même fichier. 4/ Personnellement je préfère définir des réseaux externes pour les applications qui je le sais d'avance sont destinées à tourner en permanence. Et j'utilise la génération interne pour ce que je teste. C'est vraiment une question de goût. Outre ces détails (importants), ça fonctionne exactement pareil. 5/ @bruno78 a ajouté des paramètres permettant de définir exactement ce qu'on veut, c'est tout à fait faisable avec un réseau externe aussi. J'ai quelques petites questions à propos de ce que j'ai mis en couleur dans ton message : 1/ C'est quoi que tu appelles réseau internet et réseau externe ? (j'ai pas le souvenir d'avoir lu ça dans le tuto 🙂 ) 2/ et 3/ Tu parles ici de faire un seul fichier docker-compose.yml pour toutes les applications ? Ce qui engendrera un seul conteneur plutôt que 3, c'est bien ça ? 3/ Si je fais un seul fichier, est-ce que ça va effacer les données déjà présentes dans les dossiers ? (sinon il faudra que je fasse une sauvegarde que je ferais quoiqu'il arrive 🐵 ) 4/ là j'ai pas trop saisi encore cette nuance de réseau externe... 5/ je n'ai pas retrouver son message... (j'ai du le rater de toute évidence...) 0 Citer
.Shad. Posté(e) le 8 septembre 2020 Auteur Posté(e) le 8 septembre 2020 il y a une heure, MilesTEG1 a dit : 1/ C'est quoi que tu appelles réseau internet et réseau externe ? (j'ai pas le souvenir d'avoir lu ça dans le tuto 🙂 ) Parce que je n'en parle pas. Un réseau externe est défini en dehors d'un fichier docker-compose.yml, c'est l'approche que j'utilise ici. Tu crées un sous-réseau avec une plage d'IP et une passerelle (si pas précisé, comme dans le tutoriel, des valeurs sont automatiquement attribuées). Même s'il n'y a plus de conteneur dans ce sous-réseau, il persiste, et tu pourras le rejoindre de nouveau à tout moment. S'il est défini dans un fichier docker-compose, alors il sera créé au moment de la création des différents services composant le fichier. Si on supprime ces conteneurs par un docker-compose down, le réseau disparaît aussi. il y a une heure, MilesTEG1 a dit : 2/ et 3/ Tu parles ici de faire un seul fichier docker-compose.yml pour toutes les applications ? Ce qui engendrera un seul conteneur plutôt que 3, c'est bien ça ? On peut tout mettre dans un même fichier docker-compose, on préfère même cette solution quand les services sont interdépendants l'un de l'autre. Suivant l'utilisation qu'on en fait (car ici on supervise le NAS, mais potentiellement on peut superviser beaucoup plus) il faut adapter. Mais attention, ça fait bien 3 conteneurs différents. Il faut voir ça comme un manuel qui t'explique comment monter et démonter une table, ses chaises, ses allonges, etc... au lieu d'avoir un manuel pour chaque partie. il y a une heure, MilesTEG1 a dit : 3/ Si je fais un seul fichier, est-ce que ça va effacer les données déjà présentes dans les dossiers ? (sinon il faudra que je fasse une sauvegarde que je ferais quoiqu'il arrive 🐵 ) Les données montées sur le NAS ne sont jamais effacées par un docker-compose down. Mais il faudra voir si tu fais un seul dossier avec différents sous-dossiers pour les différents services. Ça c'est à toi de voir ce que tu préfères. il y a une heure, MilesTEG1 a dit : 5/ je n'ai pas retrouver son message... (j'ai du le rater de toute évidence...) @oracle7 a cité un message de @bruno78 dans son tutoriel de supervision de la Freebox à mon avis. 0 Citer
oracle7 Posté(e) le 8 septembre 2020 Posté(e) le 8 septembre 2020 (modifié) @.Shad. Bonjour, il y a une heure, .Shad. a dit : Un réseau externe est défini en dehors d'un fichier docker-compose.yml, c'est l'approche que j'utilise ici. Tu crées un sous-réseau avec une plage d'IP et une passerelle (si pas précisé, comme dans le tutoriel, des valeurs sont automatiquement attribuées). Même s'il n'y a plus de conteneur dans ce sous-réseau, il persiste, et tu pourras le rejoindre de nouveau à tout moment. S'il est défini dans un fichier docker-compose, alors il sera créé au moment de la création des différents services composant le fichier. Si on supprime ces conteneurs par un docker-compose down, le réseau disparaît aussi. Ah là, Merci, c'est encore plus clair comme cela.👍😃 Donc, si je comprends bien et pour reprendre mon idée d'avoir un réseau bien spécifique : Je crée un réseau externe via docker (comme dans le TUTO) mais là au lieu de cocher "Obtenir automatiquement la configuration du réseau", je coche "Utiliser la configuration manuelle" et je renseigne les paramètres de ce sous-réseau. Ensuite, dans le fichier docker-compose.yml pour chaque service je n'ai plus qu'a leur attribuer l'@IP de mon choix (i.e. dans le sous-réseau défini précédemment) pour fixer les choses et avoir une @IP spécifique à chaque conteneur/service. Pour ce faire on rajoute par ex, ceci : Citation services: influxdb: networks: monitoring: ipv4_address: 172.20.0.x ... telegraf: networks: monitoring: ipv4_address: 172.20.0.y ... networks: default: external: name: monitoring C'est cela ? la logique est bonne ? Autre question : En fouillant la toile, malgré que la modification de la durée de la politique de rétention ne soit pas possible par paramétrage/configuration car cela se fait semble-t-il lors de la création de la base de données, j'ai vu que l'on pouvait par contre tout de même, modifier la durée de rétention des informations qui est fixée par défaut à une semaine : Citation > show retention policies name duration shardGroupDuration replicaN default ---- -------- ------------------ -------- ------- autogen 0s 168h0m0s 1 true en faisant une commande du style (je ne suis pas sûr que la syntaxe soit rigoureusement exacte) : Citation docker exec -it influxdb influx -execute 'ATLER RETENTION POLICY autogen ON nas_telegraf DURATION 52w REPLICATION 1 SHARD DURATION 1w' Donc comment automatiser (si c'est possible !) cette commande pour qu'elle soit exécutée juste après la création de la base nas_telegraf ? Ainsi, on aurait un "nettoyage" automatique des données datant de plus d'un an car plus utiles. @MilesTEG1 OUI j'ai fait allusion à une réponse de @bruno78 dans son TUTO de monitoring de la FreeBox. Cordialement oracle7😉 Modifié le 8 septembre 2020 par oracle7 0 Citer
.Shad. Posté(e) le 8 septembre 2020 Auteur Posté(e) le 8 septembre 2020 (modifié) il y a 18 minutes, oracle7 a dit : Je crée un réseau externe via docker (comme dans le TUTO) mais là au lieu de cocher "Obtenir automatiquement la configuration du réseau", je coche "Utiliser la configuration manuelle" et je renseigne les paramètres de ce sous-réseau. Très possible, je n'ai jamais eu recours à l'interface DSM pour faire ça 🙂 via SSH ou avec Portainer. Mais ça doit être tout à fait possible oui 👍 il y a 18 minutes, oracle7 a dit : C'est cela ? la logique est bonne ? Tout à fait, tu peux aussi remplacer : networks: default: external: name: monitoring par : networks: monitoring: external: true Moins long et plus lisible. il y a 18 minutes, oracle7 a dit : docker exec -it influxdb influx -execute 'ATLER RETENTION POLICY autogen ON nas_telegraf DURATION 52w REPLICATION 1 SHARD DURATION 1w' Pour expliciter un peu, la première partie : docker exec -it influxdb signifie qu'on va exécuter dans le conteneur influxdb une commande : influx -execute 'ATLER RETENTION POLICY autogen ON nas_telegraf DURATION 52w REPLICATION 1 SHARD DURATION 1w' Si tu as mis en place une authentification HTTP comme dans le tutoriel, l'accès à la base de donnée te sera refusé, je te conseille de procéder autrement itérativement, pour bien comprendre le fonctionnement : docker exec -it influxdb bash Puis : influx -username admin -password admin à adapter suivant ce que tu as défini dans ton docker-compose pour InfluxDB. Tu peux même te connecter avec ton utilisateur nas_telegraf, car il a les droits R/W sur la base de donnée en question normalement. Là arrive le coeur d'InfluxDB, le champ de requête, tu peux déjà explorer un peu ce qu'il est possible de faire en lisant la doc : https://docs.influxdata.com/influxdb/v1.8/query_language/explore-schema/ Et c'est ici que tu peux entrer ta commande (ALTER pas ATLER 😉) : ALTER RETENTION POLICY autogen ON nas_telegraf DURATION 52w REPLICATION 1 SHARD DURATION 1w Pour une première fois c'est bien de regarder un peu comment ça marche, ça permet aussi de voir comment les données sont organisées. Modifié le 8 septembre 2020 par .Shad. 0 Citer
MilesTEG1 Posté(e) le 8 septembre 2020 Posté(e) le 8 septembre 2020 @.Shad. merci pour les réponses 😉 Sinon vous êtes sur que la rétention est de 7jours maxi par défaut ? Car moi j'ai rien spécifié à la création de la base de donnée, et j'ai plus que 7 jours de dispo : mes données remontent au 29 aout, date à laquelle j'ai du lancer les conteneurs pour la première fois ^^ 0 Citer
.Shad. Posté(e) le 8 septembre 2020 Auteur Posté(e) le 8 septembre 2020 C'est la durée des shards qui est d'une semaine, concrètement je suis pas familier avec le concept il faudrait que je regarde de quoi il s'agit, mais perso j'ai plus d'un an de données je pense, avec la config par défaut. 0 Citer
oracle7 Posté(e) le 8 septembre 2020 Posté(e) le 8 septembre 2020 @MilesTEG1 et @.Shad. Bonjour, Ce site synthétise bien la chose, voir notamment sa conclusion. Mais il y en a plein d'autres sur le sujet de la rétention. Cordialement oracle7😉 0 Citer
oracle7 Posté(e) le 8 septembre 2020 Posté(e) le 8 septembre 2020 @.Shad. Bonjour, Merci pour l'explication sur la mise en œuvre de la commande de màj de la durée de rétention mais cela reste des opérations "manuelles", il n'y a vraiment pas moyen d'automatiser cela dans le processus de création du conteneur influxdb ? Cordialement oracle7😉 0 Citer
.Shad. Posté(e) le 8 septembre 2020 Auteur Posté(e) le 8 septembre 2020 Pour arriver à tes fins il faut build soi-même l'image via le dockerfile en ajoutant la commande souhaitée. Mais dans ce cas-là tu ne peux plus te servir de l'image officielle out-of-the-box, il te faudra DL les fichiers depuis Github, et utiliser docker build pour créer ta propre image. Pour moi c'est un faux problème, il suffit de ne pas ajouter dans le docker-compose d'InfluxDB les variables liées à la base de données : - INFLUXDB_USER=nas_telegraf - INFLUXDB_USER_PASSWORD=nas_telegraf Et tu règles dans telegraf.conf le paramètre skip_database_creation sur false, tu peux aussi personnaliser la politique de rétention de données comme tu l'entends. D'ailleurs le fichier telegraf.conf a changé entre le moment où le tutoriel a été rédigé et maintenant, j'ai des options en plus pour personnaliser la rétention de données sur mon VPS par exemple. Sinon n'hésite pas à consulter le discours d'influxdata, on y trouve beaucoup d'informations. 😉 0 Citer
oracle7 Posté(e) le 8 septembre 2020 Posté(e) le 8 septembre 2020 @.Shad. Bonjour, OK merci pour ces explications, je vais donc restreindre mes "envies" et ne pas modifier la politique de rétention pour rester sur du standard. Même si c'est possible, tout cela est encore bien au delà de ma portée actuelle et de mes connaissances en la matière. Donc je reporte, peut-être pas aux calandres grecques mais comme il n'y a aucune urgence alors comme on dit "demain il fera jour" ... Je continue sur la suite du TUTO. Cordialement oracle7😉 0 Citer
MilesTEG1 Posté(e) le 8 septembre 2020 Posté(e) le 8 septembre 2020 J'aurais une petite question ^^ J'aimerais monitorer mon vieux NAS. Comment puis-je ajouter ce NAS en source de données, mais que ce soit séparé du premier NAS dans la base de donnée ? Et potentiellement je ferais la même chose pour un autre NAS ailleurs (chez mes parents) si ça fonctionne 😉 0 Citer
oracle7 Posté(e) le 8 septembre 2020 Posté(e) le 8 septembre 2020 @MilesTEG1 Je serai aussi preneur de ces informations. @.Shad. Bon je viens d'exécuter le docker-compose sur mon fichier "générique". Les 3 conteneurs sont bien créés, influxdb et telegraf se lancent bien mais grafana commence par se lancer puis après deux secondes il s'arrête et redémarre plusieurs fois pour finir par rester "bloqué" ? sur redémarrage en cours. J'ai bien ouverts les ports des 3 conteneurs dans le pare-feu du NAS. Une idée ? Cordialement oracle7😉 0 Citer
MilesTEG1 Posté(e) le 8 septembre 2020 Posté(e) le 8 septembre 2020 il y a 2 minutes, oracle7 a dit : @MilesTEG1 Je serai aussi preneur de ces informations. @.Shad. Bon je viens d'exécuter le docker-compose sur mon fichier "générique". Les 3 conteneurs sont bien créés, influxdb et telegraf se lancent bien mais grafana commence par se lancer puis après deux secondes il s'arrête et redémarre plusieurs fois pour finir par rester "bloqué" ? sur redémarrage en cours. J'ai bien ouverts les ports des 3 conteneurs dans le pare-feu du NAS. Une idée ? Cordialement oracle7😉 Que dit le log du conteneur Grafana ? 0 Citer
oracle7 Posté(e) le 8 septembre 2020 Posté(e) le 8 septembre 2020 (modifié) @MilesTEG1 GF_PATHS_DATA='/var/lib/grafana' is not writable. You may have issues with file permissions, more information here: http://docs.grafana.org/installation/docker/#migration-from-a-previous-version-of-the-docker-container-to-5-1-or-later mkdir: can't create directory '/var/lib/grafana/plugins': Permission denied Modifié le 8 septembre 2020 par oracle7 0 Citer
MilesTEG1 Posté(e) le 8 septembre 2020 Posté(e) le 8 septembre 2020 C'est étrange... car normalement dans le conteneur, il doit avoir accès à toute son arborescence... non ? 0 Citer
oracle7 Posté(e) le 8 septembre 2020 Posté(e) le 8 septembre 2020 @MilesTEG1 Bonjour, Le problème est que tant qu'il n'est pas lancé je ne peux accéder à son arborescence pour modifier ou du moins au moins pouvoir voir quels droits sont effectivement attribués au répertoire '/var/lib/grafana' . On tourne en rond donc 😩 J'espère que @.Shad. ou @bruno78 auront une idée. Cordialement oracle7😉 0 Citer
.Shad. Posté(e) le 9 septembre 2020 Auteur Posté(e) le 9 septembre 2020 (modifié) Tu peux partager ton/tes fichiers docker-compose.yml ? Je n'ai pas installé Grafana sur mon NAS depuis très longtemps, donc il y a peut-être eu des changements qui ont été totalement transparents pour moi sur une Debian mais qui ne le sont pas sur DSM. La première chose selon moi serait d'ajouter dans le service grafana le paramètre : user: "uid" avec l'UID de l"utilisateur du NAS propriétaire des dossiers. Tu n'as pas besoin d'exposer tous les ports sur le NAS, pas ceux de Telegraf en tout cas. InfluxDB, si tu souhaites pouvoir y accéder depuis une machine distante (votre autre question), il faut effectivement exposer soit le port 8086 vers l'extérieur (mais dans ce cas-là activer SSL dans InfluxDB et Telegraf), soit plus simple utiliser un proxy inversé pour accéder au port 8086 du NAS (dans ce cas-là oui il faut faire un NAT NAS<->conteneur). Le seul obligatoire dans notre cas, vu qu'on est en bridge, c'est Grafana et son port 3000, si on veut y accéder de son LAN. Si vous installez Telegraf sur d'autres machines, il faudra juste adapter dans telegraf.conf l'URL d'écoute de InfluxDB (adresse proxy inversé par exemple). Modifié le 9 septembre 2020 par .Shad. 0 Citer
MilesTEG1 Posté(e) le 9 septembre 2020 Posté(e) le 9 septembre 2020 il y a 33 minutes, .Shad. a dit : Si vous installez Telegraf sur d'autres machines, il faudra juste adapter dans telegraf.conf l'URL d'écoute de InfluxDB (adresse proxy inversé par exemple). Hmmm, tu veux dire que pour monitorer un autre NAS, il faut installer sur ce NAS là telegraf ? Car sur mon vieux 214play, ce n'est pas possible... j'ai pas la possibilité de mettre docker... Je pensais que je pourrais récupérer directement depuis mon 920+ les données SNMP du 214play. 0 Citer
.Shad. Posté(e) le 9 septembre 2020 Auteur Posté(e) le 9 septembre 2020 Tu peux c'est juste que tu dois ouvrir le port 161 (SNMP) vers l'extérieur. Utiliser SNMPv2 au minimum avec un nom de communauté costaud 🙂 Je ne sais pas si on peut utiliser SNMPv3 mais ce serait préférable. 0 Citer
MilesTEG1 Posté(e) le 9 septembre 2020 Posté(e) le 9 septembre 2020 Déjà je voudrais juste pour le 214play qui est dans le même LAN 😉 Quand tu parles d'ouvrir le port sur l'extérieur, c'est sur le NAS ou sur la box ? La communauté est celle que tu as définie dans le tuto. Si je la change sur les NAS, les données acquises vont-elles disparaitre de Grafana (et donc de la DB) ? 0 Citer
bruno78 Posté(e) le 9 septembre 2020 Posté(e) le 9 septembre 2020 (modifié) Bonjour, @oracle7, ayant mis à jour tous mes dockers récemment, le renouvellement de Grafana n'a posé aucun problème. Comme l'a dit @.Shad. commencer par vérifier le user => uid. volumes: - "/volume1/docker/monitoring/grafana/data:/var/lib/grafana" user: "1026" "1026" étant l'Id du user qui va utiliser grafana, pour moi mon user admin personalisé. Pour obtenir cette référence => # id <utilisateur> Bruno78 PS pour compléter les droits sur /var/lib dans grafana : bash-5.0$ ls -lisa total 0 738 0 drwxr-xr-x 1 root root 40 Aug 25 09:01 . 733 0 drwxr-xr-x 1 root root 86 Aug 25 09:01 .. 739 0 drwxr-xr-x 1 root root 0 May 29 14:20 apk 706381 0 drwxr-xr-x 1 1026 users 40 Sep 9 06:10 grafana 740 0 drwxr-xr-x 1 root root 0 May 29 14:20 misc 741 0 drwxr-xr-x 1 root root 0 May 29 14:20 udhcpd bash-5.0$ cd grafana bash-5.0$ pwd /var/lib/grafana bash-5.0$ ls -lisa total 2512 706381 0 drwxr-xr-x 1 1026 users 40 Sep 9 06:10 . 738 0 drwxr-xr-x 1 root root 40 Aug 25 09:01 .. 706933 2512 -rwxr-xr-x 1 1026 root 2572288 Sep 9 06:10 grafana.db 706932 0 drwxr-xr-x 1 1026 root 88 May 27 06:12 plugins 707168 0 drwxr-xr-x 1 1026 root 0 Mar 13 14:33 png bash-5.0$ Modifié le 9 septembre 2020 par bruno78 0 Citer
.Shad. Posté(e) le 9 septembre 2020 Auteur Posté(e) le 9 septembre 2020 Ben il faut exposer le port 161 publiquement sur le NAS2 si tu veux que NAS1 y accède, ou alors mettre en place un VPN site à site. C'est toi qui vois. La communauté est définie sur un périphérique, et dans Telegraf pour chaque inputs.snmp tu définis la communauté du périphérique qui va être pollé. Je ne vois pas en quoi ça affecte ce que tu as déjà mis en place. 0 Citer
MilesTEG1 Posté(e) le 9 septembre 2020 Posté(e) le 9 septembre 2020 OK. Bon là j'ai ajouté l'adresse IP LAN du deuxième NAS que j'ai chez moi dans le telegraf.conf sans rien changer d'autre. J'ai pu faire un nouveau dashboard, en choisissant pour agent_host l'adresse IP du second NAS. Tout semble fonctionner : Je précise que je n'ai rien ouvert sur le 214play, mais comme il est fraichement installé, je n'ai pas encore mis le parefeu en route. Et vu qu'il n'est en rien exposé sur le net... et qu'il ne tourne en général pas 😮 0 Citer
.Shad. Posté(e) le 9 septembre 2020 Auteur Posté(e) le 9 septembre 2020 (modifié) Tu n'as pas dû faire de NAT du port 161 entre ta box et ton second NAS ? Je te déconseille de laisser la communauté par défaut sur tes NAS si tu utilises le même [inputs.snmp] que pour ton premier NAS. C'est l'équivalent d'un mot de passe, en terme de sécurité c'est comme si tu exposais DSM sur l'extérieur avec un compte admin/admin ou admin/password. Ou alors tu laisses "public" et si tu disposes d'une IP publique statique là où se trouve ton premier NAS, je te conseille de faire une règle de pare-feu sur ton second NAS avec comme source cette seule IP. Le tutoriel a comme postulat une installation locale, avec des applications isolées dans un bridge personnalisé et un minimum de NAT NAS <-> conteneur, dans ce cas-là il n'y a aucun risque de laisser "public" comme communauté. Ce n'est pas la même histoire quand on prendre l'autoroute de l'Internet. 😉 Modifié le 9 septembre 2020 par .Shad. 0 Citer
Messages recommandés
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.