oracle7 Posté(e) le 3 octobre 2022 Posté(e) le 3 octobre 2022 @.Shad. Bonjour, Finalement pour ma question : J'ai trouvé le problème : l'option "com.docker.network.bridge.name" ne supporte pas un nom de réseau > 15 caractères sinon on récupère le message d'erreur. A toi de voir, mais il serait peut-être judicieux d'insérer dans ton TUTO cette précision pour éviter des déconvenues, non ? Cordialement oracle7😉 1 Citer
.Shad. Posté(e) le 3 octobre 2022 Auteur Posté(e) le 3 octobre 2022 @oracle7 Ah oui en effet j'ajouterai la précision, mon nom de réseau était bien plus court, je n'aurais pas imaginé. Et les messages d'erreur sont flous au possible. 0 Citer
MilesTEG1 Posté(e) le 3 octobre 2022 Posté(e) le 3 octobre 2022 il y a une heure, oracle7 a dit : @.Shad. Bonjour, Finalement pour ma question : J'ai trouvé le problème : l'option "com.docker.network.bridge.name" ne supporte pas un nom de réseau > 15 caractères sinon on récupère le message d'erreur. A toi de voir, mais il serait peut-être judicieux d'insérer dans ton TUTO cette précision pour éviter des déconvenues, non ? Cordialement oracle7😉 Tu mets cette option où dans ton docker-compose ? Car moi je nomme mes réseau avec une autre option, name: nom_du_reseau Par exemple avec le docker-compose de NextCloud que je vais installer prochainement : networks: nextcloud_network: ipam: driver: default config: - subnet: 172.31.0.0/16 gateway: 172.31.0.1 name: nextcloud_network Le nom le plus long que j'ai est : another_bridge_network La longueur dépasse les 15 caractères... 0 Citer
oracle7 Posté(e) le 3 octobre 2022 Posté(e) le 3 octobre 2022 @MilesTEG1 Bonjour, Désolé mais je crains que tu ne mélanges les choses. Pas grave ! 🤪 Ce n'est pas dans le docker-compose qu'il y a problème mais lorsque tu crées la première fois ton réseau bridge personnalisé : Soit tu passes par l'interface de docker dans DSM et là pas soucis. Soit tu utilises sous SSH en CLI la commande et là risque de soucis : docker network create -d bridge \ --subnet=172.18.0.0/24 \ --gateway=172.18.0.1 \ --opt "com.docker.network.bridge.name"="br_monitoring" \ monitoring Le problème que j'ai souligné se passe au niveau de l'option "com.docker.network.bridge.name" de cette dernière. Par exemple ici "br_monitoring" ne pose pas de problème car < 15 caractères. Par contre si dans l'option tu saisis par exemple : "br_nextcloud_network" tu auras l'erreur et pas de création du réseau. Pour l'intant, je n'ai pas recontré d'anomalies avec des noms "longs" pour les réseaux. Par exemple ici "monitoring". Donc dans ton cas "nextcloud_network", bien que faisant lui plus de 15 caractères, doit passer aussi. C'est donc juste le nom donné pour l'option de la commande CLI qui est limité à 15 car. Cela dit à mon humble avis une bonne pratique serait de ne pas dépasser 15 car dans tous les cas. Maintenant ce que j'en dit ... Est-ce plus clair comme cela ? Cordialement oracle7😉 0 Citer
MilesTEG1 Posté(e) le 3 octobre 2022 Posté(e) le 3 octobre 2022 il y a 28 minutes, oracle7 a dit : Bonjour, Désolé mais je crains que tu ne mélanges les choses. Pas grave ! 🤪 Ce n'est pas dans le docker-compose qu'il y a problème mais lorsque tu crées la première fois ton réseau bridge personnalisé : Soit tu passes par l'interface de docker dans DSM et là pas soucis. Soit tu utilises sous SSH en CLI la commande et là risque de soucis : docker network create -d bridge \ --subnet=172.18.0.0/24 \ --gateway=172.18.0.1 \ --opt "com.docker.network.bridge.name"="br_monitoring" \ monitoring Le problème que j'ai souligné se passe au niveau de l'option "com.docker.network.bridge.name" de cette dernière. Hello @oracle7 Ha ok tu passes par la création du réseau avant de faire ton docker-compose up -d. Est-ce vraiment utile ? Moi c'est Portainer qui se charge de créer le réseau avec le bout de code que je t'ai mis en exemple. Alors je vois juste une faille dans ma manière de procéder, c'est que mes réseaux sont en /16 et pas /24... donc je ne peux pas créer un 172.18.5.0/24 ça me fait une erreur, il faut avoir créer le 172.18.0.0/16 avant, et dans le yml je peux ensuite joindre le réseau 172.18.5.0/24, enfin je crois... Pour le moment je ne suis pas limité par ma manière de faire... Mais il se peut qu'un jour je doive faire comme toi, créer en amont chaque réseau. Ce qui serait effectivement plus propre ^^ PS : je viens de checker un de mes réseaux qui a le plus grand nom : root@Syno-DS920Plus:~# docker network inspect another_bridge_network [ { "Name": "another_bridge_network", "Id": "4a8ca8c60c6070d1ca170322d53415e30633bd919d757ae114dfe9b264696ca6", "Created": "2022-09-27T14:29:25.885019615+02:00", "Scope": "local", "Driver": "bridge", "EnableIPv6": false, "IPAM": { "Driver": "default", "Options": null, "Config": [ { "Subnet": "172.25.0.0/16", "Gateway": "172.25.0.1" } ] }, "Internal": false, "Attachable": false, "Ingress": false, "ConfigFrom": { "Network": "" }, "ConfigOnly": false, "Containers": { "04ee26bd5e6c9af971185845b04b6a6589849dda196916555d21e39d9dba1e52": { "Name": "uptime-kuma", "EndpointID": "a3f0e42c3cf4d24e16523bab80b954d0eda2dfefac4d78275f090d8f9ffc8d2f", "MacAddress": "02:42:ac:19:00:02", "IPv4Address": "172.25.0.2/16", "IPv6Address": "" } }, "Options": {}, "Labels": { "com.docker.compose.network": "another_bridge_network", "com.docker.compose.project": "uptime_kuma", "com.docker.compose.version": "2.5.1" } } ] En fait, via le docker-compose.yml, ça ne met pas de nom, mais un label !! C'est bien ça ? Est-ce vraiment gênant ? Les noms apparaissent pourtant bien : root@Syno-DS920Plus:~# docker network ls NETWORK ID NAME DRIVER SCOPE 5ed7dd5c7e9c acme_network bridge local 4a8ca8c60c60 another_bridge_network bridge local 334450caab79 bridge bridge local e83521a723b7 calibre-web_default bridge local bf0ac7a99d3d crowdsec_network bridge local e2dccb0c6a4a dashy_default bridge local b30ea1417684 gitea_network bridge local eaafac945a80 host host local adb21693ea83 macvlan-network macvlan local 9811a31122a1 monitoring_nas bridge local ffc1a99be78a none null local 50eb4078411a plex_tautulli bridge local 177958463c88 vaultwarden_network bridge local 0 Citer
MilesTEG1 Posté(e) le 3 octobre 2022 Posté(e) le 3 octobre 2022 Je viens de tester la création d'un réseau avec cette commande : docker network create -d bridge \ --subnet=172.33.0.0/24 \ --gateway=172.33.0.1 \ br_monitoring_blablalbaeazazazazazdadazdazd Le nom est bien présent : root@Syno-DS920Plus:~# docker network ls NETWORK ID NAME DRIVER SCOPE 5ed7dd5c7e9c acme_network bridge local 4a8ca8c60c60 another_bridge_network bridge local b23276c4eabc br_monitoring_blablalbaeazazazazazdadazdazd bridge local root@Syno-DS920Plus:~# docker network inspect br_monitoring_blablalbaeazazazazazdadazdazd [ { "Name": "br_monitoring_blablalbaeazazazazazdadazdazd", "Id": "b23276c4eabcb59217ce72f145e94d1f4873f04ca2f15c7dee515cde665d0d59", "Created": "2022-10-03T18:08:32.084529277+02:00", "Scope": "local", "Driver": "bridge", "EnableIPv6": false, "IPAM": { "Driver": "default", "Options": {}, "Config": [ { "Subnet": "172.33.0.0/24", "Gateway": "172.33.0.1" } ] }, "Internal": false, "Attachable": false, "Ingress": false, "ConfigFrom": { "Network": "" }, "ConfigOnly": false, "Containers": {}, "Options": {}, "Labels": {} } ] Du coup, pourquoi s'embêter à mettre l'option pour le nom quand tu crées en ligne de commande ? Moi je dois faire ça avec le docker-compose.yml via portainer, sinon ce dernier me nomme le réseau en ajoutant le nom du conteneur derrière... 0 Citer
oracle7 Posté(e) le 3 octobre 2022 Posté(e) le 3 octobre 2022 @MilesTEG1 Bonjour, il y a 6 minutes, MilesTEG1 a dit : Du coup, pourquoi s'embêter à mettre l'option pour le nom quand tu crées en ligne de commande ? Je vais laisser notre gourou @.Shad. te répondre sur ce point précis qu'il maitrise mieux que moi 😜. Pour ma part je procède ainsi : Création du réseau via la commande adhoc. Dans chaque conteneur je désigne le réseau à utiliser networks:RéseauX:external: true. Pour chaque conteneur, j'affecte une @IPv4 et une @MAC pour pouvoir le cas échéant atteindre directement le conteneur (même si ce n'est pas toujours utile je te l'accorde). Idem quand plusieurs conteneurs sont sur un même réseau, mais alors je laisse la résolution DNS par nom faire son boulot pour qu'ils communiquent entre eux. Bon tout cela est mal dit mais c'est le principe. Cordialement oracle7😉 1 Citer
.Shad. Posté(e) le 4 octobre 2022 Auteur Posté(e) le 4 octobre 2022 @MilesTEG1 L'option de nommage du bridge, c'est le nom de l'interface adhoc créée sur le NAS (172.x.0.1), pas le nom du réseau. Ca évite de se taper un nom d'interface généré aléatoirement. @oracle7 Tu es sûr de ta limite de 15 caractères ? Ca me semble peu, et @MilesTEG1 a visiblement des noms de réseau beaucoup plus longs que 15 caractères. 0 Citer
oracle7 Posté(e) le 4 octobre 2022 Posté(e) le 4 octobre 2022 @.Shad. Bonjour, Il y a 5 heures, .Shad. a dit : Tu es sûr de ta limite de 15 caractères ? Ca me semble peu, et @MilesTEG1 a visiblement des noms de réseau beaucoup plus longs que 15 caractères. Comme tu le dis c'est le nom de l'interface créée et pas le nom du réseau. Donc manisfestement les noms de réseaux, eux, supportent sans problème plus de 15 car. Dans tous les cas voici ma source : https://gist.github.com/brthor/b035052bad98e0a2d7c0e925d2d86a2a Cordialement oracle7😉 0 Citer
MilesTEG1 Posté(e) le 4 octobre 2022 Posté(e) le 4 octobre 2022 @oracle7 du coup il n’y a aucun intérêt à nommer l’interface, ce nom n’est jamais utilisé dans le docker-compose, non ? Quand je liste mes réseaux, que ce soit via portainer ou via la commande terminal , j’ai bien les noms que je mets dans mon docker-compose. ps : sinon Vu que j’ai migré mon paquet docker et ses conteneurs sur le ssd (mvne, oui je sais c’est bricoler 😆) j’ai recrée tous mes conteneur en spécifiant pour chacun une adresse iP définie que je note dans un fichier .md (je peux fournir le prototype 😉) . ca me permet de vérifier quels sont les conteneurs que j’isole des autres. pour le moment, chaque conteneur (ou groupe qui vont ensemble comme Plex et tautulli , ou bien la stack monitoring) ont un réseau à eux. jz n’arrive pas à me décider pour portainer et watchtower vu qu’ils ont besoin tous les deux du docker.sock : est-ce que je les laisse ensemble dans le bridge système (celui par défaut) ? Ou bien je crée un réseau dédié à chacun ? en tout ça la création du conteneur va plus vite sur le nvme 😆 0 Citer
oracle7 Posté(e) le 4 octobre 2022 Posté(e) le 4 octobre 2022 (modifié) @MilesTEG1 Bonjour, Il y a 2 heures, MilesTEG1 a dit : du coup il n’y a aucun intérêt à nommer l’interface, ce nom n’est jamais utilisé dans le docker-compose, non ? Effectivement pour ma part j'ai fait que suivre la préconisation de @.Shad. dans son TUTO, ni plus ni moins. EDIT : Pour info, le nom de l'interface réseau "br_xxxxxx" que l'on donne à la création du réseau bridge personalisé, apparaît (entre autre) dans le moniteur de ressources de DSM dans l'onglet Réseau. Sinon, de mon coté j'ai regroupé : Acme et Portainer dans un réseau unique synology-network Gotify et Watchtower dans un réseau gotify-network puisque ces derniers communiquent ensembles (enfin surtout watchtower vers gotify !). Maintenant, sauf erreur de ma part, ce n'est pas parce que des conteneurs utilisent le docker.sock qu'ils doivent partager le même réseau, cela ne me parait pas utile voire pas nécessaire ou impératif mais je peux me tromper. Cordialement oracle7😉 Modifié le 4 octobre 2022 par oracle7 0 Citer
oracle7 Posté(e) le 7 octobre 2022 Posté(e) le 7 octobre 2022 @.Shad. Bonjour, Pourrais-tu STP essayer de m'expliquer ce comportement (en espérant que je vais être clair dans sa description et que tu auras une réponse !) : Sous SSH, le répertoire /run/docker a les droits 0755 et le répertoire /run/docker/netns a les droits 0700 sachant que tous les deux sont root:root. J'accède sans problème au contenu de /run/docker/netfs. Dans le docker-compose de telegraf, je monte le volume " - /:/hostfs:ro " conformément à la doc de https://registry.hub.docker.com/_/telegraf pour monitorer le docker engine host. Maintenant, lorsque que je rentre dans le conteneur telegraf (docker exec -it telegraf bash), il m'est impossible d'accèder au répertoire /hostfs/run/docker/netns. Par ailleurs lors de l'exécution du conteneur telegraf, je récolte ce type d'erreur dans le log de telegraf, ce qui semble confirmer le point précédant et être l'origine de l'erreur : 2022-10-07T14:41:15+02:00 D! [outputs.influxdb_v2] Wrote batch of 119 metrics in 30.460364ms 2022-10-07T14:41:15+02:00 D! [outputs.influxdb_v2] Buffer fullness: 0 / 10000 metrics 2022-10-07T14:41:20+02:00 D! [inputs.disk] [SystemPS] => unable to get disk usage ("/hostfs/run/docker/netns/5fdd4d03d1d4"): permission denied 2022-10-07T14:41:20+02:00 D! [inputs.disk] [SystemPS] => unable to get disk usage ("/hostfs/run/docker/netns/a23d3dd3c162"): permission denied 2022-10-07T14:41:20+02:00 D! [inputs.disk] [SystemPS] => unable to get disk usage ("/hostfs/run/docker/netns/597f58313571"): permission denied 2022-10-07T14:41:20+02:00 D! [inputs.disk] [SystemPS] => unable to get disk usage ("/hostfs/run/docker/netns/cbb43ff4dc01"): permission denied 2022-10-07T14:41:20+02:00 D! [inputs.disk] [SystemPS] => unable to get disk usage ("/hostfs/run/docker/netns/5eeb93e81603"): permission denied 2022-10-07T14:41:20+02:00 D! [inputs.disk] [SystemPS] => unable to get disk usage ("/hostfs/run/docker/netns/c2c97a718e7d"): permission denied 2022-10-07T14:41:20+02:00 D! [inputs.disk] [SystemPS] => unable to get disk usage ("/hostfs/run/docker/netns/0984314f543e"): permission denied 2022-10-07T14:41:20+02:00 D! [inputs.disk] [SystemPS] => unable to get disk usage ("/hostfs/run/docker/netns/b06ebc0f4f59"): permission denied Pour me sortir, de ce type d'erreur, je suis obligé d'activer la commande : mount_points = ["/"] dans [[inputs.disk]] dans le fichier telegraf.conf : #---------------------------------------------------------- ## Read metrics about disk usage by mount point [[inputs.disk]] ## Set mount_points will restrict the stats to only the specified mount points. mount_points = ["/"] ## Ignore mount points by filesystem type. ignore_fs = ["tmpfs", "devtmpfs", "devfs", "iso9660", "overlay", "aufs", "squashfs"] Selon toi est-ce normal ? en SNMPV2c, il n'y avait pas besoin de cela. Pour mémoire je suis en SNMPv3. Je ne vois pas le lien et du coup je ne comprends pas et donc, saurais-tu STP éclairer ma lanterne ? D'avance Merci. Cordialement oracle7😉 0 Citer
.Shad. Posté(e) le 7 octobre 2022 Auteur Posté(e) le 7 octobre 2022 Tu as mis les variables d'environnement qui vont de paire avec le montage de volume ? Mon compose pour Telegraf sur mon VPS si ça peut t'aider, et pas eu besoin de décommenter le "/" dans [inputs.disk] : telegraf: image: telegraf container_name: telegraf networks: - net-monitoring # non-root user needed since 1.20.3 user: 1001:998 environment: - HOST_MOUNT_PREFIX=/hostfs - HOST_PROC=/hostfs/proc - HOST_ETC=/hostfs/etc - HOST_SYS=/hostfs/sys - HOST_VAR=/hostfs/var - HOST_RUN=/hostfs/run volumes: # config - /opt/monitoring/telegraf/telegraf.conf:/etc/telegraf/telegraf.conf:ro # disks input - /etc:/hostfs/etc:ro - /proc:/hostfs/proc:ro - /sys:/hostfs/sys:ro - /var:/hostfs/var:ro - /run:/hostfs/run:ro - /:/hostfs:ro # docker socket mounting - /var/run/docker.sock:/var/run/docker.sock:ro # additionnal MIBs - /var/lib/snmp/mibs:/usr/share/snmp/mibs:ro - /var/lib/snmp/mibs/ietf:/usr/share/snmp/mibs/ietf:ro - /var/lib/snmp/mibs/iana:/usr/share/snmp/mibs/iana:ro # system mounting - /run/udev:/run/udev:ro labels: - "com.centurylinklabs.watchtower.enable=true" depends_on: - influxdb restart: unless-stopped 0 Citer
oracle7 Posté(e) le 7 octobre 2022 Posté(e) le 7 octobre 2022 @.Shad. Bonjour, Oui, j'avais déjà bien mis les variables d'environnement pour les disk inputs. Au détail près du montage du volume /run/udev et des volumes de montages des MIBs, mon docker-compose est très proche du tien. D'ailleurs quelle est l'utilité de ce /run/udev ? Au passage, pour réinitialiser InfluxDB2 proprement, à part supprimer l'image et vider le contenu du dossier d'installation /volume1/docker/monitoring/influxdb2-data, y-a-t-il autre chose à nettoyer ailleurs ? J'ai perdu le dashbord fourni en standard avec influxDB2 et j'aimerai le retrouver. Je n'ai rien trouvé de vraiment semblable sur https://github.com/influxdata/community-templates . Cordialement oracle7😉 0 Citer
.Shad. Posté(e) le 8 octobre 2022 Auteur Posté(e) le 8 octobre 2022 /run/udev c'est pour pouvoir classer les disques par tag dans Grafana. Pour InfluxDBv2 aucune idée, je ne l'utilise pas. Repars d'une installation clean. 0 Citer
Dimebag Darrell Posté(e) le 31 mars 2023 Posté(e) le 31 mars 2023 (modifié) Bonjour tout le monde, Je reviens vers vous car j'ai remarqué ce type d'erreur dans mes logs sur telegraf. (container) 2023-03-31T11:56:03Z E! [outputs.influxdb] When writing to [http://localhost:8086]: failed doing req: Post "http://localhost:8086/write?db=telegraf": dial tcp 127.0.0.1:8086: connect: connection refused Après avoir checker les droits users dans influxdb Je vois ceci : user admin ---- ----- admin true user_telegraf false Mais malgré tout, mon monitoring fonctionne, et les données ont l'air d'être bien poussées (car dispo dans grafana) Une idée ? Modifié le 31 mars 2023 par Dimebag Darrell 0 Citer
.Shad. Posté(e) le 31 mars 2023 Auteur Posté(e) le 31 mars 2023 Il y a 5 heures, Dimebag Darrell a dit : Mais malgré tout, mon monitoring fonctionne, et les données ont l'air d'être bien poussées (car dispo dans grafana) Tu es sûr que ce sont des données récentes que tu vois ? On peut se faire avoir avec les tables, en revanche sur les graphiques c'est plus évident. Pour moi y a une erreur dans ton paramétrage, sauf si Telegraf et InfluxDB sont en mode host. Si pas le cas, c'est normal que la connexion soit refusée, il n'y a rien sur le port 8086 du conteneur Telegraf. Ton instance Telegraf devrait pousser les données vers http://influxdb:8086, où influxdb est le nom du conteneur InfluxDB et où les deux conteneurs Telegraf et InfluxDB sont dans le même réseau bridge. 0 Citer
Dimebag Darrell Posté(e) le 31 mars 2023 Posté(e) le 31 mars 2023 telegraph, correspond aux info venant des traps snmp du syno. par exemple CPU load sur mon syno, sachant que j'ai détecté le problème hier soir... néanmoins, comment je peux corriger cette erreur ? J'ai essayé en faisant un GRANT ALL on.... TO... sur le user de la db, mais je n'ai pas vu les droits changer 0 Citer
.Shad. Posté(e) le 1 avril 2023 Auteur Posté(e) le 1 avril 2023 Je ne vois pas le rapport entre ta réponse et ma réponse. 😕 Il faut que tu commences par éclaircir les points que j'ai soulignés dans ma réponse. A moins tu aies créé un nouvel utilisateur, ou une nouvelle db Telegraf, il n'y a aucune raison d'aller changer les permissions des utilisateurs d'InfluxDB sur leur base de donnée. 0 Citer
Dimebag Darrell Posté(e) le 1 avril 2023 Posté(e) le 1 avril 2023 @.Shad. Dans ma réponse, je montre que les données arrivent toujours bien vers influxdb --> grafana. les données sont à jours. Par contre, lorsque je regarde les droits des user dans influxDB, je vois ceci ser admin ---- ----- admin true user_telegraf false J'ai essayé de faire un GRANT ALL ON monitoring_telegraf (nom de la db) TO user_telegraf. Le user reste tjs en false... ! (donc aucun droit admin) 0 Citer
.Shad. Posté(e) le 1 avril 2023 Auteur Posté(e) le 1 avril 2023 (modifié) C'est normal qu'il ne soit pas admin. L'utilisateur est sensé avoir tous les droits sur la base de donnée qui lui est associée, c'est ce que tu fais avec GRANT ALL TO ... ON ... Pas avoir tous les droits sur toutes les bases de données. Par défaut, le seul utilisateur admin est celui spécifié dans ton fichier compose lors de la création initiale du conteneur. Le problème est là où je l'ai signalé, si c'était un problème de droit tu n'aurais pas eu un "connection refused" mais un "permission denied" ou équivalent. Modifié le 1 avril 2023 par .Shad. 0 Citer
Dimebag Darrell Posté(e) le 1 avril 2023 Posté(e) le 1 avril 2023 @.Shad. user admin ---- ----- admin true user_telegraf false J'essaie de reconstituer l'idée, que signifie alors "false" pour user_telegraf ? D'où viendrait le problème alors ? la solution, repartir de 0 et refaire complètement le container et ses DBs ? 0 Citer
.Shad. Posté(e) le 1 avril 2023 Auteur Posté(e) le 1 avril 2023 Ca veut juste dire qu'admin est admin, et que user_telegraf n'est pas admin. Rien de plus normal. Pourquoi tout recommencer, je t'ai posé des questions (sans point d'interrogation je reconnais) dans ma première intervention : Il y a 22 heures, .Shad. a dit : Pour moi y a une erreur dans ton paramétrage, sauf si Telegraf et InfluxDB sont en mode host. Si pas le cas, c'est normal que la connexion soit refusée, il n'y a rien sur le port 8086 du conteneur Telegraf. Ton instance Telegraf devrait pousser les données vers http://influxdb:8086, où influxdb est le nom du conteneur InfluxDB et où les deux conteneurs Telegraf et InfluxDB sont dans le même réseau bridge. Donc en reformulant : Est-ce qu'InfluxDB et Telegraf sont en mode bridge ? Si oui, est-ce que les deux conteneurs dans le même réseau bridge ? 0 Citer
Dimebag Darrell Posté(e) le 2 avril 2023 Posté(e) le 2 avril 2023 Il y a 17 heures, .Shad. a dit : Ca veut juste dire qu'admin est admin, et que user_telegraf n'est pas admin. Rien de plus normal. Pourquoi tout recommencer, je t'ai posé des questions (sans point d'interrogation je reconnais) dans ma première intervention : Donc en reformulant : Est-ce qu'InfluxDB et Telegraf sont en mode bridge ? Si oui, est-ce que les deux conteneurs dans le même réseau bridge ? Donc en reformulant : Est-ce qu'InfluxDB et Telegraf sont en mode bridge ? oui Si oui, est-ce que les deux conteneurs dans le même réseau bridge 0 Citer
.Shad. Posté(e) le 2 avril 2023 Auteur Posté(e) le 2 avril 2023 Tu peux copier-coller ici le contenu de [[outputs.influxdb]] de ton fichier de configuration telegraf.conf ? 0 Citer
Messages recommandés
Rejoindre la conversation
Vous pouvez publier maintenant et vous inscrire plus tard. Si vous avez un compte, connectez-vous maintenant pour publier avec votre compte.