oracle7 Posté(e) le 25 septembre 2022 Posté(e) le 25 septembre 2022 @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 Citer
oracle7 Posté(e) le 26 septembre 2022 Posté(e) le 26 septembre 2022 (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é le 26 septembre 2022 par oracle7 0 Citer
Jeff777 Posté(e) le 27 septembre 2022 Posté(e) le 27 septembre 2022 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 Citer
oracle7 Posté(e) le 27 septembre 2022 Posté(e) le 27 septembre 2022 @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 Citer
Jeff777 Posté(e) le 27 septembre 2022 Posté(e) le 27 septembre 2022 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 Citer
oracle7 Posté(e) le 27 septembre 2022 Posté(e) le 27 septembre 2022 @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 Citer
Jeff777 Posté(e) le 27 septembre 2022 Posté(e) le 27 septembre 2022 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 Citer
oracle7 Posté(e) le 27 septembre 2022 Posté(e) le 27 septembre 2022 @Jeff777 Bonjour, MERCI 😀. Petite précision : je teste aussi avec Influxdb v2.4 : peut-être aussi que j'ai raté un truc à ce niveau, vas savoir ... Cordialement oracle7😉 0 Citer
Jeff777 Posté(e) le 27 septembre 2022 Posté(e) le 27 septembre 2022 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 Citer
oracle7 Posté(e) le 27 septembre 2022 Posté(e) le 27 septembre 2022 @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 Citer
Jeff777 Posté(e) le 27 septembre 2022 Posté(e) le 27 septembre 2022 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 Citer
oracle7 Posté(e) le 27 septembre 2022 Posté(e) le 27 septembre 2022 @Jeff777 Bonjour, C'est en cours, mais il y a encore beaucoup de choses à valider avant de publier quoique ce soit. D'où mes questions au fil de l'eau ... Cordialement oracle7😉 1 Citer
.Shad. Posté(e) le 27 septembre 2022 Auteur Posté(e) le 27 septembre 2022 (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. 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é le 27 septembre 2022 par .Shad. 0 Citer
oracle7 Posté(e) le 27 septembre 2022 Posté(e) le 27 septembre 2022 (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é le 27 septembre 2022 par oracle7 0 Citer
.Shad. Posté(e) le 27 septembre 2022 Auteur Posté(e) le 27 septembre 2022 Tu as mis cb de secondes en timeout dans l'input SNMP pour le NAS ? 0 Citer
oracle7 Posté(e) le 28 septembre 2022 Posté(e) le 28 septembre 2022 @.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 Citer
.Shad. Posté(e) le 28 septembre 2022 Auteur Posté(e) le 28 septembre 2022 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 Citer
oracle7 Posté(e) le 29 septembre 2022 Posté(e) le 29 septembre 2022 (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" : 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é le 29 septembre 2022 par oracle7 0 Citer
.Shad. Posté(e) le 29 septembre 2022 Auteur Posté(e) le 29 septembre 2022 (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é le 29 septembre 2022 par .Shad. 0 Citer
MilesTEG1 Posté(e) le 30 septembre 2022 Posté(e) le 30 septembre 2022 Ça m’a l’air d’être vraiment la merde ce influxdb 2 !! Et comme @.Shad. Je n’ai vraiment pas le temps de changer quoique ce soit 😅 0 Citer
oracle7 Posté(e) le 30 septembre 2022 Posté(e) le 30 septembre 2022 @.Shad. Bonjour, Une question peut-être idiote mais peux-tu STP me confirmer la chose. Je m'explique : J'utilise le réseau 172.20.0.0/24 (monitoring) pour mes conteneurs docker. 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 Citer
MilesTEG1 Posté(e) le 30 septembre 2022 Posté(e) le 30 septembre 2022 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 Citer
oracle7 Posté(e) le 30 septembre 2022 Posté(e) le 30 septembre 2022 @MilesTEG1 Bonjour, il y a 30 minutes, MilesTEG1 a dit : Comment as-tu vu ça ? Tout simplement dans le message d'invite au lancement de WSL, confirmé avec un ipconfig. D'où mon doute ... Cordialement oracle7😉 0 Citer
.Shad. Posté(e) le 30 septembre 2022 Auteur Posté(e) le 30 septembre 2022 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 Citer
oracle7 Posté(e) le 30 septembre 2022 Posté(e) le 30 septembre 2022 @.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 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.