Aller au contenu

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

.Shad.

Par .Shad.
dans Tutoriels

 Partager

Messages recommandés

oracle7 Grand Master

oracle7

Posté(e)
Posté(e)

@faluorn

Bonjour,

Le 07/03/2022 à 16:36, faluorn a dit : 
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

As-tu trouvé la parade à cette erreur ?

Merci de ta réponse.

Cordialement

oracle7😉

 

0
  • Réponses 1.4 k
  • Créé
  • Dernière réponse

Meilleurs contributeurs dans ce sujet

Jours populaires

Meilleurs contributeurs dans ce sujet

Jours populaires

Messages populaires

.Shad.
.Shad.

AVERTISSEMENT : Ce tutoriel est adapté à InfluxDB 1.8.x, qui n'est plus la dernière version d'InfluxDB qui existe maintenant en version 2.x, dont le fonctionnement est grandement différent. 1. Pr

oracle7
oracle7

Bonjour, Finalement je me répond à moi même. Après avoir pataugé quelques heures parceque je n'avais pas saisi que la configuration présentée dans le ReadMe sur Github considérait tout ce qu'il f

.Shad.
.Shad.

Refonte en profondeur du tutoriel, impressions d'écran à ajouter encore.

Images postées

oracle7 Grand Master

oracle7

Posté(e)
Posté(e) (modifié)

@.Shad.

Bonjour,

Est-ce que par hasard tu aurais essayé d'utiliser le SNMP V3 ?

Je viens de tenter le coup et cela ne marche pas. Telegraf bloque sur des timesout alors qu'en V2 pas de soucis, les données remontent bien vers InfluxDB.

Faut-il utiliser l'utilisateur dédié docker (telegraf) ou peut-on rester avec un utilisateur courant (pour moi ayant des droit d'admin) ?

Ton avis STP.

Cordialement

oracle7😉

Modifié par oracle7
0
Jeff777 Veteran

Jeff777

Posté(e)
Posté(e)
Il y a 21 heures, oracle7 a dit :

Est-ce que par hasard tu aurais essayé d'utiliser le SNMP V3 ?

Bonjour,

Quel est l'intérêt recherché ? Les monitorings fonctionnent bien avec SNMP V2 et la dernière version de telegraf. Même celui de la Freebox.

0
oracle7 Grand Master

oracle7

Posté(e)
Posté(e)

@Jeff777

Bonjour,

il y a 48 minutes, Jeff777 a dit :

Quel est l'intérêt recherché ?

Tout simplement pour apporter plus de sécurité avec snmp v3 car l'usage de snmp v1 et v2C n'est pas recommandé par Synology. Voilà pourquoi je teste la chose. Mais tu as raison cela marche très bien en v2 actuellement et je suis currieux et aussi parfois "joueur", mais là, avec la v3 j'ai du raté un truc de config car pour tout ce qui concerne le monitoring du Syno je bloque sur des timeout de connexion et je ne vois pas quoi faire ...

Cordialement

oracle7😉

0
Jeff777 Veteran

Jeff777

Posté(e)
Posté(e)
il y a 14 minutes, oracle7 a dit :

je bloque sur des timeout de connexion et je ne vois pas quoi faire ...

Tu as essayé de jouer avec les paramètres de telegraf.conf  (timeout, interval, jitter) ?

0
oracle7 Grand Master

oracle7

Posté(e)
Posté(e)

@Jeff777

Bonjour,

Oui, j'avais même commencé par cela. Mais rien n'a marché. En plus, après recherche sur la toile (et j'y ai passé quelques heures 😟) personne n'a donné de solution probante à ce niveau. Le plus fort c'est que cela fonctionne bien en v2 avec les mêmes paramètres (ceux que tu cites). C'est pour cela aussi que j'ai des doutes avec l'utilisateur de connexion. Il faut que je teste avec l'utilisateur dédié du groupe docker : telegraf. Mais je n'en suis pas sûr du tout ...

Cordialement

oracle7😉

0
Jeff777 Veteran

Jeff777

Posté(e)
Posté(e)
il y a 6 minutes, oracle7 a dit :

Il faut que je teste avec l'utilisateur dédié du groupe docker : telegraf

Je reste à l'écoute si tu y arrives 😉

0
Jeff777 Veteran

Jeff777

Posté(e)
Posté(e)
il y a 5 minutes, oracle7 a dit :

Petite précision : je teste aussi avec Influxdb v2.4

Ah moi je suis resté à Influxdb v1.8. J'ai raté quelque chose ?

0
oracle7 Grand Master

oracle7

Posté(e)
Posté(e)

@Jeff777

Bonjour,

il y a 11 minutes, Jeff777 a dit :

J'ai raté quelque chose ?

Non pas forcément. Comme pour toutes les plates-formes, Grafana et InfluxDB ont été mis à jour pour nous offrir plus de fonctionnalités, plus d'options et pour suivre les besoins et les demandes des utilisateurs. Sauf qu’en exécutant InfluxDB2, on rencontre des changements majeurs par rapport à InfluxDB1.8 (ou antérieur). Notammant dans la terminologie employée mais aussi et surtout au niveau du langage de requêtes : on passe de influxql à Flux (pour faire court). ET c'est loin d'être évident et simple ... Du moins c'est ce que je découvre !

Cordialement

oracle7😉

 

 

0
Jeff777 Veteran

Jeff777

Posté(e)
Posté(e)
il y a une heure, oracle7 a dit :

ET c'est loin d'être évident et simple

Tu pourras faire un tuto un de ces jours ? 😉

0
.Shad. Grand Master

.Shad.

Posté(e)
  • Auteur
Posté(e) (modifié)

@oracle7 Je n'ai jamais touché au SNMPv3, vu que je reste sur du polling local je n'en ai jamais vraiment vu l'utilité. Cela dit à première vue ça me semble, sûrement faussement, facile d'accès.

snmpv3_dsm.png

et dans le fichier telegraf.conf : 

#   ## SNMPv3 authentication and encryption options.
#   ##
#   ## Security Name.
#   # sec_name = "myuser"
#   ## Authentication protocol; one of "MD5", "SHA", or "".
#   # auth_protocol = "MD5"
#   ## Authentication password.
#   # auth_password = "pass"
#   ## Security Level; one of "noAuthNoPriv", "authNoPriv", or "authPriv".
#   # sec_level = "authNoPriv"
#   ## Context Name.
#   # context_name = ""
#   ## Privacy protocol used for encrypted messages; one of "DES", "AES" or "".
#   # priv_protocol = ""
#   ## Privacy password used for encrypted messages.
#   # priv_password = ""

Pour les champs qui n'apparaissent pas dans DSM :

https://www.webnms.com/simulator/help/sim_network/netsim_conf_snmpv3.html

Si j'en crois cette page, les options dans sec_level définissent l'utilisation ou non des deux autres champs : authentification et niveau de confidentialité. Pour le context_name, l'article ci-avant en parle aussi mais c'est moins clair.

Ah, et SNMPv3 utilise a priori le port 10161 au lieu de 161, en tenir compte pour le réglage de ton pare-feu, si tu as verrouillé l'accès depuis Docker (mais je pense que tu aurais eu une connexion refusée plutôt qu'un timeout en ce cas).

Désolé, tu as sûrement déjà dû tester tout ça, vu que je viens de trouver ça en faisant une recherche rapide. Mais j'ai pas mieux à offrir 😄 

Ah si peut-être, cet issue sur le Github de Telegraf : https://github.com/influxdata/telegraf/issues/3655

Modifié par .Shad.
0
oracle7 Grand Master

oracle7

Posté(e)
Posté(e) (modifié)

@.Shad.

Bonjour,

Merci de ta réponse.

Effectivement j'ai déjà testé tout cela. Mais je bute toujours sur ce problème de timeout et de collection trop longue.😪 

root@MonNAS:/volume1/docker/scripts_install/monitoring/telegraf# docker logs -f telegraf
2022-09-27T18:07:07Z I! Using config file: /etc/telegraf/telegraf.conf
2022-09-27T20:07:07+02:00 I! Starting Telegraf 1.24.1
2022-09-27T20:07:07+02:00 I! Available plugins: 222 inputs, 9 aggregators, 26 processors, 20 parsers, 57 outputs
2022-09-27T20:07:07+02:00 I! Loaded inputs: cpu disk diskio docker kernel mem net processes snmp (2x) swap system
2022-09-27T20:07:07+02:00 I! Loaded aggregators:
2022-09-27T20:07:07+02:00 I! Loaded processors: converter strings
2022-09-27T20:07:07+02:00 I! Loaded outputs: influxdb_v2
2022-09-27T20:07:07+02:00 I! Tags enabled: host=telegraf
2022-09-27T20:07:07+02:00 I! [agent] Config: Interval:30s, Quiet:false, Hostname:"telegraf", Flush Interval:10s
2022-09-27T20:08:40+02:00 E! [inputs.snmp] Error in plugin: agent 172.20.0.1:161: performing get on field sysName: request timeout (after 3 retries)
2022-09-27T20:08:40+02:00 E! [inputs.snmp] Error in plugin: agent 192.168.2.1:161: performing get on field sysName: request timeout (after 3 retries)
2022-09-27T20:08:40+02:00 E! [inputs.snmp] Error in plugin: agent 192.168.2.11:161: performing get on field sysName: request timeout (after 3 retries)
2022-09-27T20:09:00+02:00 W! [inputs.snmp] Collection took longer than expected; not complete after interval of 1m0s

Toujours la même liste d'objets en erreur (comme chez @faluorn) :

  • sysName
  • ifTable
  • diskTable
  • raidTable
  • LaTable
  • diskSmartTable
  • hrStorageTable
  • storageIODevice
  • ethPortTable

avec pour certains non pas un "request timeout" mais un "not in time window".

Pour ce qui est de la collection not complete after 1m0s, je suis même monté à 3m0s pour interval de l'agent mais pas mieux.

Je suis même passé de 1000 à 5000 avec le metric_batch_size et là pareil pas de changement.

Ce qui est étonnant c'est que lorsque je lance des requêtes sur les MIBS correspondantes des dits objets (par ex) : 

snmpwalk -v3 -u oracle7 -l authNoPriv -a MD5 -A mypassword 172.20.0.1 -M RFC1213-MIB::sysName
OU
snmpwalk -v3 -u oracle7 -l authNoPriv -a MD5 -A mypassword 172.20.0.1 -M SYNOLOGY-DISK-MIB::diskTable

j'ai une réponse instantanée.

Du coup je ne comprend pas car dans ce cas pas de problème de timeout ou de not in time window. 🥴

A tout hasard ce ne t'évoque rien ? une piste de recherche peut-être ?

EDIT : Lorsque je lance la création du conteneur avec le mode debug activé dans telegraf.conf, j'observe une double analyse (parse translate) pour uniquement les dits objets suscités (par ex) : 

2022-09-27T20:47:03+02:00 D! [inputs.snmp] executing "snmptranslate" "-Td" "IF-MIB::ifTable.1"
2022-09-27T20:47:03+02:00 D! [inputs.snmp] executing "snmptable" "-Ch" "-Cl" "-c" "public" "127.0.0.1" "IF-MIB::ifTable"

alors que pour tous les autres, seul snmptranslate est exécuté. Serait-ce ou pas la source du problème ?

J'ai aussi ceci de récurrent tout les 10s : 

2022-09-27T21:01:40+02:00 D! [inputs.disk] [SystemPS] => unable to get disk usage ("/hostfs/run/docker/netns/a401448d8184"): permission denied
2022-09-27T21:01:40+02:00 D! [inputs.disk] [SystemPS] => unable to get disk usage ("/hostfs/run/docker/netns/7d4c09416e66"): permission denied
2022-09-27T21:01:40+02:00 D! [inputs.disk] [SystemPS] => unable to get disk usage ("/hostfs/run/docker/netns/26f53dd02e8f"): permission denied
2022-09-27T21:01:40+02:00 D! [inputs.disk] [SystemPS] => unable to get disk usage ("/hostfs/run/docker/netns/efa7f3810de5"): permission denied
2022-09-27T21:01:40+02:00 D! [inputs.disk] [SystemPS] => unable to get disk usage ("/hostfs/run/docker/netns/6e3782fd3a20"): permission denied
2022-09-27T21:01:40+02:00 D! [inputs.disk] [SystemPS] => unable to get disk usage ("/hostfs/sys/kernel/debug/tracing"): permission denied
2022-09-27T21:01:40+02:00 D! [inputs.disk] [SystemPS] => unable to get disk usage ("/hostfs/run/docker/netns/d871b4949990"): permission denied
2022-09-27T21:01:40+02:00 D! [inputs.disk] [SystemPS] => unable to get disk usage ("/hostfs/run/docker/netns/a2de4cba335a"): permission denied
2022-09-27T21:01:45+02:00 D! [outputs.influxdb_v2] Wrote batch of 120 metrics in 113.728151ms
2022-09-27T21:01:45+02:00 D! [outputs.influxdb_v2] Buffer fullness: 0 / 10000 metrics

Une autre idée ?

Cordialement

oracle7😉

Modifié par oracle7
0
oracle7 Grand Master

oracle7

Posté(e)
Posté(e)

@.Shad.

Bonjour,

Ca avance ! j'ai passé le timeout de inputs.snmp à 60s. Cela semble avoir éliminer les times out sur les tables. Au moins un point de gagné 🤪

Maintenant je me bat avec les problèmes de : 

2022-09-28T15:19:00Z D! [inputs.snmp] Previous collection has not completed; scheduled collection skipped
2022-09-28T15:19:00Z W! [inputs.snmp] Collection took longer than expected; not complete after interval of 1m0s

Je viens de passer l'interval de inputs.snmp à 300s, ce qui me parait beaucoup au regard de ce que je peux voir ici ou là sur la toile., mais cela ne semble pas encore assez, j'ai encore l'erreur ... Ton avis à ce propos ?

Cordialement

oracle7😉

 

0
.Shad. Grand Master

.Shad.

Posté(e)
  • Auteur
Posté(e)

C'est énorme 60s de timeout déjà, passer à 10s au lieu de 5s aurait dû suffire si ton réseau n'est pas défectueux.

Pour les collections, ce sont tes uniques messages d'erreur ? Ça me semble léger.

Tu es bien en log level debug ?

0
oracle7 Grand Master

oracle7

Posté(e)
Posté(e) (modifié)

@.Shad.

Bonjour,

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

C'est énorme 60s de timeout déjà, passer à 10s au lieu de 5s aurait dû suffire si ton réseau n'est pas défectueux.

Bien d'accord avec toi.

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

Pour les collections, ce sont tes uniques messages d'erreur ? Ça me semble léger.

Tu es bien en log level debug ?

Oui et Oui.

Au final, je suis revenu en SNMP v2C avec les paramètres initiaux càd idem en influxdb v1.8 soit interval=30s, Flush_interval= 10s, timeout=10s.

Là aucun problème cela collecte bien. Donc a priori pas de soucis vis à vis du réseau local.

Ensuite j'ai supprimé mon bucket et recréer un nouveau. J'ai juste modifié dans le telegraf.conf les paramètres de connexion SNMP soit : 

[[inputs.snmp]]
  agents = [  "172.20.0.1", "192.168.2.11", "192.168.2.1" ]
  interval = "30s"
  timeout = "10s"    #    VpD 5s
  version = 3    #    SNMP version VpD 2
#  community = "macommunaute"
  retries = 3
  max_repetitions = 30    #    VpD 10
  name = "snmp.SYNO"
  ## SNMPv3 authentication and encryption options.
  sec_level = "authNoPriv"    #    Values: "noAuthNoPriv", "authNoPriv", "authPriv"
  sec_name = "oracle7"
  auth_protocol = "MD5"    #    Values: "MD5", "SHA", ""
  auth_password = "MdpSimple"
  context_name = "MonNAS"
#  priv_protocol = "DES"     #    Values: "DES", "AES", ""
#  priv_password = "MdpSimple"

Mais rien y fait, voici le log en degug : 

2022-09-29T10:05:13Z D! [agent] Connecting outputs
2022-09-29T10:05:13Z D! [agent] Attempting connection to [outputs.influxdb_v2]
2022-09-29T10:05:13Z D! [agent] Successfully connected to outputs.influxdb_v2
2022-09-29T10:05:13Z D! [agent] Starting service inputs
2022-09-29T10:05:23Z D! [outputs.influxdb_v2] Buffer fullness: 0 / 10000 metrics
2022-09-29T10:05:33Z D! [outputs.influxdb_v2] Wrote batch of 115 metrics in 30.7176ms
2022-09-29T10:05:33Z D! [outputs.influxdb_v2] Buffer fullness: 0 / 10000 metrics
2022-09-29T10:05:43Z D! [outputs.influxdb_v2] Buffer fullness: 0 / 10000 metrics
2022-09-29T10:05:53Z D! [outputs.influxdb_v2] Buffer fullness: 0 / 10000 metrics
2022-09-29T10:06:00Z W! [inputs.snmp] Collection took longer than expected; not complete after interval of 30s
2022-09-29T10:06:00Z D! [inputs.snmp] Previous collection has not completed; scheduled collection skipped
2022-09-29T10:06:03Z D! [outputs.influxdb_v2] Wrote batch of 124 metrics in 35.174572ms
2022-09-29T10:06:03Z D! [outputs.influxdb_v2] Buffer fullness: 0 / 10000 metrics
2022-09-29T10:06:10Z E! [inputs.snmp] Error in plugin: agent 192.168.2.11: performing get on field sysName: request timeout (after 3 retries)
2022-09-29T10:06:10Z E! [inputs.snmp] Error in plugin: agent 192.168.2.1: performing get on field sysName: request timeout (after 3 retries)
2022-09-29T10:06:10Z E! [inputs.snmp] Error in plugin: agent 172.20.0.1: performing get on field sysName: request timeout (after 3 retries)
2022-09-29T10:06:13Z D! [outputs.influxdb_v2] Buffer fullness: 0 / 10000 metrics
2022-09-29T10:06:23Z D! [outputs.influxdb_v2] Buffer fullness: 0 / 10000 metrics
2022-09-29T10:06:30Z D! [inputs.snmp] Previous collection has not completed; scheduled collection skipped
2022-09-29T10:06:30Z W! [inputs.snmp] Collection took longer than expected; not complete after interval of 30s
2022-09-29T10:06:33Z D! [outputs.influxdb_v2] Wrote batch of 120 metrics in 32.065765ms
2022-09-29T10:06:33Z D! [outputs.influxdb_v2] Buffer fullness: 0 / 10000 metrics
2022-09-29T10:06:43Z D! [outputs.influxdb_v2] Buffer fullness: 0 / 10000 metrics
2022-09-29T10:06:50Z E! [inputs.snmp] Error in plugin: agent 192.168.2.11: gathering table interface: performing bulk walk for field ifDescr: request timeout (after 3 retries)
2022-09-29T10:06:50Z E! [inputs.snmp] Error in plugin: agent 192.168.2.1: gathering table interface: performing bulk walk for field ifDescr: request timeout (after 3 retries)
2022-09-29T10:06:50Z E! [inputs.snmp] Error in plugin: agent 172.20.0.1: gathering table interface: performing bulk walk for field ifDescr: request timeout (after 3 retries)
2022-09-29T10:06:53Z D! [outputs.influxdb_v2] Buffer fullness: 0 / 10000 metrics
2022-09-29T10:07:00Z W! [inputs.snmp] Collection took longer than expected; not complete after interval of 30s
2022-09-29T10:07:00Z D! [inputs.snmp] Previous collection has not completed; scheduled collection skipped
2022-09-29T10:07:03Z D! [outputs.influxdb_v2] Wrote batch of 124 metrics in 38.095971ms
2022-09-29T10:07:03Z D! [outputs.influxdb_v2] Buffer fullness: 0 / 10000 metrics
2022-09-29T10:07:13Z D! [outputs.influxdb_v2] Buffer fullness: 0 / 10000 metrics

Dans le Data explorer de InfluxDB2 WebUI, il ne trouve pas non plus le mesurement "snmp.SYNO" et du coup pas les "agent_host" :

8g0TJoc.png

Manisfestement il ya un problème avec le snmp.SYNO, j'ai du monté le timeout à 60s pour faire disparaitre les erreurs sur les tables. pour les collections j'ai même testé avec un interval de 600s mais cela ne marche pas non plus ! 

2022-09-29T11:30:00Z W! [inputs.snmp] Collection took longer than expected; not complete after interval of 10m0s
2022-09-29T11:30:00Z D! [inputs.snmp] Previous collection has not completed; scheduled collection skipped

Je ne comprends pas, on doit bien pouvoir implenter le snmp v3 sur synology ! Je ne vois pas qu'est-ce que je rate ?

EDIT :

Je viens de faire un telegraf --test  cà bloque sur ces tables, j'ai vérifié les indentations, mais cela semble OK de ce coté là. ce qui est bizarre, c'est que cela touche tous les éléments pour lesquels il y a un is_tag=true, je les ai donc commentés et refait un test mais cela ne change rien ??? 

2022-09-29T12:31:40Z E! [inputs.snmp] Error in plugin: agent 172.20.0.1: performing get on field sysName: request timeout (after 3 retries)
2022-09-29T12:31:40Z E! [inputs.snmp] Error in plugin: agent 192.168.2.11: performing get on field sysName: request timeout (after 3 retries)
2022-09-29T12:31:40Z E! [inputs.snmp] Error in plugin: agent 192.168.2.1: performing get on field sysName: request timeout (after 3 retries)
2022-09-29T12:32:20Z E! [inputs.snmp] Error in plugin: agent 172.20.0.1: gathering table interface: performing bulk walk for field ifDescr: request timeout (after 3 retries)
2022-09-29T12:32:20Z E! [inputs.snmp] Error in plugin: agent 192.168.2.11: gathering table interface: performing bulk walk for field ifDescr: request timeout (after 3 retries)
2022-09-29T12:32:20Z E! [inputs.snmp] Error in plugin: agent 192.168.2.1: gathering table interface: performing bulk walk for field ifDescr: request timeout (after 3 retries)
2022-09-29T12:33:00Z E! [inputs.snmp] Error in plugin: agent 192.168.2.11: gathering table diskTable: performing bulk walk for field diskID: request timeout (after 3 retries)
2022-09-29T12:33:00Z E! [inputs.snmp] Error in plugin: agent 172.20.0.1: gathering table diskTable: performing bulk walk for field diskID: request timeout (after 3 retries)
2022-09-29T12:33:00Z E! [inputs.snmp] Error in plugin: agent 192.168.2.1: gathering table diskTable: performing bulk walk for field diskID: request timeout (after 3 retries)
2022-09-29T12:33:40Z E! [inputs.snmp] Error in plugin: agent 172.20.0.1: gathering table raidTable: performing bulk walk for field raidName: request timeout (after 3 retries)
2022-09-29T12:33:40Z E! [inputs.snmp] Error in plugin: agent 192.168.2.11: gathering table raidTable: performing bulk walk for field raidName: request timeout (after 3 retries)
2022-09-29T12:33:40Z E! [inputs.snmp] Error in plugin: agent 192.168.2.1: gathering table raidTable: performing bulk walk for field raidName: request timeout (after 3 retries)
2022-09-29T12:34:20Z E! [inputs.snmp] Error in plugin: agent 192.168.2.11: gathering table diskSMARTTable: performing bulk walk for field diskSMARTInfoDevName: not in time window
2022-09-29T12:34:20Z E! [inputs.snmp] Error in plugin: agent 172.20.0.1: gathering table diskSMARTTable: performing bulk walk for field diskSMARTInfoDevName: not in time window
2022-09-29T12:34:20Z E! [inputs.snmp] Error in plugin: agent 192.168.2.1: gathering table diskSMARTTable: performing bulk walk for field diskSMARTInfoDevName: not in time window
2022-09-29T12:35:00Z E! [inputs.snmp] Error in plugin: agent 172.20.0.1: gathering table storageIOTable: performing bulk walk for field storageIODevice: request timeout (after 3 retries)
2022-09-29T12:35:00Z E! [inputs.snmp] Error in plugin: agent 192.168.2.11: gathering table storageIOTable: performing bulk walk for field storageIODevice: request timeout (after 3 retries)
2022-09-29T12:35:00Z E! [inputs.snmp] Error in plugin: agent 192.168.2.1: gathering table storageIOTable: performing bulk walk for field storageIODevice: request timeout (after 3 retries)
2022-09-29T12:35:40Z E! [inputs.snmp] Error in plugin: agent 172.20.0.1: gathering table ethPortTable: performing bulk walk for field ethPortIndex: request timeout (after 3 retries)
2022-09-29T12:35:40Z E! [inputs.snmp] Error in plugin: agent 192.168.2.11: gathering table ethPortTable: performing bulk walk for field ethPortIndex: request timeout (after 3 retries)
2022-09-29T12:35:40Z E! [inputs.snmp] Error in plugin: agent 192.168.2.1: gathering table ethPortTable: performing bulk walk for field ethPortIndex: request timeout (after 3 retries)
2022-09-29T12:36:20Z E! [inputs.snmp] Error in plugin: agent 172.20.0.1: gathering table laTable: performing bulk walk for field laNames: request timeout (after 3 retries)
2022-09-29T12:36:20Z E! [inputs.snmp] Error in plugin: agent 192.168.2.11: gathering table laTable: performing bulk walk for field laNames: request timeout (after 3 retries)
2022-09-29T12:36:20Z E! [inputs.snmp] Error in plugin: agent 192.168.2.1: gathering table laTable: performing bulk walk for field laNames: request timeout (after 3 retries)
2022-09-29T12:37:00Z E! [inputs.snmp] Error in plugin: agent 192.168.2.11: gathering table hrStorageTable: performing bulk walk for field hrStorageDescr: not in time window
2022-09-29T12:37:00Z E! [inputs.snmp] Error in plugin: agent 172.20.0.1: gathering table hrStorageTable: performing bulk walk for field hrStorageDescr: not in time window
2022-09-29T12:37:00Z E! [inputs.snmp] Error in plugin: agent 192.168.2.1: gathering table hrStorageTable: performing bulk walk for field hrStorageDescr: not in time window
2022-09-29T12:37:00Z D! [agent] Stopping service inputs
2022-09-29T12:37:00Z D! [agent] Input channel closed
2022-09-29T12:37:00Z D! [agent] Processor channel closed
2022-09-29T12:37:00Z D! [agent] Processor channel closed
2022-09-29T12:37:00Z D! [agent] Stopped Successfully
2022-09-29T12:37:00Z E! [telegraf] Error running agent: input plugins recorded 27 errors

Une idée peut-être ?

Cordialement

oracle7😉

Modifié par oracle7
0
.Shad. Grand Master

.Shad.

Posté(e)
  • Auteur
Posté(e) (modifié)

Là en l'état je ne pourrai pas t'aider plus. Je n'ai pas assez de temps libre pour me lancer dans une révision de mon monitoring malheureusement. Si tu arrives à résoudre ton problème n'hésite pas à partager la solution.

Modifié par .Shad.
0
oracle7 Grand Master

oracle7

Posté(e)
Posté(e)

@.Shad.

Bonjour,

Une question peut-être idiote mais peux-tu STP me confirmer la chose. Je m'explique :

  1. J'utilise le réseau 172.20.0.0/24 (monitoring) pour mes conteneurs docker.
  2. Par ailleurs sur mon PC local j'utilise WSL (Ubuntu 24.04.5 LTS) qui lui utilise aussi le réseau 172.20.0.0/24 sur l'interface eth1 pour le SWAP.

Donc ma question, normalement il ne doit pas y avoir d'interférences entre les deux ? C'est bien deux choses différentes, rassures-moi car je m'y perd un peu ...

Cordialement

oracle7😉

 

0
MilesTEG1 Veteran

MilesTEG1

Posté(e)
Posté(e)
Il y a 2 heures, oracle7 a dit :

Par ailleurs sur mon PC local j'utilise WSL (Ubuntu 24.04.5 LTS) qui lui utilise aussi le réseau 172.20.0.0/24 sur l'interface eth1 pour le SWAP.

Comment as-tu vu ça ?
Ça m'intéresse, car j'ai eu récemment un soucis avec ce genre d'adresses sur mon pc qui lui aussi à WSL2 d'installé avec un Ubuntu.

0
.Shad. Grand Master

.Shad.

Posté(e)
  • Auteur
Posté(e)

Ce sont deux sous-réseaux privés liés à ta machine.

Ils n'ont aucune raison de se causer entre eux, hormis par l'intermédiaire du NAT sur les hôtes respectifs, aucune raison qu'il y ait donc des problèmes de routage.

0
oracle7 Grand Master

oracle7

Posté(e)
Posté(e)

@.Shad.

Bonjour,

Merci de ta réponse rassurante s'il en est. C'est bien ce qui me semblait aussi mais dans le doute j'ai préféré poser la question.

Pour mes problèmes de collection non complète, tu n'aurais une piste que je puisse explorer ?

Je ne vois pas ce qui peut se passer d'autant plus que les requêtes snmpwalk snmp v3 sur les MIBS quelque qu'elles soient renvoient les données instantanément. C'est cà qui est bizarre ...

Cordialement

oracle7😉

0

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.

Invité
Répondre à ce sujet…

×   Collé en tant que texte enrichi.   Coller en tant que texte brut à la place

  Seulement 75 émoticônes maximum sont autorisées.

×   Votre lien a été automatiquement intégré.   Afficher plutôt comme un lien

×   Votre contenu précédent a été rétabli.   Vider l’éditeur

×   Vous ne pouvez pas directement coller des images. Envoyez-les depuis votre ordinateur ou insérez-les depuis une URL.

×
 Partager
Aller sur la liste des sujets
×
×
  • Créer...

Information importante

Nous avons placé des cookies sur votre appareil pour aider à améliorer ce site. Vous pouvez choisir d’ajuster vos paramètres de cookie, sinon nous supposerons que vous êtes d’accord pour continuer.