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

MilesTEG1 · le 13 octobre 2020

J'essaye à l'occasion 😉

oracle7 · le 14 octobre 2020

@.Shad.

Bonjour,

Je souhaite monitorer mes caméras vidéo HIKvision. J'ai donc trouvé les fichiers MIB qui vont bien (enfin j'espère) et je me demandais si on peux les mettre directement dans le répertoire "/usr/share/snmp/mibs/". Mais dans ce cas, je crains qu'ils ne soient effacés de ce répertoire lors d'une mise à jour de DSM ? J'ai bon ? O/N

Sinon peut-on les mettre ailleurs (du style dans "/volume1/docker/MIBs") et dans ce cas comment vont-ils être pris en compte ?

Il faut rajouter un lien symbolique dans "/usr/share/snmp/mibs/" sur le NAS vers "/volume1/docker/MIBs" pour chacun de ces fichiers (il y en a en fait deux) ?
OU
Tout simplement dans le fichier "docker-compose.yml" pour le service "telegraf" on rajoute une ligne à "volumes:" du style " - "/volume1/docker/MIBs:/usr/share/snmp/mibs:ro" " ? Mais dans ce cas comme on a déjà une ligne " - "/usr/share/snmp/mibs:/usr/share/snmp/mibs:ro" " pour monter les MIBs Synology, cela ne va pas poser de problèmes de monter deux répertoires différents dans un même répertoire du conteneur ?

Merci de vos réponses avisés.

PS : En plus d'ajouter les fichiers MIBs, bien évidemment, le fichier "telegraf.conf" est aussi modifié en conséquences pour collecter les données des caméras.

EDIT : Je viens de tester la solution d'ajouter une ligne du style " - "/volume1/docker/MIBs:/usr/share/snmp/mibs:ro" " dans le fichier "docker-compose.yml" pour le service "telegraf". Ce n'est pas bon du tout : je récupère un message (un peu prévisible d'ailleurs) :

ERROR: Duplicate mount points: [/usr/share/snmp/mibs:/usr/share/snmp/mibs:ro, /volume1/docker/MIBs:/usr/share/snmp/mibs:ro]

J'en reviens donc à ma première question ci-avant.

Cordialement

oracle7😉

Modifié le 14 octobre 2020 par oracle7

oracle7 · le 14 octobre 2020

@.Shad.

Bonjour,

En complément à ma tentative de configurer le monitoring de mes caméras HIKvision.

Dans le logiciel de configuration des caméras HIK j'ai ceci à propos de la partie snmp :

Est-ce qu'il faut bien renseigner comme cela ? (l'@IP est celle de la caméra).
Au niveau des fichiers MIB, en attendant plus de précisions (voir mon post précédent), j'ai collé dans le répertoire "usr/share/snmp/mibs/" les deux fichiers MIB trouvés pour HIK ici.
A leur examen, je constate d'une part :
- que l'un (HIKVISION-MIB.txt) est valable pour une entreprise "50001" et l'autre (HIK-DEVICE-MIB.txt) pour une entreprise "39165".
- que d'autre part, les données qu'il gèrent sont différentes même si certaines semblent se ressembler. ?????
Est-ce un problème cette différence de validité ?
A noter que les infos que j'ai récupérées par ailleurs dans un dashboard sur grafana.com semblent elles utiliser le fichier HIK-DEVICE-MIB. J'ai donc ajouter ces informations dans le fichier "telegraf.conf". Mais à bien y réfléchir, j'ai un doute, Est-ce que j'ai bien fait, Oui/Non ?
Dans le fichier "telegraf.conf" j'ai aussi ajouté l'@IP de ma caméra dans le champ "agents" sous INPUT PLUGIN.
Fort de tout cela, après avoir re généré le conteneur telegraf, j'ai essayé dans une session SSH la commande suivante pour voir si au moins je récupérais des infos de la caméra : "snmpwalk -c public -v2c 192.168.2.21 1.3.6.1.1.1.39165" mais "Timeout: No Response from 192.168.2.21". Idem en remplaçant l'@IP de la caméra par celle du conteneur telégraf 172.20.0.3. (public sera remplacé par la bonne valeur "secrète").
Le log de telegraf me donne aussi ceci :

Citation

2020-10-14T17:09:40Z I! Starting Telegraf 1.15.2
2020-10-14T17:09:40Z I! Using config file: /etc/telegraf/telegraf.conf
2020-10-14T17:09:40Z I! Loaded inputs: snmp kernel mem processes swap cpu disk diskio system docker
2020-10-14T17:09:40Z I! Loaded aggregators:
2020-10-14T17:09:40Z I! Loaded processors: regex converter
2020-10-14T17:09:40Z I! Loaded outputs: influxdb
2020-10-14T17:09:40Z I! Tags enabled: host=telegraf
2020-10-14T17:09:40Z I! [agent] Config: Interval:30s, Quiet:false, Hostname:"telegraf", Flush Interval:10s
2020-10-14T17:11:00Z W! [inputs.snmp] Collection took longer than expected; not complete after interval of 1m0s
2020-10-14T17:11:20Z E! [inputs.snmp] Error in plugin: agent 192.168.2.21: performing get on field sysName: Request timeout (after 3 retries)
2020-10-14T17:12:00Z W! [inputs.snmp] Collection took longer than expected; not complete after interval of 1m0s
2020-10-14T17:12:40Z E! [inputs.snmp] Error in plugin: agent 192.168.2.21: gathering table ifTable: performing bulk walk for field ifDescr: Request timeout (after 3 retries)
2020-10-14T17:13:00Z W! [inputs.snmp] Collection took longer than expected; not complete after interval of 1m0s

J'ai raté ou omis sûrement quelque chose mais je ne vois pas quoi ?

Une idée ou une piste serait la bienvenue pour me permettre de dépatouiller tout cela ...

Merci d'avance de ta réponse.

Cordialement

oracle7😉

Modifié le 14 octobre 2020 par oracle7

.Shad. · le 15 octobre 2020

Il y a 18 heures, oracle7 a dit :

Sinon peut-on les mettre ailleurs (du style dans "/volume1/docker/MIBs") et dans ce cas comment vont-ils être pris en compte ?

Moi je ferais un truc du genre à ta place :

/volume1/docker/MIBs/:/usr/share/snmp/mibs/hiks:ro

Le defaut path pour la recherche de MIBs reste le même, si ça marche pas jette un oeil à ça (fin du post) : https://ma.ttias.be/autoloading-mib-files-in-client-snmp-configuration-on-linux/

Pas le temps de répondre à la suite pour l'instant. 😉

oracle7 · le 15 octobre 2020

@.Shad.

Bonjour,

Le 15/10/2020 à 07:32, .Shad. a dit :
Moi je ferais un truc du genre à ta place :
/volume1/docker/MIBs/:/usr/share/snmp/mibs/hiks:ro

Désolé, cela ne marche pas.

J'ai donc regardé le lien que tu m'as donné et j'ai créé dans "etc/snmp" un fichier "snmp.conf" telque :

mibdirs +/volume1/docker/MIBs
mibs +HIK-DEVICE-MIB

J'ai ajouté dans le fichier "telegraf.conf" les lignes suivantes :

#----------------------------------------------------------
## HIKVISION IP Camera
#----------------------------------------------------------
	# Uses the HIK-DEVICE-MIB
[[inputs.snmp]]
  agents = [  "192.168.2.21" ]
  interval = "60s"
  timeout = "10s"
  retries = 3
  version = 2
  community = "xxxxxxxxxxxxx"
  max_repetitions = 30
  name = "snmp.HIK"
	
	# HIK Manufacturer
  [[inputs.snmp.field]]
    name = "manufacturer"
    oid = "HIK-DEVICE-MIB::manufacturer.0"
	# HIK Device Model
  [[inputs.snmp.field]]
    name = "deviceModel"
    oid = "HIK-DEVICE-MIB::deviceType.0"
	# HIK Version Software
  [[inputs.snmp.field]]
    name = "softwVersion"
    oid = "HIK-DEVICE-MIB::softwVersion.0"
	# HIK Cpu Precent
  [[inputs.snmp.field]]
    name="cpuPercent"
    oid = "HIK-DEVICE-MIB::cpuPercent.0"
	# HIK Mem Used
  [[inputs.snmp.field]]
    name="memUsed"
    oid = "HIK-DEVICE-MIB::memUsed.0"
	# HIK Static Ip
  [[inputs.snmp.field]]
    name="staticIp"
    oid = "HIK-DEVICE-MIB::staticIpAddr.0"
	# HIK MAC Address
  [[inputs.snmp.field]]
    name="macAddr"
    oid = "HIK-DEVICE-MIB::macAddr.0"
	# HIK Video Encode
  [[inputs.snmp.field]]
    name="vidEncode"
    oid = "HIK-DEVICE-MIB::videoEncode.0"
  
  [[processors.regex]]
    order = 1
    namepass = ["snmp"]
    [[processors.regex.fields]]
      key = "cpuPercent"
      pattern = "^(\\d+).*"
      replacement = "${1}"
    [[processors.regex.fields]]
      key = "memUsed"
      pattern = "^(\\d+).*"
      replacement = "${1}"
	
  [[processors.converter]]
    order = 2
    [processors.converter.fields]
      integer = ["cpuPercent","memUsed"]

et redémarré le conteneur telegraf --> docker restart telegraf

Maintenant il y a déjà un mieux en renseignant correctement la partie snmp de la caméra (dans son logiciel d'admin) et en redémarrant ensuite celle-ci, j'arrive à voir ses infos avec une commande :

"snmpwalk -c xxxxxxxxxxxxx -v 2c 192.168.2.21 1.3.6.1.4.1.39165" :

SNMPv2-SMI::enterprises.39165.1.1.0 = STRING: "DS-2CD2045FWD-I"
SNMPv2-SMI::enterprises.39165.1.2.0 = STRING: "0"
SNMPv2-SMI::enterprises.39165.1.3.0 = STRING: "V5.6.5 build 200316"
SNMPv2-SMI::enterprises.39165.1.4.0 = STRING: "xx-xx-xx-xx-xx-xx"
SNMPv2-SMI::enterprises.39165.1.5.0 = STRING: "1"
SNMPv2-SMI::enterprises.39165.1.6.0 = STRING: "Hikvision"
SNMPv2-SMI::enterprises.39165.1.7.0 = STRING: "71 PERCENT"
SNMPv2-SMI::enterprises.39165.1.8.0 = STRING: "0.0 GB"
SNMPv2-SMI::enterprises.39165.1.9.0 = STRING: "0 PERCENT"
SNMPv2-SMI::enterprises.39165.1.10.0 = STRING: "512 MB"
SNMPv2-SMI::enterprises.39165.1.11.0 = STRING: "54 PERCENT"
SNMPv2-SMI::enterprises.39165.1.12.0 = INTEGER: 0
SNMPv2-SMI::enterprises.39165.1.13.0 = IpAddress: 192.168.2.21
SNMPv2-SMI::enterprises.39165.1.14.0 = IpAddress: 255.255.255.0
SNMPv2-SMI::enterprises.39165.1.15.0 = IpAddress: 192.168.2.1
SNMPv2-SMI::enterprises.39165.1.16.0 = IpAddress: 0.0.0.0
SNMPv2-SMI::enterprises.39165.1.17.0 = IpAddress: 0.0.0.0
SNMPv2-SMI::enterprises.39165.1.18.0 = IpAddress: 0.0.0.0
SNMPv2-SMI::enterprises.39165.1.19.0 = STRING: "2020-10-15 21:15:26"
SNMPv2-SMI::enterprises.39165.1.20.0 = INTEGER: 1
SNMPv2-SMI::enterprises.39165.1.21.0 = STRING: "H.264"
SNMPv2-SMI::enterprises.39165.1.22.0 = STRING: "H.264"
SNMPv2-SMI::enterprises.39165.1.23.0 = INTEGER: 0
SNMPv2-SMI::enterprises.39165.1.24.0 = INTEGER: 0
SNMPv2-SMI::enterprises.39165.1.25.0 = INTEGER: 0
SNMPv2-SMI::enterprises.39165.1.26.0 = INTEGER: 1
SNMPv2-SMI::enterprises.39165.1.27.0 = INTEGER: 1
SNMPv2-SMI::enterprises.39165.1.28.0 = INTEGER: 1
SNMPv2-SMI::enterprises.39165.1.29.0 = STRING: "ETHERNET"
SNMPv2-SMI::enterprises.39165.1.30.0 = INTEGER: 0
SNMPv2-SMI::enterprises.39165.1.31.0 = INTEGER: 0
SNMPv2-SMI::enterprises.39165.1.32.0 = IpAddress: 0.0.0.0
SNMPv2-SMI::enterprises.39165.1.33.0 = STRING: "192.168.2.10"
SNMPv2-SMI::enterprises.39165.1.34.0 = INTEGER: 0
SNMPv2-SMI::enterprises.39165.1.34.0 = No more variables left in this MIB View (It is past the end of the MIB tree)

mais et il y a un MAIS, une fois dans le monitoring impossible de sélectionner dans le "FROM" d'une requête la valeur "syno.HIK", elle n'apparait pas. Tout ce passe comme si l'ajout dans le fichier "telegraf.conf" n'avait pas été pris en compte.

Du coup je suis un peu (beaucoup) perplexe voir perdu.

Une idée ou piste de ta part serait très appréciée ...

Cordialement

oracle7😉

Modifié le 16 octobre 2020 par oracle7

bruno78 · le 17 octobre 2020

Bonjour @.Shad., @Einsteinium,

je ne savais pas trop où placer cette question (ici ou côté DSM7 ? ) : depuis mon passage en DSM7, il n'y a plus de remontée de données via telegraf pour tout ce qui relève du plugin [inputs.snmp]. Invariablement le même message :

2020-10-17T16:42:00Z D! [inputs.snmp] Previous collection has not completed; scheduled collection skipped
2020-10-17T16:42:00Z W! [inputs.snmp] Collection took longer than expected; not complete after interval of 1m0s

Et au final rien ne remonte vers influxdb, et donc rien non plus sur grafana !

Et pourtant, toutes les commandes snmpwalk ou snmpbulkwalk, qui sont à la base du fonctionnement de telegraf, fonctionnent parfaitement lorsque lancées à la main.

Ce qui ne vient pas de [inputs.snmp] fonctionne parfaitement (par exple : [[inputs.system]], [[inputs.swap]], [[inputs.mem]], ....).

J'ai l'impression d'avoir tout vérifié et regardé tous les logs et toutes les traces, ... rien vu de probant !

Je sèche ...

Cdt

Bruno78

@oracle7,

as-tu essayé de mettre directement les valeurs numériques des OID dans le telegraf.conf ? De mémoire lorsque l'on avait inclus le monitoring des UPS dans le dashboard du NAS, j'avais eu ce genre de problème ... Ce n'est qu'une piste ....

Cdt

Bruno78

Modifié le 17 octobre 2020 par bruno78

oracle7 · le 17 octobre 2020

@bruno78

Bonjour,

Je ne sais si cela t'aidera mais j'ai eu à un moment donné un soucis similaire. J'avais en fait des tabulations à la place d'espaces pour l'indentation dans quelques lignes du fichier telegraf.conf.

Cordialement

oracle7😉

bruno78 · le 17 octobre 2020

@oracle7 ,
Je n'ai plus le temps de regarder ce soir, mais c'est vrai que mon fichier telegraf.conf n'est pas très "propre" côté indentations. J'espère que ce n'est que cela. Je regarde ça demain. Merci. Bruno78

Envoyé de mon STF-L09 en utilisant Tapatalk

Einsteinium · le 17 octobre 2020

Là je t’aiderais pas, je n’utilise pas 🙂

bruno78 · le 18 octobre 2020

@oracle7,

malheureusement, fichier telegraf.conf remis au propre, vérifie l'absence de tabulation, vérifié l'indentation (au cas ou ...). est rien à faire .... Toujours aucune remontée d'info snmp du NAS par telegraf.

Cdt

Bruno78

oracle7 · le 18 octobre 2020

@bruno78

Bonjour,

Désolé si j'enfonce des "portes ouvertes".

A tout hasard (encore une idée tordue, je sais 🤪), avec DSM7 les fichiers MIB n'auraient-ils pas été déplacés ailleurs que dans "/usr/share/snmp/mibs/" ?

Citation

        volumes:
            - "/volume1/docker/telegraf/telegraf.conf:/etc/telegraf/telegraf.conf:ro"
            - "/proc:/host/proc:ro"
            - "/usr/share/snmp/mibs:/usr/share/snmp/mibs:ro"

Du coup le montage ne serait plus bon dans le docler-compose.yml.

Sinon, sont-ils aussi toujours les mêmes ?

Il y a 17 heures, bruno78 a dit :

Ce qui ne vient pas de [inputs.snmp] fonctionne parfaitement (par exple : [[inputs.system]], [[inputs.swap]], [[inputs.mem]], ....).

Tu parles de [inputs.snmp] ne serait-ce pas plutôt [[inputs.snmp]] i.e. entre double crochets ?

Cordialement

oracle7😉

Modifié le 18 octobre 2020 par oracle7

bruno78 · le 18 octobre 2020

@oracle7,

oui et oui 🙂 Montage docker-compose.yaml vérifié et [[ bien en place .

Cdt

Bruno78

oracle7 · le 18 octobre 2020

@.Shad.

Bonjour,

Malgré les manipulations décrites précédemment, je n'arrive toujours pas à faire prendre en compte mes fichiers MIB HIKvision.

Une idée ou piste peut-être car là je bloque ...

Cordialement

oracle7😉

.Shad. · le 18 octobre 2020

@oracle7

Je ne vois pas d'où le problème peut venir, ce qui pourrait être intéressant c'est d'utiliser tcpdump ou l'image Wireshark de Linuxserver pour voir comment se comportent les paquets SNMP.
A priori rien ne me semble non fonctionnel dans ce que tu as fait...

@bruno78

Est-ce que tu rencontres les mêmes problèmes si Telegraf est installé en host et pas en bridge ?

oracle7 · le 18 octobre 2020

@.Shad.

Merci d'avoir regarder.

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

ce qui pourrait être intéressant c'est d'utiliser tcpdump ou l'image Wireshark de Linuxserver pour voir comment se comportent les paquets SNMP.

Là, cela dépasse largement mes compétences.

Autant je sais regarder le trafic sur un port (ex 1194 pour openVPN) autant là, tu me parles chinois ☹️ pour cette manipulation.

Je dois rater un truc tout c... mais quoi ?

EN fait je ne comprend pas trop le message d'erreur (error plugin) retourné après lancement de telegraf :

Citation

2020-10-18T12:32:46Z I! Starting Telegraf 1.15.3
2020-10-18T12:32:46Z I! Using config file: /etc/telegraf/telegraf.conf
2020-10-18T12:32:46Z I! Loaded inputs: mem swap diskio kernel processes system docker snmp snmp cpu disk
2020-10-18T12:32:46Z I! Loaded aggregators:
2020-10-18T12:32:46Z I! Loaded processors: regex converter
2020-10-18T12:32:46Z I! Loaded outputs: influxdb
2020-10-18T12:32:46Z I! Tags enabled: host=telegraf
2020-10-18T12:32:46Z I! [agent] Config: Interval:30s, Quiet:false, Hostname:"telegraf", Flush Interval:10s
2020-10-18T12:33:00Z E! [inputs.snmp] Error in plugin: initializing field manufacturer: translating: MIB search path: /root/.snmp/mibs:/usr/share/snmp/mibs:/usr/share/snmp/mibs/iana:/usr/share/snmp/mibs/ietf:/usr/share/mibs/site:/usr/share/snmp/mibs:/usr/share/mibs/iana:/usr/share/mibs/ietf:/usr/share/mibs/netsnmp
Cannot find module (HIK-DEVICE-MIB): At line 1 in (none)

Peut-être que cela te "cause" ?

Cordialement

oracle7😉

Modifié le 18 octobre 2020 par oracle7

bruno78 · le 18 octobre 2020

Il y a 2 heures, .Shad. a dit :

Est-ce que tu rencontres les mêmes problèmes si Telegraf est installé en host et pas en bridge ?

@.Shad. brillantissime ! oui, avec Telegraf en "host", ca passe !! Mais du coup, qu'est ce qui a changé ? je suis passé de DSM6 à DSM7 sans toucher aux config des dockers. Tout était à l'identique. Donc ?

Merci de cette piste

Bruno78

.Shad. · le 18 octobre 2020

Pour moi c'est un timeout, et donc quelque part la résolution DNS automatique qu'effectue Docker plante (un conteneur en bridge forward ce qu'il ne peut résoudre seul à son hôte).

Ce que tu peux tester (en bridge) c'est d'installer nslookup dans ton conteneur telegraf et voir si tu arrives à tout résoudre normalement. Quelle IP/interface utilises-tu pour joindre ton NAS depuis Telegraf ?

bruno78 · le 19 octobre 2020

bonjour @.Shad.,

je vais faire le test de nslookup dans la journée j'espère.

Pour joindre le NAS, depuis Telegraf, j'utilise l'adresse IP du NAS

 [[inputs.snmp]]
   # List of agents to poll
   agents = [  "192.168.1.171"  ]  # addr IP du NAS

Bruno78

bruno78 · le 19 octobre 2020

@.Shad.

résultat du nslookup sur le telegraf mode bridge : tout a l'air normal pourtant.

root@nas_telegraf:/# nslookup
> influxdb
Server:         127.0.0.11
Address:        127.0.0.11#53

Non-authoritative answer:
Name:   influxdb
Address: 172.20.0.3
> grafana
Server:         127.0.0.11
Address:        127.0.0.11#53

Non-authoritative answer:
Name:   grafana
Address: 172.20.0.2
>
> google.fr
Server:         127.0.0.11
Address:        127.0.0.11#53

Non-authoritative answer:
Name:   google.fr
Address: 216.58.209.227
Name:   google.fr
Address: 2a00:1450:4007:817::2003
>

Cdt, Bruno78

.Shad. · le 19 octobre 2020

Ici : https://github.com/influxdata/telegraf/issues/8271

Ca ne donne pas de solution mais au moins tu n'es pas seul... 😉

Que te donne le fichier /etc/resolv.conf de Telegraf ? Le mien, sous DSM 6 :

bruno78 · le 19 octobre 2020

@.Shad., effectivement, on est moins seul !

Mon resolv.conf sur le docker telegraf (1.15.3) en mode bridge :

root@nas_telegraf:/etc# cat resolv.conf
nameserver 127.0.0.11
options ndots:0
root@nas_telegraf:/etc#

peut-être tenter de revenir legèrement en arrière sur la version telegraf ?

.Shad. · le 19 octobre 2020

Fais un backup de ton resolv.conf, et tu remplaces 127.0.0.11 par l'IP de ton serveur DNS local.
Tu relances le conteneur (restart) et tu vois si ça fonctionne cette fois.

Si oui, c'est qu'il y a un problème quelque part soit dans Telegraf, soit dans Docker avec le forward des requêtes DNS, mais là c'est un peu vague pour moi.

Sinon, tu remplaces l'IP locale du NAS par l'IP passerelle 172.x... dans l'agent (si le Telegraf qui poll ton NAS est bien lui aussi hébergé sur le NAS ?)

Modifié le 19 octobre 2020 par .Shad.

bruno78 · le 19 octobre 2020

Merci, je te réponds dans la journée.
Bruno78

Envoyé de mon STF-L09 en utilisant Tapatalk

MilesTEG1 · le 19 octobre 2020

@bruno78 C'est bien toi qui a DSM7 qui tourne sur ton NAS n'est-ce pas ?

Ça fonctionnait bien avec DSM6.2 avant de migrer le NAS en dsm7 ?

(pour savoir si le soucis que tu as vient de DSM7 ou pas ^^)

Docker est sur mon 920+ avec DSM6.2, et j'ai réussi à monitorer mon 214play qui est en DSM7 pour tester ^^
Mais je ne sais pas si le fait d'avoir telegraf et compagnie sur le DSM7 ne pose pas des soucis chez toi...

bruno78 · le 19 octobre 2020

@.Shad.

alors si je mets dans le resolv.conf l'adresse de mon NAS qui est serveur de nom, encore une fois tout semble normal :

il ne connait pas "influxdb"
il connait "google.fr"

alors que si il y a 172.0.0.11, alors il sait resoudre "influxdb" et "google.fr" ...

root@nas_telegraf:/etc# nslookup
> influxdb
Server:         127.0.0.11
Address:        127.0.0.11#53

Non-authoritative answer:
Name:   influxdb
Address: 172.20.0.3

> google.fr
Server:         127.0.0.11
Address:        127.0.0.11#53

Non-authoritative answer:
Name:   google.fr
Address: 216.58.206.227
Name:   google.fr
Address: 2a00:1450:4007:80f::2003
> exit

root@nas_telegraf:/etc# echo nameserver 192.168.1.171 > resolv.conf
root@nas_telegraf:/etc# echo options ndots:0 >> resolv.conf

root@nas_telegraf:/etc# cat resolv.conf
nameserver 192.168.1.171
options ndots:0

root@nas_telegraf:/etc# nslookup
> influxdb
Server:         192.168.1.171
Address:        192.168.1.171#53

** server can't find influxdb: NXDOMAIN
> google.fr
Server:         192.168.1.171
Address:        192.168.1.171#53

Non-authoritative answer:
Name:   google.fr
Address: 216.58.206.227
Name:   google.fr
Address: 2a00:1450:4007:80f::2003

Le telegraf qui vient poller le NAS est bien sur la même machine. Si je remplace dans l'agent l'adresse du NAS par l'adresse de la passerelle (172.20.0.1), alors avec resolv.conf pointant vers 127.0.0.11, ca fonctionne bien en bridge (à condition de ne pas oublier dans le graf grafana, si on a une condition "where agent_host = ..." de mettre "where agent_host = 172.20.0.1" au lieu de "where agent_host = 192.168.1.171" si on a ce genre de conditions.

=> il semble donc que la solution soit bien de donner à l'agent SNMP la passerelle de reseau bridge.

@MilesTEG1

oui, j'ai upgradé de DSM6 vers DSM7, ca marchait avait avec tous les dockers en mode bridge, et la ca ne veut plus. J'ai été obligé sur conseil de Shad de passer le docket telegraf en mode réseau "host"

Modifié le 19 octobre 2020 par bruno78

Connexion

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

Messages recommandés

Lien vers le commentaire

Partager sur d’autres sites

Meilleurs contributeurs dans ce sujet

Jours populaires

Meilleurs contributeurs dans ce sujet

Jours populaires

Messages populaires

.Shad.

oracle7

.Shad.

Images postées

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Rejoindre la conversation

Qui est en ligne 5 membres, 0 anonyme, 366 invités (Afficher la liste complète)

Contributeurs populaires

Annonces

Information importante