.Shad.
-
Compteur de contenus
6673 -
Inscription
-
Dernière visite
-
Jours gagnés
154
Tout ce qui a été posté par .Shad.
-
@RF-Atomik Peux-tu taper en SSH : docker exec -it telegraf ping 172.19.0.1 - Ici telegraf est le nom du conteneur Telegraf - Ajouter sudo devant la commande si tu n'es pas connecté en root Est-ce que le ping est fonctionnel ?
-
@RF-Atomik Le nom de la communauté est le bon ? Si tu l'as changé, il faut le changer dans la partie [[inputs.snmp]] de la partie Synology dans le fichier telegraf.conf (On ne voit pas tes images) @Jeff777 Tu peux remettre ton fichier docker-compose pour telegraf sur le Rpi ?
-
Bon ben tu n'as qu'à le générer sur le NAS, c'est exactement le même (évite de prendre un ancien backup, la fichier évolue avec les màj), tu as juste à taper : docker run --rm telegraf telegraf config > telegraf.conf.rpi Tu le transfères et tu le renommes correctement sur le Rpi. Je suis quand même très étonné de ce problème que tu rencontres, mais je ne vois pas comment le debugger.
-
@RF-Atomik Passe par l'IP passerelle comme conseillé dans le tutoriel, comme ça tu n'es pas dépendant de l'IP locale. Dans le tutoriel je choisis le réseau 172.18.0.0, mais quelque soit le réseau choisi, c'est la première IP du réseau qui est la passerelle, 172.18.0.1 dans mon cas. Normalement si tu as autorisé la plage d'IP 172.16.0.0/255.240.0.0 dans le pare-feu du NAS ça devrait fonctionner. Pour ma part je supervise un autre NAS via son IP locale depuis le Telegraf de mon NAS principal sans problème.
-
Aucune raison que ça ne fonctionne plus, es-tu sûr d'avoir déclaré le volume correctement dans la section volumes du fichier docker-compose ?
-
@Jeff777 Si tu te log en root et que tu tapes la commande originelle : docker run --rm telegraf telegraf config > telegraf.conf Le fichier ne se crée pas non plus ? (penser à supprimer l'ancien avant) @RF-Atomik 10.0.10.41 c'est l'IP du NAS hôte ? ou d'un autre NAS ?
-
J'ai les mêmes messages, mais les volumes non utilisés sont liés à un autre conteneur, c'est une conséquence. Un conteneur crée des volumes, on peut voir ces volumes dans le Dockerfile : On voit tout en bas : VOLUME /config /sync Ca veut dire que si l'on ne monte qu'un des deux volumes, par exemple /config, dans notre fichier docker-compose, Docker va créer ce qu'on appelle un "volume" Docker qui comprendra les fichiers que l'image place dans /sync, et ce sera un dossier créé dans les répertoires dédiés à Docker, dans /volume1/@docker/... (qui est un lien symbolique de /var/packages/Docker/...) Ces dossiers sont non persistants, donc à chaque fois que le conteneur est supprimé, le volume n'est plus utilisé, à la recréation du conteneur, un nouveau volume sera créé. D'où la liste de volumes non utilisés, il suffit d'identifier quel volume de quelle image tu ne définis actuellement pas dans tes fichiers docker-compose. Pour éviter qu'ils aient un nom bâtard, et que les données persistent, c'est simple : version: ... services: blabla... ... volumes: - exemple:/etc ... volumes: exemple: Ca va te créer un volume Docker qui aura pour chemin : /volume1/@docker/volumes/exemple/_data/... Pour l'histoire des instances multiples, il faudrait aller voir sur le Github de Watchtower, je l'utilise sur 4 machines différentes et toutes ont ce message après mise à jour.
-
Ok je pense voir le problème pour docker-compose, l'installation a été faite pour l'utilisateur, pas le système. Donc tu tapes : pip3 uninstall docker-compose Je pense que tu avais oublié le "sudo" devant quand tu l'as installé. Ca n'explique pas les problèmes liés à Docker par contre. Donc je t'invite à tout désinstaller (suivre les liens données plus avant, modulo la commande sans le sudo au-dessus). Puis tu réinstalles tout en étant connecté avec pi, pas avec root. Toutes les commandes sont précédées de sudo. Logiquement ça devrait te permettre de repartir sur une base saine.
-
Ouh le vilain ! Bienvenue 😉
-
Ça : Ton Rpi veut absolument être en mode swarm. Ce n'est pas normal.
-
En quoi c'est normal ? Tu as dit : Si le proxy inversé est sur le NAS1, drive aussi bien que video.alexisg.com doivent pointer sur le proxy inversé. Là tu sollicites le port 443 du NAS2, y a rien dessus donc il te renvoie le port DSM du protocole demandé, ici HTTPS... On s'en balance du certificat sur NAS2 sauf pour les services non proxiables du NAS2 comme le transfert de données Drive sur le port 6690, Active Backup for Business, etc...
-
Que donnent : nslookup video.alexisg.com IP_locale_NAS nslookup drive.alexisg.com IP_locale_NAS
-
Je ne vois pas ce qui peut clocher honnêtement, à la limite ce que tu peux essayer de faire : - désinstaller docker-compose sudo pip uninstall docker-compose - désinstaller complètement Docker : https://docs.docker.com/engine/install/debian/#uninstall-docker-engine - réinstaller via : https://docs.docker.com/engine/install/debian/#install-using-the-convenience-script Et si vraiment ça ne marche toujours pas, tu peux toujours générer le fichier sur ton NAS et l'envoyer sur ton Raspberry Pi.
-
Tu peux taper : journalctl -u docker.service Et poster les logs ici.
-
Essaie avec pi peut-être oui, je suis jamais en root sur mon Rpi perso.
-
Chez moi : cd /opt/containers/telegraf docker run --rm telegraf telegraf config | sudo tee telegraf.conf La configuration s'affiche à l'écran (pour ça que je n'ai pas mis les impressions d'écran, ça dégage toutes les anciennes commandes). Si je fais un : ls -l EDIT : Tu as supprimé le dossier avant de retester ?
-
On va mettre de côté pour l'instant le problème de Portainer agent, tu as forcément des logs dans Telegraf, regarde dans le fichier telegraf.conf du Rpi, dans la première partie, avant InfluxDB, tu as une ligne : # debug = false Tu décommentes et tu passes la valeur à true : debug = true Tu redémarres le conteneur, puis tu tapes : docker logs telegraf -f
-
Ca a l'air bon de ce côté-là, pour moi le plus important ce sont les logs de Telegraf sur le Rpi, il précise généralement pourquoi il n'arrive pas à envoyer les données.
-
@Jeff777 Pour Portainer voir ma réponse juste avant la tienne. Pour l'url de InfluxDB, est-ce que tu as bien translaté le port 8086 sur le NAS depuis le conteneur : ports: - 8086:8086 dans la description du service InfluxDB dans le fichier docker-compose ?
-
C'est une erreur qui s'est glissée dans la refonte, c'est bien : networks: monitoring: external: true et pas : networks: external: name: monitoring J'ai aussi corrigé une erreur dans le docker-compose de Grafana, pour lequel j'avais oublié d'ajouter : networks: - monitoring Fallait bien que quelqu'un me debug tout ça @Lestat69, c'est tombé sur toi. 😄 ✌️ @Jeff777 : Tu peux renommer le endpoint que tu as créé, tu cliques sur "docker-swarm" et tu changes le nom pour ce que tu veux tout simplement. Ensuite quand tu cliques sur "Home" dans le menu latéral tout en haut, normalement tu as la liste de tes endpoints :
-
Oui et non, en fait j'ai déjà eu le cas où une indexation restait bloquée, et le fait de relancer la machine résolvait le problème. Dans les faits il aurait peut-être suffi de relancer le service d'indexation, mais il y a parfois des services secondaires qui sont impliqués. Bref tant mieux si tu as résolu ton problème.✌️ -
Regarde ce qu'il y a dans /var/log/messages, tu y trouveras peut-être des informations plus concrètes. Piste à 2 balles : As-tu réessayé de relancer le NAS ?
-
Bienvenue parmi nous. 🙂
-
A partir du moment où le périphérique sur lequel tu visualises tes vidéos peut lire nativement tes vidéos 4K UHD (ça peut être ta TV Samsung, ou une android box reliée en HDMI à ta TV) la seule chose qui va jouer ce sont les débits sur ton réseau local. Un DS215j est compatible Gigabit, et même s'il ne l'était pas tout à fait, ce serait amplement suffisant pour ton utilisation (je crois qu'on monte au max à 80 Mbps sur les grosses vidéos 4K UHD, pour une bande passante de 1 Gbps = 1000 Mbps). Est-ce que tu rencontres des ralentissements en l'état ? Tu ne parles pas d'éventuels ralentissements ou saccades à la lecture, et si cela arrivait ce serait probablement la TV qu'il faudrait mettre en cause plus que ton NAS. 🙂
-
Welcome !