[TUTO] Monitoring réseau (Telegraf + InfluxDB 1.8 + Grafana)

[bebert73]

il y a 11 minutes, oracle7 a dit :

... même si je ne vois pas de prime abord l'intérêt d'avoir des accès différents en LE ou LS sur un même bucket.

Pour la sécurité :

• Grafana est sensé ne faire que "lire" les datas --> Donc lecture seul
• Telegraf est sensé écrire --> Lecture/Ecriture

Si ton service Grafana est vérolé ou que tu fais des bêtises, l'écriture ne sera pas possible.

PS :  En vrais dans mes docker je rajoute toujours l'update auto avec watchtower.

Modifié le 19 février 2022 par bebert73

[oracle7]

@bebert73

Bonjour,

Merci pour cet éclaircissement vis à vis de grafana même si je ne vois pas comment grafana pourrait aller écrire dans la BD Influx.

Pour Watchtower, tous mes conteneurs sont en update auto avec notification de MàJ par Gotify.

Cordialement

oracle7😉

Modifié le 19 février 2022 par oracle7

[bebert73]

Il y a 3 heures, oracle7 a dit :

J'ai hâte de voir comment tu implémentes le SNMP car je monitore par ce biais ma Livebox.

Bon à l'instant T SNMP fonctionne avec telegraf en 1.20.4 en suivant la config SNMP de @.Shad.

[MilesTEG1]

Hello 🙂

En lisant vos derniers échanges, je me dit que Grafana n'est plus utile du tout avec InfluxDB 2, non ?

[.Shad.]

Beaucoup moins, InfluxDB embarque tout un panel de visualisations mais reste moins complet, quand j'ai testé il y a quelques mois, que Grafana.

Après tu peux construire ton tableau sur InfluxDB et copier/coller la requête FluxQL sur Grafana.

@bebert73 Je ne vois aucune raison que ton Telegraf supervise le NAS si tu ne passes pas par SNMP et que tu es en bridge. Un moyen simple est de vérifier si les interfaces remontées par le input.net sont exactement les mêmes que celles pollées par l'agent SNMP. Si oui, je ne me l'explique pas.

[bebert73]

Salut @.Shad. !

Alors on vas rester sur un mystere car c'est bien fonctionnel  (petit comparatif infludb sans SNMP et les data DSM):

 

@MilesTEG1 Je rejoins @.Shad. pour la version actuelle de Influxdb, on peut faire un dashboard mais il n'y a pas de moyen d'extraire les rendus ou de trop modifier le dashboard en profondeur. Par contre le WebUI Influxdb devient indispensable pour fair tes query dans grafana.

Je test un peu influxdb 2.x :
Le truc qui est vraiment bien pensé c'est les templates : Ce sont des templates Dashboard/Bucket(db)/et config telegraf réunis !

Tu peux mettre en variable le nom de ton bucket aussi comme ça sur un même dashboard, en un click tu change de database (pas facile a expliqué mais bien pensé).

Quelques dashbord que j'ai importé en 5 min :

[.Shad.]

@bebert73 Est-ce que tu utilises les variables HOSTFS pour translater dans le conteneur les dossiers système du NAS ? Car pour le coup ce n'est pas sensé fonctionner sans ça, et même l'utilisation de la RAM n'est pas forcément une preuve irréfutable.

Mais si le measurement "net", qui correspond aux données pollées par le plugin inputs.net de Telegraf, donne toutes les interfaces de ton NAS et pas celle du conteneur, alors oui c'est indéniable ça fonctionne.

Par exemple, chez moi j'ai Telegraf en host, par facilité, si regarde les interfaces de "net" j'ai celles du NAS :

En bridge, j'aurais peut-être l0 et eth0, c'est tout.

Modifié le 21 février 2022 par .Shad.

[bebert73]

Salut @.Shad.

C'est bien du bridge (et je n'utilise pas les variables HOSTFS).

De tout de façon j'ai mis en place le SNMP pour avoir les infos complémentaire mais de base il y a deja pas mal de chose.

@oracle7

Si tu peux me partager ta config SNMP pour SRM (avec les mibs) je suis preneur :).

[oracle7]

@bebert73

Bonjour,

il y a 55 minutes, bebert73 a dit :

i tu peux me partager ta config SNMP pour SRM (avec les mibs) je suis preneur :).

Je ne comprends pas pour SRM il n'y a rien de particulier en soit et ce sont les mêmes MIBs que DSM. Il n'y en a qu'une seule en plus : /usr/syno/share/snmp/mibs/SYNOLOGY-PORT-MIB.txt.

Tu as juste besoin de définir un agent spécifique (@IP locale du routeur) au routeur (SRM) dans le fichier telegraf.conf à la rubrique INPUT PLUGINS > Synology > [[inputs.snmp]]

Tu ajoutes aussi ceci /

Citation

  #----------------------------------------------------------
  ## Ethernet Ports SRM
  #----------------------------------------------------------
  [[inputs.snmp.table]]
    oid = "SYNOLOGY-PORT-MIB::ethPortTable"
    [[inputs.snmp.table.field]]
      is_tag = true
    oid = "SYNOLOGY-PORT-MIB::ethPortIndex"

 

Cordialement

oracle7😉

[.Shad.]

@Jeff777 @oracle7 @MilesTEG1 J'ai pu enquêter un peu sur le pourquoi du comment des erreurs.
Depuis la 1.21, Telegraf n'utilise plus le module snmptranslate mais "gosmi" pour parser les modules.
Il se trouve que gosmi est beaucoup moins tolérant que snmptranslate concernant les éventuelles erreurs dans les fichiers MIB. Et d'après le maintainer de l'image, beaucoup des MIB embarqués par défaut avec le système (pas ceux de Synology) contiennent des erreurs de syntaxe, des accolades, points virgule et autres caractères de fin de ligne manquants par exemple.

En ne chargeant pas certains d'entre eux, j'ai réussi à faire fonctionner Telegraf 1.21+, mais au prix de la perte d'un nombre important de panels sur Grafana.

A priori, la version 1.22 (dev) devrait corriger une partie des soucis, dans le sens où Telegraf ne sera toujours pas capable de lire ces fichiers, mais les erreurs n'empêcheront pas la bonne exécution de Telegraf outre mesure.

Une demi-solution donc, pour ma part je reste sur la 1.20.4 pour l'instant.

@bebert73 Si tu es prêt à partager ton dashboard ce serait cool, j'ai commencé à jouer avec InfluxDB2 et honnêtement, même si je pense que la syntaxe "script" est plus facile à comprendre, tous les petits réglages de Grafana me manquent (changer facilement des unités (genre kilobytes vers kibibytes), les labels, les transformations, etc...).

Ca me permettrait de voir comment tu manipules ça. 🙂

 

Modifié le 4 mars 2022 par .Shad.

[faluorn]

Bonjour,

Depuis quelques temps, mon telegraf n'arrive plus à communiquer avec mon instance influx db.

J'ai bien suivi le tutoriel pas à pas (en tous cas il me semble). Dans le doute, j'ai supprimé mes conteneurs pour tout recommencer from scratch.

Voici l'erreur que j'ai :

2022-03-04T12:29:10Z E! [outputs.influxdb] When writing to [http://influxdb:8086]: Post "http://influxdb:8086/write?consistency=any&db=nas_telegraf": dial tcp: lookup influxdb on 127.0.0.11:53: no such host

Sachant que j'ai respecté le tutoriel et que donc mes conteneurs sont dans le réseau "monitoring" et que je n'ai donc indiqué aucune adresse IP.

La connexion entre grafana et mon influxdb fonctionne et lorsque je veux explorer la db, grafana me propose bien les champs tels qu'indiqués dans les fichier MIB de synology.

J'avoue, je galère un peu...

Merci d'avance pour tout aide que vous pourriez m'apporter 🙂

 

[oracle7]

@faluorn

Bonjour,

Tu n'aurais pas mis à jour l'image d'influxDB par hasard ?

Si tu est passé en v2.x de l'image alors c'est normal que tu ais des erreurs. Il faut bien rester en v1.8.x.

Cordialement

oracle7😉

 

[.Shad.]

@faluorn Bonne suggestion de @oracle7, on verra pour la suite si ce n'est pas ça.
Il y a eu des changements (majeurs) au niveau de Telegraf aussi.

Normalement le tutoriel a été màj, n'hésite pas à comparer avec ce que tu as mis en place.

[faluorn]

Bonjour

@.Shad., @oracle7

Merci pour vos réponses.

Je confirme que InfluxBD est bien "forcé" en version 1.8, comme indiqué dans le tutoriel.

Voici le fichier compose que j'utilise pour monter InfluxDB

version: '2.1'
services:

    influxdb:
        image: influxdb:1.8
        container_name: influxdb
        networks:
            - monitoring
        environment:
            - INFLUXDB_DB=nas_telegraf
            - INFLUXDB_ADMIN_USER=admin
            - INFLUXDB_ADMIN_PASSWORD=mon_super_mot_de_passe_admin
            - INFLUXDB_USER=nas_telegraf
            - INFLUXDB_USER_PASSWORD=mon_super_mot_de_passe
            - INFLUXDB_HTTP_AUTH_ENABLED=true
        volumes:
            - /volume1/docker/influxdb/data:/var/lib/influxdb
        restart: unless-stopped
        
networks:
    monitoring:
        external: true

@.Shad.

Je vais, je pense, tout supprimer et recommencer from scratch (encore) pour être sur d'avoir suivi toutes les étapes. Mais j'ai déjà fait cela plusieurs fois il y a quelques mois sans avoir réussi à solutionner le problème (qui date donc d'il y a plusieurs mois déjà, mais j'avais d'autres priorités)

Si entre temps vous avez d'autres suggestion, je suis preneur 🙂

Merci!

[Jeff777]

Bonjour

il y a 8 minutes, faluorn a dit :

image: influxdb:1.8

Il faut mettre : image: "influxdb:1.8"

Edit : Du moins c'est ce qui fonctionne chez moi. Mais effectivement dans mes autres containers je n'ai pas les guillemets 🙄

Modifié le 7 mars 2022 par Jeff777

[.Shad.]

@faluorn Avant de tout recommencer on peut faire quelques tests :

Tu tapes en SSH sur le NAS :

docker exec -it telegraf nslookup influxdb

telegraf étant le nom de ton conteneur Telegraf.

Tu nous donnes le résultat que tu obtiens.

Visiblement c'est un problème de résolution DNS, peut-être sur ton NAS.
Quels sont les DNS utilisés par ton NAS ?

@Jeff777 Pas besoin des guillemets

Modifié le 7 mars 2022 par .Shad.

[faluorn]

@.Shad.

Il y a 1 heure, .Shad. a dit :

docker exec -it telegraf nslookup influxdb

J'ai ceci comme erreur :

OCI runtime exec failed: exec failed: container_linux.go:367: starting container process caused: exec: "nslookup": executable file not found in $PATH: unknown

J'ai quand même relu le tutoriel et j'ai remarqué qu'une section avait été rajoutée pour la gestion des droits.

J'ai donc créé le groupe docker et l'utilisateur telegraf.

Par contre, quand je veux changer les droits d'accès de mes répertoires, je n'ai que la possibilité de changer le groupe et pas d'ajouter un utilisateur. Est-ce normal?

De plus, je n'ai maintenant plus accès aux logs de influxDB...?

Et mon télégraf me donne comme erreur

2022-03-07T10:29:00Z E! [inputs.snmp] Error in plugin: agent 192.168.0.202: performing get on field sysName: Request timeout (after 3 retries)

et j'ai cette ligne pour toutes les données que je tente de récupérer.

Quand je cherche dans mon telegraf.conf, je trouve ceci pour le champ "sysName" :

   #  System name (hostname)
   [[inputs.snmp.field]]
     is_tag = true
     name = "sysName"
     oid = "RFC1213-MIB::sysName.0"

Comme DNS, j'ai suivi un tutoriel de ce site afin de configurer manuellement mes DNS via le package DNS server de Synology. Je n'ai pas de soucis pour aller sur internet ni pour accéder à mes applications via une URL. As-tu besoin des détails de cette configuration-là?

Encore merci pour vos réponses!

[.Shad.]

il y a une heure, faluorn a dit :

Par contre, quand je veux changer les droits d'accès de mes répertoires, je n'ai que la possibilité de changer le groupe et pas d'ajouter un utilisateur. Est-ce normal?

Non c'est pas normal, attention que c'est un menu déroulant et que DSM fait apparaître les groupes en premier (chez moi en tout cas).

il y a une heure, faluorn a dit :

De plus, je n'ai maintenant plus accès aux logs de influxDB...?

Attention que la modif de propriété ne doit être fait que pour Telegraf.
Si tu as fait cette modification sur le dossier de tête et que tu as également des fichiers pour InfluxDB ou Grafana dans le même dossier, ça va mettre le bazar sur les permissions.

il y a une heure, faluorn a dit :

Et mon télégraf me donne comme erreur

A priori, c'est un timeout, donc ce n'est pas un problème de pare-feu, sinon ce serait refusé.
Est-ce que tu n'as pas changé le nom de la communauté SNMP ?
Sinon, si ton réseau est en 172.18.0.0 par exemple, tu mets l'IP 172.18.0.1 au lieu de 192.168.0.202, et il faut s'assurer que le pare-feu du NAS autorise les requêtes pour les IP 172.16.0.0/255.240.0.0

il y a une heure, faluorn a dit :

Comme DNS, j'ai suivi un tutoriel de ce site afin de configurer manuellement mes DNS via le package DNS server de Synology. Je n'ai pas de soucis pour aller sur internet ni pour accéder à mes applications via une URL. As-tu besoin des détails de cette configuration-là?

Un conteneur en bridge utilise la résolution DNS de son hôte, et a en plus la possibilité de résoudre en son sein les noms des autres autres conteneurs sur le même bridge personnalisé.
Si la commande nslookup n'est pas accessible dans Telegraf, on ne pourra pas vérifier directement.

[faluorn]

Bonjour @.Shad.

il y a 10 minutes, .Shad. a dit :

Non c'est pas normal, attention que c'est un menu déroulant et que DSM fait apparaître les groupes en premier (chez moi en tout cas).

J'ai d'abord les groupes et ensuite les utilisateurs. Mais je ne peux choisir qu'un seul élément : soit un propriétaire de type groupe, soit un propriétaire de type user. Pas les deux.

il y a 11 minutes, .Shad. a dit :

Si tu as fait cette modification sur le dossier de tête et que tu as également des fichiers pour InfluxDB ou Grafana dans le même dossier, ça va mettre le bazar sur les permissions.

J'avais effectivement mis le bazar. J'ai supprimé le répertoire et recréé, j'ai donc accès aux logs.

 

il y a 12 minutes, .Shad. a dit :

Est-ce que tu n'as pas changé le nom de la communauté SNMP ?

Si, j'ai fait cela. J'ai adapté dans l'interface DSM relative à SNMP et j'ai mis le même nom dans le fichier de configuration de telegraf. J'ai le sentiment que Telegraf n'arrive pas à récupérer les données MIBdu NAS. Est-ce possible cela?

Est-ce possible d'aller écrire manuellement une donnée dans InfluxDB pour voir si elle est affichée via Grafana? J'aimerais voir où se trouve l'erreur : entre mon NAS et Telegraf ou entre mon graphe et InfluxDB.

J'ai deux erreurs de type réseau/DNS dans mes logs telegraf :

2022-03-07T12:58:05Z E! [outputs.influxdb] When writing to [http://influxdb:8086]: Post "http://influxdb:8086/write?db=nas_telegraf": dial tcp 172.18.0.2:8086: connect: no route to host

2022-03-07T12:58:17Z E! [outputs.influxdb] When writing to [http://influxdb:8086]: Post "http://influxdb:8086/write?db=nas_telegraf": dial tcp: lookup influxdb on 127.0.0.11:53: no such host

avec le réseau 172.18.0.0/24 qui est la plage IP de mon bridge dans lequel sont mes trois conteneurs.

J'ai bien ajouté le réseau 172.16.0.0 dans mon firewall.

Comment puis-je rendre la commande nslookup disponible sur mes conteneurs docker?

Encore merci pour votre aide!

 

[faluorn]

Bon.

Après avoir continué à chipoter dans tous les sens, j'ai fini par bypasser l'erreur "réseau" et mon Telegraf arrive bien à pusher des données dans InfluxDB.

J'ai du changer le board grafana pour afficher une partie de ces données.

Pendant 20 minutes, mon telegraf a pushé des données dans InfluxDB et je les vois sur mon board Grafana.

Cependant, après 20 minutes, mes logs sont de nouveaux saturés d'erreur de type et aucune nouvelle information n'arrive dans influxDB

2022-03-07T14:58:00Z E! [inputs.snmp] Error in plugin: agent 192.168.0.202: gathering table raidTable: performing bulk walk for field raidName: Request timeout (after 3 retries)

Est-ce que cela veut dire que mon fichier telegraf.conf ne renseigne pas le bon champs à aller chercher dans les fichiers MIB?

J'ai cette erreur qui revient en boucle pour une série de champs :

• ifDescr
• diskID
• raidName
• laNames
• hrStorageDescr
• storageIODevice

Voici la définition de ces champs dans mon fichier telegraf.conf

  # Inet interface
  [[inputs.snmp.table]]
    oid = "IF-MIB::ifTable"
    [[inputs.snmp.table.field]]
      is_tag = true
    oid = "IF-MIB::ifDescr"
    
  # Syno disk
  [[inputs.snmp.table]]
    oid = "SYNOLOGY-DISK-MIB::diskTable"
    [[inputs.snmp.table.field]]
      is_tag = true
    oid = "SYNOLOGY-DISK-MIB::diskID" 
    
  # Syno raid
  [[inputs.snmp.table]]
    oid = "SYNOLOGY-RAID-MIB::raidTable"
    [[inputs.snmp.table.field]]
    is_tag = true
    oid = "SYNOLOGY-RAID-MIB::raidName" 
    
  # Syno load
  [[inputs.snmp.table]]
    oid = "UCD-SNMP-MIB::laTable"
    [[inputs.snmp.table.field]]
    is_tag = true
    oid = "UCD-SNMP-MIB::laNames"

  # Storage IO Device
  [[inputs.snmp.table.field]]
    name = "storageIODevice"
    is_tag = true
    oid = "SYNOLOGY-STORAGEIO-MIB::storageIODevice"

  # System volume   
  [[inputs.snmp.table]]
    oid = "HOST-RESOURCES-MIB::hrStorageTable"
  [[inputs.snmp.table.field]]
    is_tag = true
    oid = "HOST-RESOURCES-MIB::hrStorageDescr"

Si quelqu'un a une idée, je suis preneur.

Merci d'avance 🙂

Edit du 08/03

J'ai commenté ces champs dans mon fichier telegraf.conf, du coup j'ai des erreurs pour des champs qui étaient récupérés avant. Je suis perdu...

Modifié le 8 mars 2022 par faluorn

[.Shad.]

Bonjour @faluorn,

Enormément de travail actuellement, je n'ai pas trouvé un moment pour t'aider, je ne t'oublie pas mais je dois te demander de patienter encore quelques jours. 😉 

Bonne journée !

[faluorn]

Bonjour @.Shad.

Pas de soucis, j'ai moi aussi pas mal de d'autres occupations pour me tenir occupé.

J'ai quand même tenté quelques petites choses :

• J'ai complètement supprimé mon fichier telegraf.conf pour repartir de 0 avec le fichier de backup, mais l'erreur est toujours là.
• J'ai supprimé tous les inputs sauf un seul, mais j'ai la même erreur
• J'ai tenté de récupérer des données snmp de mon pc et de les afficher, mais les logs n'indiquent rien et mon dashboard reste vide
• J'ai tenté de monitorer telegraf lui-même, en suivant un tutoriel, mais les logs n'indiquent rien et mon dashboard reste vide
• J'ai joué sur les timeout (l'erreur semble indiquer que telegraf essaye de récupérer trop de données sur le temps imparti) mais cela ne change rien

Du coup, de toutes mes lectures, j'ai plusieurs autres questions :

• J'ai trouvé un tutoriel indiquant qu'on pouvait diviser le fichier telegraf.conf en plusieurs parties, divisées dans un répertoire telegraf.d mais je n'ai pas réussi. Quelqu'un a déjà réussi à faire cela?
• Est-ce possible de configurer plusieurs db influxDB dans le fichier compose, afin d'avoir une db par objet monitoré? (le NAS, un PC, telegraf,...?)

Encore merci pour vos commentaires et votre aide en tous cas.

[.Shad.]

Le 07/03/2022 à 14:11, faluorn a dit :

Comment puis-je rendre la commande nslookup disponible sur mes conteneurs docker?

Si un conteneur dispose de apt tu peux l'installer, mais ça ne sera pas persistant, c'est faisable avec un mod en revanche pour les images publiées par Linuxserver.

Le 07/03/2022 à 13:48, .Shad. a dit :

A priori, c'est un timeout, donc ce n'est pas un problème de pare-feu, sinon ce serait refusé.
Est-ce que tu n'as pas changé le nom de la communauté SNMP ?
Sinon, si ton réseau est en 172.18.0.0 par exemple, tu mets l'IP 172.18.0.1 au lieu de 192.168.0.202, et il faut s'assurer que le pare-feu du NAS autorise les requêtes pour les IP 172.16.0.0/255.240.0.0

Ce serait pas mal que tu corriges l'IP de l'agent comme je l'ai proposé dans la partie citée ci-dessus. Au vu de tes logs tu ne l'as pas fait (192.168.0.202 apparaît encore).

Le 07/03/2022 à 16:36, faluorn a dit :

Après avoir continué à chipoter dans tous les sens, j'ai fini par bypasser l'erreur "réseau" et mon Telegraf arrive bien à pusher des données dans InfluxDB.

C'est pas vraiment un domaine qui relève de la magie, ce serait bien qu'on sache exactement ce que tu as fait, histoire de n'écarter aucune piste.

Est-ce que tu utilises bien l'image 1.20.4 de Telegraf ?

Le 11/03/2022 à 13:23, faluorn a dit :

J'ai supprimé tous les inputs sauf un seul, mais j'ai la même erreur

càd ? lequel ?

Le 11/03/2022 à 13:23, faluorn a dit :

• J'ai tenté de récupérer des données snmp de mon pc et de les afficher, mais les logs n'indiquent rien et mon dashboard reste vide
• J'ai tenté de monitorer telegraf lui-même, en suivant un tutoriel, mais les logs n'indiquent rien et mon dashboard reste vide
• J'ai joué sur les timeout (l'erreur semble indiquer que telegraf essaye de récupérer trop de données sur le temps imparti) mais cela ne change rien

Pour les deux premiers point je ne connais pas ton setup donc impossible de répondre.

Pour le dernier, il suffit de vérifier si le tampon défini par défaut (10k metrics) est bien rempli entre chaque envoi, personnellement je tourne à 200/10000. Ca se voit dans les logs de Telegraf.

Le 11/03/2022 à 13:23, faluorn a dit :

J'ai trouvé un tutoriel indiquant qu'on pouvait diviser le fichier telegraf.conf en plusieurs parties, divisées dans un répertoire telegraf.d mais je n'ai pas réussi. Quelqu'un a déjà réussi à faire cela?

Jamais essayé, il faut vérifier qu'il y a bien un appel d'inclusion des fichiers conf du dit dossier dans le fichier conf principal.

Le 11/03/2022 à 13:23, faluorn a dit :

Est-ce possible de configurer plusieurs db influxDB dans le fichier compose, afin d'avoir une db par objet monitoré? (le NAS, un PC, telegraf,...?)

C'est ce que je fais dans la partie du tutoriel ou je propose de superviser un Rpi.

[faluorn]

Bonjour @.Shad.

Merci pour ta réponse!

Le 13/03/2022 à 14:18, .Shad. a dit :

C'est pas vraiment un domaine qui relève de la magie, ce serait bien qu'on sache exactement ce que tu as fait, histoire de n'écarter aucune piste.

J'avais tendance à simplement redémarrer les conteneurs via l'interface de Docker, je pense que lorsque je me suis connecté en SSH pour détruire/redémarrer le conteneur cela a du adapter quelque chose.

 

Le 13/03/2022 à 14:18, .Shad. a dit :

Est-ce que tu utilises bien l'image 1.20.4 de Telegraf ?

J'utilisais la 1.16, mais j'ai bien la 1.20.4 maintenant

Le 13/03/2022 à 14:18, .Shad. a dit :

C'est ce que je fais dans la partie du tutoriel ou je propose de superviser un Rpi.

Je n'ai pas réussi à trouver ce tutoriel, pourrais-tu m'envoyer l'URL s'il te plait?

 

Le 13/03/2022 à 14:18, .Shad. a dit :

Pour le dernier, il suffit de vérifier si le tampon défini par défaut (10k metrics) est bien rempli entre chaque envoi, personnellement je tourne à 200/10000. Ca se voit dans les logs de Telegraf.

Mes logs ne mentionnent pas cette information. Ni dans l'interface de Docker ni lorsque je les affiche lorsque je me connecte en SSH.

 

Le 13/03/2022 à 14:18, .Shad. a dit :

Ce serait pas mal que tu corriges l'IP de l'agent comme je l'ai proposé dans la partie citée ci-dessus. Au vu de tes logs tu ne l'as pas fait (192.168.0.202 apparaît encore).

J'ai fait cela et cela fonctionne maintenant. Comme j'avais bien des informations par le passé avec cette adresse-là, je n'avais pas changé. Mes cours de réseau remontent à... il y a trop longtemps. Je ne suis donc pas bien sur de comprendre pourquoi en mettant mon autre adresse le routage ne se fait pas via la passerelle.

En tous les cas, cela fonctionne maintenant, un énorme merci pour ton temps. Et désolé d'avoir tardé à essayer ta solution, qui nous aurait fait gagner du temps à tous les deux...

Excellente journée!

[.Shad.]

Il y a 2 heures, faluorn a dit :

J'avais tendance à simplement redémarrer les conteneurs via l'interface de Docker, je pense que lorsque je me suis connecté en SSH pour détruire/redémarrer le conteneur cela a du adapter quelque chose.

Si tu ne modifies qu'un fichier conf, normalement un redémarrage du conteneur suffit.
Pour tout le reste, il faut recréer le conteneur, c'est là que Docker-compose facilite fort la tâche. 🙂

Il y a 2 heures, faluorn a dit :

Je n'ai pas réussi à trouver ce tutoriel, pourrais-tu m'envoyer l'URL s'il te plait?

C'est de ce tutoriel dont je parle, partie 11.

Il y a 2 heures, faluorn a dit :

Mes logs ne mentionnent pas cette information. Ni dans l'interface de Docker ni lorsque je les affiche lorsque je me connecte en SSH.

Est-ce que tu as réglé le logging en debug dans le fichier conf de Telegraf ? c'est dans la première partie du fichier.

Il y a 2 heures, faluorn a dit :

J'ai fait cela et cela fonctionne maintenant. Comme j'avais bien des informations par le passé avec cette adresse-là, je n'avais pas changé. Mes cours de réseau remontent à... il y a trop longtemps. Je ne suis donc pas bien sur de comprendre pourquoi en mettant mon autre adresse le routage ne se fait pas via la passerelle.

Normalement c'est sensé marcher en mettant l'IP locale, mais certains ont eu le même problème que toi.
L'avantage de passer par l'IP interne c'est d'éviter les problèmes de changement d'IP (changement de box par exemple).
C'est comme si voulant contacter ta box, tu passais par l'IP publique au lieu de l'IP privée, ce serait suboptimal. 🙂