.Shad.

Tu avais un tuto ici même :

Un VPS est un serveur privé virtuel, en gros tu loues à un prestataire une VM qui t'est dédiée et sur laquelle tu fais ce qui te chante. Dans les premiers prix, ce sont souvent des distributions Linux seulement, et c'est parfaitement suffisant. Tu peux y installer un serveur VPN dessus, et t'y connecter avec ton NAS ou tout autre périphérique. La connexion 4G ne permet pas d'ouvrir des ports, donc pour contourner le problème, @Einsteinium se connecte en VPN sur son VPS, sur lequel il a aussi un proxy inversé. De là il émule totalement une connexion domestique classique via le réseau filaire. Pour tes questions, je ne maîtrise pas la gestion du client VPN sur le NAS, pour avoir lu un peu là-dessus il a l'air d'être difficile de différentier de façon fiable quels services passent par le VPN ou non, il y a effectivement l'option des passerelles multiples, pour autant ça me semble beaucoup manquer d'option pour définir de manière plus granulaire la façon dont les applications doivent interagir avec le client VPN. Moi je passe par Docker pour gérer ça, Virtual DSM est très pratique aussi pour cet aspect-ci, le problème c'est que cela requiert un NAS disposant d'un processeur Intel, ce qui n'est pas le cas du DS418. Je suis désolé mais je ne pense pas pouvoir t'aider outre mesure...😕

Question qui n'a rien à voir, mais les opérateurs français ne fournissent pas à la demande un modem 4G quand la connexion adsl est vraiment trop faible ?

Unifi-controller est extrêmement gourmand en RAM, c'est comme Chrome, s'il y a de la RAM dispo il la prendra 😄 Perso je l'ai limité à 512M, je n'ai jamais de problème, il dépasse rarement 450M. Mais je n'utilise pas la même image (j'utilise celle du collectif Linuxserver), ça a peut-être son importance.

Good news ! Concrètement sur ce genre de tuto c'est presque plus l'exercice que la finalité qui importe je trouve 😛

Donc la résolution de nom fonctionne. À voir si le problème de ping revient.

Je profite de te répondre ici 😛 Ce n'est pas ce qu'il y a de plus intuitif au début, mais quand on a compris la logique derrière, on a du mal à s'en passer. Pour ma part j'ai arrêté le monitoring en local, parce que dès qu'on a 4-5 db dans InfluxDB, ça bouffe assez vite la RAM. Maintenant j'ai un VPS à 3€/mois chez OVH (dont je me sers à la base de serveur VPN pour accéder aux replays des chaines françaises), sur lequel j'héberge une instance InfluxDB et mes différentes instances Telegraf y envoient leurs métriques via TLS. Idéalement j'aurais aimé réussir à utiliser Wireguard comme pont local pour faire transiter toutes les données Telegraf par VPN, mais je trébuche sur quelques points techniques, ça viendra 😛 Plus généralement sur ce tutoriel, il mériterait que je le reprenne car avec le temps je me rends compte que certaines choses sont à améliorer, mais il faut trouver la motivation. 👍

Je comprendrais que tu puisses avoir des problèmes de résolution DNS en passant par un VPN, mais un ping...? Le protocole ICMP (entre autre le ping) est rarement explicitement bloqué, et généralement c'est plutôt dans l'autre sens (Monde -> NAS que NAS -> Monde) Dans un premier temps répond à la question de @PiwiLAbruti, dans un second est-ce qu'un nslookup www.google.fr te retourne une réponse ?

@CyberFr On autorise la communication sur tous les ports dans un réseau local. Les adresses qui sont reprises (10.x.x.x, 192.168.x.x, 172.16.x.x) sont des sous-réseaux réservés à l'utilisation privée, donc par définition elles n'existent pas sur Internet, c'est ce que tu trouveras dans tous les réseaux internes (derrière un routeur, pare-feu, modem, etc... ), particuliers ou entreprises. C'est la RFC1918 qui définit cela (comme une norme DIN ou ISO par exemple). On part du postulat que le réseau local est sûr, et qu'on n'a pas besoin de s'en protéger, ça part du principe que : - on soit prudent sur l'utilisation des autres périphériques locaux. - on soit plus prudent que ça en entreprise. Pour un utilisateur un peu au fait d'un comportement responsable sur Internet et des bonnes pratiques à adopter, ces règles facilitent grandement la vie et ne représentent qu'un très faible danger, surtout si on applique toutes les règles édictées dans ce tutoriel. Séquentiellement dans ton pare-feu, tu vas donc définir des règles, qui vont analyser chaque requête entrante. Tant que la requête ne correspond pas à une règle, elle continue de descendre dans la liste. Si aucune règle ne correspond à la requête, par précaution, on la bloque avec la règle "tous" "tous" "refuser". On est sûrs ainsi que rien qu'on ait explicitement autorisé ne puisse accéder au NAS. A toi après d'ajouter les règles pour utiliser tes services à distance par exemple. Par défaut ce tutoriel incite à utiliser le VPN, ce qui est une bonne chose, en revanche si tu souhaites accéder à ton NAS depuis le travail, la plupart du temps il n'est pas possible d'installer un client VPN sur ton poste de travail, et dans ce cas-là il te faudra exposer ce service sur le web, la plupart des règles énumérées ici permettent entre autres de donner un maximum de sécurité à cette connexion externe (Blocage sur tentative de brute force, possibilité de géobloquer les connexions entrantes, etc...) J'espère t'avoir un minimum éclairer, mais tu verras avec un peu d'habitude ça vient vite 🙂

Salut, @GrOoT64 a tout dit. Bienvenue parmi nous 🙂

Ça me semble bon, pense bien à créer les dossiers py et log dans le dossier telegraf. Et t'assurer que ton NAS accepte les connexions depuis le sous-réseau de ta Freebox.

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 !