bruno78

Bonjour @.Shad., j'ai mis en place ta solution pour l'accès à influxdb, c'est drôlement plus léger et moins contraignant. Donc top ! D'autant que le VPN OpenVPN refuse de se reconnecter lors de la déconnection "normale" après 24h (je ne sais pas pourquoi, il faut que je regarde ce point). Par contre, sur la machine cible (VPS OVH) j'ai le log nginx error.log pollué par les messages suivants : 2020/12/20 09:39:56 [warn] 12743#12743: *23692 a client request body is buffered to a temporary file /var/cache/nginx/client_temp/0000008526, client: 82.64.xxx.yyy, server: influxdb.ndd.tld, request: "POST /write?consistency=any&db=pi_telegraf HTTP/2.0", host: "influxdb.ndd.tld:443" 2020/12/20 09:40:20 [warn] 12743#12743: *23712 a client request body is buffered to a temporary file /var/cache/nginx/client_temp/0000008527, client: 82.64.xxx.yyy, server: influxdb.ndd.tld, request: "POST /write?consistency=any&db=fbx_telegraf_v8 HTTP/2.0", host: "influxdb.ndd.tld:443" Est-ce un problème (à part le log error.log qui deborde !) ? j'ai essayé quelques modifications dans la conf nginx sur les buffers, mais sans succès ... Constates-tu le même phénomène ? Comment fixer les bonnes valeurs de buffers nginx ? merci, bruno78

@Einsteinium bonjour, cette nuit, renouvellement attendu de 3 domaines indépendants via acme.sh en docker, mis en place il y a 2 mois et dont la date de renouvellement était donc cette nuit Sur les 3, 1 OK et 2 KO pour les 2 KO je précise tout de suite : pas de problème de clé chez OVH. après analyse des logs entre le OK et les 2 KO, je constate que pour les 2 KO le log me dit qu'il trouve un subdomain "_acme-challenge.ndd.tld" , ce qui n'est pas le cas pour le domaine pour lequel le renouvellement est OK. [Sun Dec 20 00:44:16 UTC 2020] _sub_domain='_acme-challenge' [Sun Dec 20 00:44:16 UTC 2020] _domain='_acme-challenge.ndd.tld' [Sun Dec 20 00:44:16 UTC 2020] Adding record [Sun Dec 20 00:44:16 UTC 2020] domain/zone/_acme-challenge.ndd.tld/record [Sun Dec 20 00:44:16 UTC 2020] GET [Sun Dec 20 00:44:16 UTC 2020] url='https://eu.api.ovh.com/1.0/auth/time' [Sun Dec 20 00:44:16 UTC 2020] timeout=30 [Sun Dec 20 00:44:16 UTC 2020] _CURL='curl --silent --dump-header /acme.sh/http.header -L -g --connect-timeout 30' [Sun Dec 20 00:44:16 UTC 2020] ret='0' [Sun Dec 20 00:44:16 UTC 2020] _ovh_p='[hidden](please add '--output-insecure' to see this value)' [Sun Dec 20 00:44:16 UTC 2020] data='{"fieldType":"TXT","subDomain":"_acme-challenge","target":"JKfeSWG7F4c5P7tqB7zbwHgktMBL_8za59AZROJ6NEE","ttl":60}' [Sun Dec 20 00:44:16 UTC 2020] POST [Sun Dec 20 00:44:16 UTC 2020] _post_url='https://eu.api.ovh.com/1.0/domain/zone/_acme-challenge.ndd.tld/record' [Sun Dec 20 00:44:16 UTC 2020] _CURL='curl --silent --dump-header /acme.sh/http.header -L -g ' [Sun Dec 20 00:44:16 UTC 2020] _ret='0' [Sun Dec 20 00:44:16 UTC 2020] Add txt record error. [Sun Dec 20 00:44:16 UTC 2020] Error add txt for domain:_acme-challenge.ndd.tld si maintenant je vais voir les zones DNS chez OVH, je m'aperçois que pour le domaine renouvellement OK il n'y a qu'un seul enregistrement TXT "_acme-challenge.ndd.tld", alors que pour les 2 domaines pour lesquels le renouvellement est KO, j'ai 4 enregistrements TXT "_acme-challenge.ndd.tld" avec 4 valeurs de clés différentes. n'y en t'il pas 3 de trop ? Est-ce pour cela qu'il pense détecter un sous-domaine _acme-challenge.ndd.tld ? faut'il les supprimer toutes les 4 ? ou juste 3 mais lesquelles ? Si tu as quelques lumières sur le sujet , merci d'avance Bruno78

Hypothèse : changement de version du paquet Docker dans le DSM7 ???? sinon je ne sais pas pourquoi .....

juste pour illustrer la mise à jour éventuelle de la requete, à vérifier :

ce que je veux dire c'est que sur NAS1, les données manquantes, sont celles qui relèvent de la section [[snmp.inputs]] de ton docker telegraf ?

Je ne me trompes pas : ce sont uniquement les données snmp qui ne passent pas, on est d'accord ? Peux-tu stp refaire le test avec les adresses passerelles, mais après il faut vérifier les requetes dans le dashboard. Si par exemple tu as des conditions du genre "where agent_host=NAS_IP" il faudra mettre également l'adresse de la passerelle au lieu de l'adresse du NAS.

@.Shad. evidemment c'est plus simple. Si je galère avec le VPN, je ferai ainsi. J'ai les telegrafs sur le NAS (nas_telegraf et fbx_telegraf), mais également un télégraf sur le RPi, qui passe par le VPN du NAS, .... moyennant là aussi l'ajout d'une route adequate ! Donc oui, c'est definitivement plus lourd et impactant que ta solution. Pourquoi n'y ai-je pas pensé avant ! (en tout cas l'exercice n'était pas ininteressant). @MilesTEG1 beaucoup de raisons en fait : instances docker pas mises en place au meme moment garder une certaine indépendance entre les instances (ne pas casser le monitoring Fbx sous pretexte de "bricoler" le nas telegraf) et puis et surtout pour la Fbx on a le problème de l'installation du Python, qui n'a pas été un long fleuve tranquile et s'est montré dependant à la version du docker telegraf. Donc séparation des variables 🙂 @Jeff777, pour l'url snmp.output : c'est aussi ce que j'avais en DSM6 (l'adresse locale). Et en passant en DSM7 ca ne marchait plus et j'ai été obligé de mettre l'adresse du reseau docker. Mais je reste en local sur la meme machine. Je n'ai pas d'exemple avec 2 machines.

@Jeff777, ok, alors vérifie ce que tu as du côté de l'agent snmp : ## ## Synology ## [[inputs.snmp]] # List of agents to poll agents = [ "172.20.0.1" ] 172.20.0.1 étant ma passerelle du réseau bridge utlisé par tes dockers de monitoring (data_export pour toi) @.Shad. pour mon info, le principe de la liaison TLS, c'est ce que tu expliques dans ton TUTO sur la centralisation des instance Docker avec Portainer ? Effectivement c'est peut-être plus simple à mettre en oeuvre qu'OpenVPN ...

@Jeff777 , oui j'ai eu des soucis en passant à DSM7 (si tu remontes plus haut, en page 12, il y a un certain nombre d'echanges avec @.Shad.) comment est configuré l'accès à influxdb dans ton telegraf.conf ? docker en mode bridge ou host ? je suis revenu en mode bridge, avec la configuration ci-dessous: ############################################################################### # 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 influxdb NAS local : urls = ["http://influxdb:8086"] @.Shad., oui c'est lourd, je ne sais pas si je vais garder cette conf vers un VPS/OVH. Compte tenu de la consommation mémoire d'influx entre autre, mon RPi 3 est un peu juste, c'est pour cela que j'ai tenté cette solution. Si trop lourd, je passerai sur un RPi4 en local. Et oui, je me suis servi de ton tuto OpenVPS sur VPS, donc normal que tu le reconnaisses ! Le VPN OpenVPS est directement monté sur le NAS (interface VPN client) vers le serveur OpenVPN sur le VPS. Le containeur Telegraf du NAS vise l'addresse IP privée (en 172.X.X.X) sur le VPS, ayant ajouté une route statique sur le NAS pour emprunter le VPN pour atteindre le VPS. Ouais, .... c'est lourd ! C'est un essai (d'autant qu'hier le VPN est tombé mais n'est pas remoté tout seul .... Pour info, enlever influx et grafan du NAS fait quasiment "économiser" 10% d'activité disque permenente .... sans compter l'économie de mémoire. Bruno78

@Jeff777, @.Shad., quel est le problème exactement ? je ne suis pas sûr d'avoir compris le détail de la configuration. De mon côté j'ai fait (pas terminé) quelques changements: la vDSM7 ne me sert que pour des tests ponctuels. Je ne la supervise pas, par contre il m'arrive de faire des tests de supervision à partir de cette vDSM7. considérant que ce n'est pas le job premier du NAS de faire du monitoring (même si il est capable de le faire on est d'accord), je "déporte" Grafana, Influxdb et Loki sur une VPS chez OVH, et je garde évidemment les process d'alimentation des données (telegraf, promtail, scripts perso) sur les entités concernées (NAS, RPi, VPS ). Le tout via un VPN OpenVPN entre le NAS et le VPS OVH. Dans cette supervision du NAS (docker telegraf sur le NAS), il y a bien sûr le monitoring de l'ensemble des dockers tournants sur le NAS. Bref, @Jeff777, comment puis-je t'aider ? Cdt Bruno78

@.Shad. : je te confirme (je viens de le refaire), que stopper la package Docker a pour conséquence de supprimer le link macvlan-swag, et donc tout ce qui suit ....

@EVOTk, tu dois créer une route vers un réseau / subnet, pas vers une machine / host individuelle. Sauf erreur de ma part, ta commande d'ajout de route devrait donc être a priori : ip route add 192.168.0.96/28 dev maclan-swag @.Shad. par ailleurs ce matin de bonne heure j'en ai profité pour regarder le problème de perte de connectivité avec le docker Pihole : sur un reboot complet du NAS, les interfaces et les routes remontent bien avec le timer originel de 60s dans la tache planifiée au demarrage. j'ai par contre reproduit le problème en faisant un stop / start du paquet Docker. Je ne sais pas si c'est réellement ce qui c'était passé pour moi à l'origine. Il y a peut-être d'autres cas dans lesquels cela arrive ? ... je continue le monitoring. Évidemment une solution pourrait être de relancer automatiquement la création de l'interface et du routage vers le docker PiHole en cas de détection de perte de connectivité, mais pour le moment je préfère laisser "en manuel" pour voir si cela se reproduit et en quelles circonstances. Bruno78

@EVOTk bonjour, je serais surpris que 192.168.0.100/24 représente 192.168.0.96 à 192.168.0.111 .... Le /24 représente l'ensemble de la plage 192.168.1.0 à 192.168.1.255. Si tu veux 16 adresses (14 adresses utilisables pour des hosts) de 192.168.0.96 à 192.168.0.111, il te faut un réseau en /28

Bonjour, (à propos du script, pas de nginx) j'utilise ce script depuis déjà un bon moment (pour le docker PiHole). Il est lancé au démarrage du NAS, moyennant un timer du 60secondes (sleep 60) pour être sûr que les interfaces réseau sont montées au moment de l’exécution du script. Or j'ai eu depuis quelques jour des déboires avec justement la résolution DNS, jusqu'à m’apercevoir que ce réseau n'était plus opérationel (link down et route absente). Il a suffit de le remettre up et recréer la route pour que cela reparte. => je ne sais pas pourquoi il était passer down, mais cela est concomitant dans le temps avec un reboot du NAS. J'ai donc passé le timer à 90sec, et rajouter via grafana une surveillance de l'accessibilité du docker Pihole (sinon tout le monde bascule sur le DNS secondaire et on ne se rend pas compte du problème tout de suite). => je vérifie cela au prochain reboot. Bruno78

Bonjour, je suis sur un DS918+, en DSM7 Beta avec cache SSD (2*MVNE montés en R/W). Aucun problème a priori.

@X260-dpaulet, D'où l'intérêt de la containairisation ..... merc pour ce message

Hello, avec un Pi3B, aucun soucis .... (et il ne fait pas que ça)

@Jeff777, non a priori ça ne résout pas le problème : msg="Unable to update container \"/fbx_py\": Error response from daemon: pull access denied for fbx_py, repository does not exist or may require 'docker login'. Proceeding to next." Par contre, une mise à jour periodique via un script shell lancé par une tache planifiée, ça doit pouvoir se faire. Bruno78

@Jeff777, je vois que tu galères pas mal avec ce fichu docker telegraf dans lequel on ajoute python. Je n'ai pas eu le temps de regarder watchover, donc je ne peux guère t'aider. Mais pour info, je suis en train de voir à remplacer, pour la freebox uniquement, le docker telegraf par un docker python. Je ne sais pas si cela pourrait rendre l'utilisation de watchover plus facile, car de toute façon même ainsi il faut légèrement modifier l'image et créer une image locale, mais cela se ferait via "docker build". Je vais voir si il y a des possibilités ... et jeter un coup d'oeil à Wacthover (mais il y a 11 pages de posts à lire .....) Cdt Bruno78

Bonjour, désolé un peu éloigné du forum ces derniers temps (je travaille à une version sans telegraf pour le monitoring de la freebox (remplacement du docker telegraf par un simple docker python; et je me frotte aux joies de l'exploitation des logs via promtail/loki .... ca prend du temps). Bref pour en revenir aux interfacex LAN/WAN de la Freebox, je les atteins simplement car l'API mis à disposition le permet, mais ce n'est pas du SNMP. Donc je ne vois pas comment transposer ici ... Cdt Bruno78

il y a un espace entre le -- et accountemail => supprimer ce caractère espace

@nebelnic bonjour, a priori le script est bien disponible en page 1, chap 6 du tuto Bruno78

@Jeff777, l'adresse MAC fixée pour le docker telegraf .... ne sert à rien ici. Je l'avais mise en place pour certains dockers en mode macvlan et donc pour lesquels l'adresse IP et l'adresse MAC sont visibles sur le réseau. C'est le cas en particulier de mon docker pihole. Mais ici pour telegraf .... aucun intérêt on est d'accord. C'est un reliquat. Bruno78

@Jeff777, pour ce que l'on veut faire ici, càd disposer d'une image telegraf incluant l'installation de Python3, la commande "docker commit" fait le boulot. Voici donc comment j'ai procédé : (les outputs sont tronqués car trop longs) 1) Je charge une image de telegraf vierge, je vérifie qu'il n'y a pas de python et j'y installe mon python3 selon la procédure du tuto : root@vdsm2:/volume1/docker/monitoring# cat docker-compose.yaml services: test_telegraf: image: telegraf:latest container_name: test_telegraf hostname: test_telegraf mac_address: d2:ca:ab:cd:00:06 networks: data_grafana: ipv4_address: 172.18.0.6 environment: - PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/bin:/sbin:/usr/local:/usr/src - TZ=CET volumes: - "/volume1/docker/dev3/telegraf/telegraf.conf:/etc/telegraf/telegraf.conf:ro" - "/volume1/docker/dev3/telegraf/py:/usr/local/py:ro mem_limit: 50M ports: - 5125:8125/udp - 5092:8092/udp - 5094:8094 restart: unless-stopped root@vdsm2:/volume1/docker/monitoring# root@vdsm2:/volume1/docker/monitoring# docker-compose up -d test_telegraf Creating test_telegraf ... done root@vdsm2:/volume1/docker/monitoring# docker images REPOSITORY TAG IMAGE ID CREATED SIZE telegraf latest 79fd1e5d0a8f 3 months ago 276MB root@vdsm2:/volume1/docker/monitoring# docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 0de5d8966d84 telegraf:latest "/entrypoint.sh tele…" 16 seconds ago Up 11 seconds 0.0.0.0:5092->8092/udp, 0.0.0.0:5094->8094/tcp, 0.0.0.0:5125->8125/udp test_telegraf root@vdsm2:/volume1/docker/monitoring# docker exec -it test_telegraf /bin/bash root@test_telegraf:/# python -V bash: python: command not found root@test_telegraf:/# python3 -V bash: python3: command not found root@test_telegraf:/# apt update root@test_telegraf:/# apt upgrade …. root@test_telegraf:/# dpkg --configure -a root@test_telegraf:/# apt-get install apt-transport-https ca-certificates curl gnupg-agent software-properties-common root@test_telegraf:/# wget https://bootstrap.pypa.io/get-pip.py root@test_telegraf:/# apt-get install python3-distutils root@test_telegraf:/# python3 get-pip.py --prefix=/usr/local root@test_telegraf:/# python3 -m pip install requests root@test_telegraf:/# pip install unidecode root@test_telegraf:/# python3 -V Python 3.7.3 root@test_telegraf:/# exit exit 2) je fais dessus un "docker commit -p <reference docker> <nom_nouvelle_image>". Cela produit une nouvelle image contenant toutes les modifications effectuées auparavant. L'option -p met en pause le docker pendant la création de la nouvelle image afin de garantir qu'il n'y ai pas d'incohérence dans le file system. root@vdsm2:/volume1/docker/monitoring# docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 0de5d8966d84 telegraf:latest "/entrypoint.sh tele…" 16 minutes ago Up 15 minutes 0.0.0.0:5092->8092/udp, 0.0.0.0:5094->8094/tcp, 0.0.0.0:5125->8125/udp test_telegraf root@vdsm2:/volume1/docker/monitoring# docker commit -p 0de5d8966d84 telegraf_py:latest sha256:e9ac730929f7698a4264ff762f2b86a34a28113a48fda598d065fa04a19260cf root@vdsm2:/volume1/docker/monitoring# docker images REPOSITORY TAG IMAGE ID CREATED SIZE telegraf_py latest e9ac730929f7 8 seconds ago 466MB telegraf latest 79fd1e5d0a8f 3 months ago 276MB root@vdsm2:/volume1/docker/monitoring 3) je modifie mon docker-compose.yaml pour utiliser cette nouvelle image version: "2" services: test_telegraf: image: telegraf_py:latest container_name: test_telegraf hostname: test_telegraf mac_address: d2:ca:ab:cd:00:06 networks: data_grafana: ipv4_address: 172.18.0.6 environment: - PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/bin:/sbin:/usr/local:/usr/src - TZ=CET volumes: - "/volume1/docker/dev3/telegraf/telegraf.conf:/etc/telegraf/telegraf.conf:ro" - "/volume1/docker/dev3/telegraf/py:/usr/local/py:ro" mem_limit: 50M ports: - 5125:8125/udp - 5092:8092/udp - 5094:8094 restart: unless-stopped 4) j'efface le docker mis à jour manuellement, et je relance le docker-compose avec la nouvelle image telegraf_py:latest root@vdsm2:/volume1/docker/monitoring# docker stop test_telegraf test_telegraf root@vdsm2:/volume1/docker/monitoring# docker rm test_telegraf test_telegraf root@vdsm2:/volume1/docker/monitoring# docker-compose up -d test_telegraf Creating test_telegraf ... done root@vdsm2:/volume1/docker/monitoring# 5) je vérifie les détails du nouveau docker : il a bien pris en compte l'image telegraf_py:latest root@vdsm2:/volume1/docker/monitoring# docker inspect test_telegraf [ { "Id": "a778a6d7d5e50a1e29837205d3fbe5710dafc2884f0f26e5cae09981b0737219", "Created": "2020-11-28T06:29:51.30628885Z", "Path": "/entrypoint.sh", "Args": [ "telegraf" ], …. "Env": [ "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/bin:/sbin:/usr/local:/usr/src", "TELEGRAF_VERSION=1.15.2", "TZ=CET" ], "Cmd": [ "telegraf" ], "ArgsEscaped": true, "Image": "telegraf_py:latest", "Volumes": { "/etc/telegraf/telegraf.conf": {}, "/usr/local/py": {} }, ….. } } } } ] root@vdsm2: 6) et enfin je vérifie que mon docker basé sur l'image commitée telegraf_py:latest contient le python fonctionnel : root@vdsm2:/volume1/docker/monitoring# docker exec -it test_telegraf /bin/bash root@test_telegraf:/# python3 -V Python 3.7.3 Voilà. Désolé c'était un peu long, mais je voulais être sûr que c'était bon. Donc pas besoin de docker save/load. Cdt Bruno78

alors a priori il serait conseillé de faire un docker commit -p ... avant le backup, et de ne pas le faire dans la partition / qui n'est pas taillée pour cela. Si on se met dans /homes ca ne pose pas de problème. J'essaie de mettre cela au clair ce weekend.