.Shad.

Supprime les 3 conteneurs, et tu refais docker-compose up -d pour chacun.

Tu as un conteneur Telegraf qui utilise encore l'image, tu peux stopper stopper et effacer le conteneur manuellement puis ensuite effacer l'image avec Portainer ou la commande : docker rmi <nom_de_l_image_telegraf> Pour : docker-compose down c'est très étonnant que ça ne marche pas, ça doit être écrit dans le dossier où se trouve le fichier docker-compose de Telegraf, je ne l'ai pas précisé (comme pour up -d)

Je remarque que le nom de ton image Telegraf est étrange sur ton impression d'écran de Portainer. Pour repartir d'une base saine, je te conseille de faire la chose suivante : Tu conserves les fichiers docker-compose.yml pour chaque conteneur et le fichier telegraf.conf Tu exportes éventuellement tes dashboards si tu les as customisés Tu arrêtes chaque conteneur avec docker-compose down Tu vas taper docker image prune (ou tu effaces l'image de telegraf depuis Portainer, ça marche très bien) en SSH, et tu confirmes Tu supprimes tout le contenu des dossiers data de Influxdb et grafana Tu vas refaire les manips de mon tutoriel, et, avec l'accord de @bruno78, je te propose d'utiliser le même conteneur Telegraf pour les données du NAS et de la Freebox, il va falloir ajouter les volumes dont il a besoin et qu'il définit dans ce tutoriel : le volume lié au script python (éventuellement) le volume pour les logs On peut garder les ports de mon tutoriel, @bruno78 les a intelligemment décalés pour ne pas entrer en conflit avec mon conteneur, ici si on utilise le même donc pas besoin. Dans notre cas du coup, ce sera la même datasource InfluxDB qui regroupera les données du NAS et de la Freebox. Suite : Tu ajoutes le paragraphe [[inputs.exec]] du tutoriel pour la collecte des métriques de ta Freebox Tu disais que ta Freebox n'est pas sur le même réseau, est-ce que ton NAS autorise les connexions entrantes depuis le sous-réseau de celle-ci ? A partir de là, je pense que tu une base saine et prête pour appliquer ce tutoriel. On docker-compose up -d et on regarde ce que disent les logs.

Le fait que les IP changent ne gênent normalement pas, car ils utilisent normalement leurs noms pour communiquer entre eux.

Oui en effet, coquille. @bruno78 Oui c'est ce que je notais plus haut, je ne vois pas ce que l'IP de Telegraf vient faire au niveau des logs de Grafana. Cependant sur l'impression d'écran où je lui demande d'afficher les measurements dans InfluxDB qu'il arrive à récolter les données par défaut liées au cpu, mem, etc... donc la liaison est bien établie entre Telegraf et InfluxDB. Et a priori il a aussi configuré correctement la datasource dans Grafana... Et l'erreur des logs de Grafana correspond généralement à l'erreur qu'on a lorsqu'on valide une datasource, lui il a le message Datasource working.

@Jeff777 On peut en tout cas constater que dans la base de donnée nas_telegraf le measurement lié au script n'est pas repris, on a seulement ceux relevés par défaut par Telegraf (cpu, mem, etc...). Du coup au vu des IP de tes conteneurs, je ne comprends pas bien pourquoi Grafana fait référence dans ses logs à 172.18.0.5, qui est l'IP du conteneur Telegraf. Les deux ne sont pas sensés communiquer, Telegraf alimente InfluxDB et Grafana accède aux données qui y sont stockées. Normalement il te faut quelque chose ainsi, je reprends l'impression d'écran de mon tutoriel : Mais évidemment à la place de nas_telegraf ça doit être fbx_telegraf, est-ce que cette datasource est validée (message vert en bas de page) dans ta configuration ?

En SSH tu peux faire : docker inspect <nom_du_conteneur> Plutôt à la fin du fichier tu auras un champ IP_address : Sinon tu as des interfaces comme portainer qui sont vraiment top pour avoir une vue d'ensemble de son système :

Salut, @Jeff777 Tu peux essayer de te connecter en SSH sur le conteneur influx db et vérifier si la base de données est bien peuplée : sudo docker exec -it <nom_du_conteneur_influxdb> influx -username <utilisateur_admin> -password <mot_de_passe_admin> Puis : USE fbx_telegraf SHOW MEASUREMENTS Tu devrais voir la liste des champs qu'on retrouve dans Grafana. D'après les logs de ton conteneur fbx_telegraf, il y a une erreur au niveau de l'exécution du script et qui l'arrête de manière inopinée (exit code 1). Si tu ne vois rien c'est qu'il y a un problème entre Telegraf et InfluxDB. D'ailleurs remarque à @bruno78 également, on peut tout à fait utiliser le même conteneur telegraf que pour le NAS ou que ce soit d'autres. De manière générale j'essaie de mettre une instance telegraf par machine, mais là vu que le conteneur n'est pas directement hébergé sur la Freebox, on passe par une autre machine (ici le NAS), autant centraliser dans le même conteneur. De ta dernière impression d'écran, il semble y avoir également un souci de communication entre Grafana et la datasource InfluxDB pour ta Freebox. Est-ce que 172.18.0.5 est l'adresse IP de ton conteneur InfluxDB ? EDIT : tes conteneurs doivent se baser sur l'heure UTC par défaut, c'est mon cas aussi d'ailleurs : On peut régler ça je pense en montant dans les volumes de telegraf : /etc/localtime:/etc/localtime:ro

Bonjour, Pas mal de confusion ici et là. Les disques n'ont aucun rapport (sauf dysfonctionnement avéré, mais le gestionnaire de stockage te l'indiquerait) avec la lenteur d'exécution du système. Que l'interface soit lente, ça s'explique, le software a évolué, et la version 6.2 de DSM est certainement plus gourmande que la version de l'époque. Mais dans ton cas tu dis que tu as toujours connu des problèmes de lenteur, j'ai plutôt tendance à penser que le réseau n'est pas optimal. L'utilité du cache SSD est très limité, et vient seulement en complément d'un jeu de disques qui accueille les données. Il ne peut pas servir de stockage à proprement parler. Dans un premier temps, quelle est ton utilisation ? Utilisation des applis mobiles, streaming local de musique, vidéo SD, HD, 4K ? etc...

Tu as la solution C2 de Synology, un cloud intégré à Hyper Backup, qui gère les sauvegardes de ton NAS. Sinon Dropbox, Google Drive, et tout un tas d'autres solutions, il faut que tu lances Hyper Backup, si pas installé par défaut à ajouter depuis le centre de paquets.

Ce sont des débits tout à fait classiques et ce même avec du matériel d'entrée de gamme mais fonctionnel (routeur à moins de 50€ et du câble cat5e). J'ai un pare-feu matériel pfSense qui fait le routage en session pppoe sur ma ligne VDSL. Mais il n'y a aucun besoin de matériel particulier pour avoir du gigabit. Outre la question de @Balooforever il faut que tu procèdes de manière itérative. Tester à partir d'un autre pc/laptop en filaire, utiliser un autre câble, utiliser le swich en direct avec le NAS (NAS <--câble--> switch <--câble--> PC), etc... L'autre possibilité c'est que tu aies d'importantes perturbations électro-magnétiques et que le blindage extérieur du câble cat5e ne suffise pas, dans ce cas-là tu peux acheter un câble cat6 de petite longueur (S/FTP ou S/STP de préférence, pour un blindage optimal). Mais honnêtement peu de chance que ça vienne de là. Est-ce que ton test est fait alors que le reste de ton réseau est au "repos" ? (pas de téléchargement, pas de streaming, etc...)

Alors avec NAStester : avec iperf : Globalement c'est assez cohérent, donc NAStester a l'air digne de confiance. Est-ce que tu as un switch ou tout passe par le routeur ?

Je vais essayer avec Nastester voir s'il donne des résultats cohérents, j'ai iperf pour comparer.

Bienvenue parmi nous ! Au plaisir de gagner ensemble autour d'un sujet !

Mettons-nous d'accord sur les unités, il ne faut pas confondre b et B : - b c'est pour bit - B c'est pour byte, octet en français 1 B = 8 b Quand on parle de gigabit, ça veut dire 1000 Mbps (Mega bits par seconde) = 1000 / 8 MBps = 125 MBps. Ca c'est théorique on tourne généralement à du 105-110 MBps avec un réseau filaire performant en cat5e ou cat6. Nastester donne des vitesses en MBps. Concernant les taux de transferts en eux-mêmes, tu ne devrais pas avoir de telles différences en lecture et écriture, ça doit être sensiblement identique, donc là on a un effet selon moi indépendant de la qualité du réseau, qui est bonne sans être optimale (80 MBps c'est correct sans plus). Essaie maintenant de te relier en direct avec un câble ethernet sur le NAS, tu fixes son IP sur un sous-réseau que tu choisis. Par exemple 192.168.3.100/255.255.255.0 Ensuite tu règles ton PC en IP statique avec une IP dans le même sous-réseau, par exemple 192.168.3.101/255.255.255.0 Tu lances un test sur l'adresse IP du NAS avec Nastester depuis ton PC. N'oublie pas à la fin du test de remettre l'adresse habituelle de ton NAS, en statique ou DHCP.

Je doute que le tarif du DS918+ diminue réellement à court terme.

Là où Ubiquity brille c'est réellement sur les AP. Pour le reste je trouve le surcoût assez élevé par rapport à la concurrence pour les mêmes fonctionnalités. Après certains aiment bien avoir toutes leurs données accessibles depuis le unifi controller. Dans le milieu professionnel c'est autre chose et ça peut totalement se justifier. Pour moi ça se résume à un choix purement esthétique et donc subjectif.

Les bonnes résolutions ne se prennent pas qu'en Janvier ! Bienvenue 🙂

En tout cas tu n'es pas en 100Mbps car tu dépasses les valeurs théoriques, donc tu es bien en gigabit mais totalement parasité. Dans ce genre de cas, on procédé de manière itérative, on débranche tout entre le client et le NAS. Et on remonte étape par étape. On commence par changer de port Ethernet sur la box/switch/routeur. Si ça ne change rien on change intervenir des câbles. On peut enlever le commutateur de l'équation en se raccordant directement au NAS depuis le client avec un câble. Le but étant d'identifier quel périphérique fait office de goulot d'étranglement.

Tu peux installer un serveur rsync sur ton PC et faire des sauvegardes via Hyper Backup. Pourquoi mettre FreeNAS dessus si tu as déjà un Synology ? Met une bête distribution Linux tu seras plus tranquille.

Le lien de ton image ne marche pas chez moi. Tu obtiens quels débits ? Dans tous les cas, les chances que le NAS soit l'élément limitant de ton installation sont quasi nulles.

Ah si tu as un htaccess qui fait la redirection c'est sûr que tu es coincé 🙂

Photo Station c'est sur le port 80, tu fais donc https://sous-domaine.ndd.tld:443 vers http://localhost:80, en n'oubliant pas de préciser /photo dans ton URL et ça devrait marcher.

Vu que tu n'as pas de serveur DNS local ça invalide mon hypothèse. Je ne vois pas de ce que tu décris pourquoi ça ne fonctionne pas. 😕

Tu as bien différencié le nom DNS de ta box et le sous-domaine (utilisé par le proxy inversé) pour accéder à son interface d'administration ?