.Shad.

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

Haha ! Je vais y jeter un œil pour voir si j'arrive à quelque chose 😉

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

Bienvenue parmi nous 🙂

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.

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 👍 Tout à fait, tu peux aussi remplacer : networks: default: external: name: monitoring par : networks: monitoring: external: true Moins long et plus lisible. 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.

@maxou56 pourra peut-être t'en dire un peu plus, je sais qu'il a des adaptateurs 2.5 Gb/s sur ses NAS et qu'il utilise des Mac. Pour la question concernant l'Adaptative Load Balancing, voir ce sujet : Mais dans les faits donc ça revient à faire de l'agrégation de liens, sauf que c'est géré au niveau du NAS et pas du switch (ça te fait l'économie d'un switch administrable si tu n'as pas ça, si tu as alors préférer cette solution), ce qui signifie que tu auras plusieurs voies de 1 Gb/s, particulièrement adapté pour du multi-tâches ou multi-utilisateurs, mais en aucun cas tu ne dépasseras le gigabit.

C'est étrange comme problème, à ta place j'essaierais de contacter le support Synology.

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. 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. 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. @oracle7 a cité un message de @bruno78 dans son tutoriel de supervision de la Freebox à mon avis.

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.

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é. 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. 😉 Dans notre cas, il est clairement intéressant de regrouper les services au sein d'un même fichier. 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. @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.

On a pu lire plusieurs retours déjà concernant des problèmes avec la Freebox et l'URL permettant de l'administrer. Je pense qu'il y a un hardcoding quelque part dans la Freebox qui perturbe le fonctionnement normal, ou des références qui pointent vers l'extérieur, même quand on essaie d'y accéder uniquement en local.

Ok pas de souci je l'ajouterai 😉 2 retours c'est déjà plus significatif !

Tout dépend de ce que tu souhaites faire, dans ce cas-là je fais comme @bruno78 je crée un fichier avec tous les services car ils sont liés. Par contre un docker-compose down entraînera l'arrêt de tous les conteneurs.

Il faut créer en amont tous les dossiers qu'on monte, c'est-à-dire ceux qu'on retrouve dans le fichier docker-compose.yml Donc mea culpa il faut bien le créer en amont. Sinon concernant la commande c'est docker-compose et pas compose-docker, et elle est reprise dans les informations préliminaires concernant l'utilisation de docker-compose. L'intérêt c'est justement qu'on peut utiliser la méthode qu'on veut, bien que je favorise grandement docker-compose pour sa flexibilité. 😉

C'est un NAT qu'on fait entre la machine hôte et le conteneur, de manière à très similaire à ce qu'on fait dans un réseau local entre un pare-feu/routeur/box et un périphérique du réseau. Dans notre cas, InfluxDB écoute ce que lui envoie Telegraf (et éventuellement d'autres software capable de dialoguer avec InfluxDB, collectd par exemple) sur ce port. Comme précisé dans les remarques concernant la mise en route du conteneur InfluxDB, à partir du moment où Telegraf et InfluxDB se trouvent dans le même réseau bridge personnalisé, il n'y aurait théoriquement même pas besoin d'exposer le port 8086 sur le NAS, car Telegraf et InfluxDB savent directement se causer, sans passer par l'hôte (le NAS). Mais si par hasard, tu décidais d'exploiter InfluxDB pour d'autres périphériques de ton réseau, il faut qu'InfluxDB soit accessible, et seul le NAT entre hôte et conteneur permet de rendre les conteneurs accessibles au reste du réseau (cf analogie routeur et LAN). A noter qu'on peut passer par un proxy inversé pour exposer InfluxDB, et utiliser le port 443. Très utile si on supervise aussi des machines distantes. 😉 Et pour répondre plus précisément à la question, oui bien sûr les ports donnés dans le tutoriel sont purement adaptés à l'application prise en exemple. Le dossier data va être généré par le lancement du conteneur. De souvenir, car je n'utilise plus InfluxDB depuis longtemps sur mon NAS, il sera créé en root/root, car vu qu'on ne précise pas l'utilisateur et le groupe dans le docker-compose, il le fera par défaut en root/root. Normalement ça ne posera aucun problème de fonctionnement. Sur mon VPS, j'ai ajouté le paramètre : user: "1001:1001" dans le fichier docker-compose, même indentation que volumes, environment, etc... Cela permet sans passer par les variables PUID/PGID, qui ne sont pas implémentés sur ces images (dommage car très adaptées aux NAS), de spécifier l'utilisateur exécutant les actions lors de la création du conteneur, et typiquement aussi les propriétaires des fichiers créés. Sur mon VPS 1001:1001 est l'UID/GID de mon utilisateur, à remplacer par ce que tu souhaites utiliser sur ton NAS. Je mets toutefois en garde car sur DSM ce n'est jamais évident de jouer avec ces paramètres, je ne vois pas de problème majeur à laisser root/root en tant que propriétaire des fichiers créés dans ton dossier influxdb. Le fichier docker-compose.yml se trouve dans le dossier du conteneur, donc tu as créé un dossier influxdb, et dedans tu crées un fichier docker-compose.yml, c'est tout ce que tu as avant de démarrer la création.

Cela peut faire penser à un conflit d'IP sur le réseau local. Comment est définie l'IP du NAS ? Fixée statiquement ou par réservation DHCP ? Ou aléatoire ?

Bienvenue parmi nous 🙂

À tout hasard, vu les dossiers sur lesquels il essaie de travailler j'aurais tenté d'ajouter sudo en début de commande ? Ou alors tu es déjà en root ?

Bienvenue, tu es un nas du jeu de mot !

Oui je vais ajouter la précision. De manière générale ce log regroupe pas mal d'infos utiles, il ne faut pas hésiter à le consulter prioritairement. 😉

Pas plus d'info dans /var/log/messages ? EDIT : J'ai trouvé ça aussi https://community.synology.com/enu/forum/17/post/97593

Salut, Je suis tombé là-dessus, je sais pas si ça te concerne : https://www.reddit.com/r/synology/comments/dczg7v/docker_package_installation_failing/ Apparemment si tu as une connexion VPN active (le NAS en tant que client), ça ne fonctionne pas.

Bienvenue parmi nous 😉

Bienvenue, Le doyen du forum peut-être ? Bienvenue 🙂