.Shad.

C'est pas la meilleure solution, il serait préférable que tu crées un groupe dédié avec les droits sur ces dossiers. Et utiliser son gid dans Grafana. Mais ça peut faire l'affaire. Ça dépend les droits que donnent les gens au groupe "users" utilisé par défaut dans DSM. Et de qui est propriétaire des dossies en question. C'est vraiment propre à DSM toutes ces emm*rdes liées aux permissions, c'est pour ça que j'ai depuis longtemps déporté tout ça sur un VPS. Aucun problème sur une distribution Linux classique... La gestion des ACL de Synology a ses avantages, mais surtout des inconvénients je trouve. 😉

Apparemment la méthode lan.list est l'ancienne méthode, as-tu essayé la fonction Custom DNS directement disponible dans le GUI de Pi-hole ? Essaie de reproduire ce que tu as avec lan.list dans la GUI. Puis tu fais sur ton PC par exemple dans l'invite de commandes ou sur Linux : nslookup video.ndd.fr IP_du_Pi-Hole Tu as installé Pi-Hole de quelle manière ?

Essaie d'ajouter le gid du groupe administrateurs du NAS : user: "1030:101" Voir si c'est bien un problème lié aux permissions. Ce n'est pas idéal et définitif mais ça permet de cerner le problème. 2ème étape, créer un groupe dédié qui aura des droits R/W sur le volume monté. Supprimer le contenu des volumes et réessayer.

Tu as réessayé avec le paramètre user dans Grafana ? N'hésite pas à supprimer le contenu de /volume1/docker/grafana/data, ça sera généré avec ton nouvel utilisateur lors de la re-création du conteneur. Je te conseille de supprimer le NAT des ports dans Telegraf, sauf si tu souhaites qu'un périphérique externe accède à Telegraf (donc Telegraf recevant des infos entrantes), le NAS ayant accès au conteneur nativement via l'IP 172.20.0.3. Pour InfluxDB si tu comptes l'utiliser pour une utilisation distante tu peux laisser le NAT, et Grafana c'est nécessaire. Pour la version en tout début de fichier, tu peux passer en 2.1 plutôt que 2, la version 2.1 gère beaucoup mieux les labels, il se peut qu'à l'avenir tu t'en serves, autant faire le changement maintenant. Mais sinon tout m'a l'air bon, même sans mes suggestions ça devrait fonctionner pour moi. N'hésite pas à supprimer le contenu de tous les dossiers montés pour une installation propre avant de refaire un docker-compose up -d (garde quand même une copie de telegraf.conf 😉).

Ok je pensais que ton 214play était dans un autre LAN, je comprends mieux, aucun souci pour la communauté alors. Ce que je dis est valable pour le NAS chez tes parents effectivement.

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

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.

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.

Quasi certain que le problème vient des alias DNS renseignés dans Pi-Hole, est-ce que tous les sous-domaines utilisés pour faire du proxy inversé pointent bien vers le NAS, quelque soit la machine hébergeant le service derrière ? Si tu peux mettre une impression d'écran (en cachant ton nom de domaine) de tes alias dans Pi-Hole stp.

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.