oracle7

@limannzerga Bonjour, C'est normal car ton ndd.fr est défini et pointe sur ton @IP externe réelle (celle de ta box/routeur) alors que une fois connecté au serveur VPN extérieur, celui-ci t'attribue une autre @IP externe (c'est l'objectif quand on veux "masquer son @IP réelle pour surfer sur la toile de façon "anonyme"). PS : Toujours pas passé par la case PRESENTATION ? 🥴 Cordialement oracle7😉

@cotp Bonjour, J'ai repris le fil depuis le début et j'avoue avoir un peu de mal à te suivre avec tous tes disques et tes manipulations avec eux. Mais pas grave ...🤪 De toutes façons, tous les intervants précédants t'ont fourni tout le long de judicieuses réponses à tes questions si je ne m'abuse ... Cela dit, pour le dernier disque (12To) que tu évoques, pourquoi tu ne branches pas ton boitier USB au NAS comme préconisé par @firlin ? qu'est-ce qui t'en empêche ? Ensuite tu appliques le TUTO badblocks comme préconisé. Ce site ne t'apporte rien de plus que le TUTO de firlin, bien au contraire, au moins le TUTO de firlin est en français et facile à suivre. Toutes les instructions sont claires tu n'as juste qu'à adapter à ton cas particulier pour certains paramètres. Maintenant, tu peux toujours lancer un test de surface avec l'outil constructeur ou tout autre outil tiers (cela n'engage à rien) mais si ton disque (12 To) présente des défauts de secteurs et qu'il est neuf, ne cherche pas plus loin et fait jouer la garantie avec ton vendeur AVANT qu'elle n'expire. Tu lui retournes le disque et soit il te rembourse ou soit il t'en renvoie un autre (notes bien le N° de série pour qu'il ne te renvoie le même "reconditionné" ! mieux vaut être prudent !!! 🤣). Au final : @ml78 a complétement raison. Difficile de te dire mieux 🙂. Cordialement oracle7😉

@cotp Bonjour, C'est normal ce n'est pas une commande reconnue par Windows. C'est une commande du monde UNIX/Linux sur lequel est basé DSM, elle n'est effective que dans une session sous SSH. Le mieux que tu ais à faire est de lire au moins une fois ENTIEREMENT le TUTO de @firlin dont j'ai donné le lien dans ma réponse précédante puis d'appliquer les termes de ce TUTO à ton cas particulier. Tout y est expliqué clairement. Il n'y a rien de bien compliqué, il te suffira juste d'être très attentionné à ce que tu tapes, notamment sous SSH et tu verras tout se passera bien. Ensuite il te faudra être patient voire très patient selon la taille et le nombre de disques que tu vas tester. Au bas mot cela te prendra en gros au moins une trentaine d'heures (c'était cela pour 3 disques de 4To chacun, testés en même temps chez moi). De toutes façons tu as une commande qui te permet de suivre l'évolution au travers des logs générés. Cordialement oracle7😉

@MilesTEG1 Bonjour, Pour mémoire, dans son TUTO : Préparation des disques avec Badblocks, firlin a dit : Cordialement oracle7😉

@.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😉

@MilesTEG1 Bonjour, Tout simplement dans le message d'invite au lancement de WSL, confirmé avec un ipconfig. D'où mon doute ... Cordialement oracle7😉

@.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😉

@.Shad. Bonjour, Bien d'accord avec toi. 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😉

@.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😉

@pbai Bonjour, 1 - Comme sur tout forum, il est d'usage que les nouveaux membres passent par la rubrique [PRESENTATION] pour faire la leur. Certains ici, y sont sensibles et de plus cela facilite les réponses en fonction du niveau de compétences du membre et de ses équipements. Cela dit, rassures-toi il n'est pas trop tard pour bien faire ... 2 - Pour commencer, as-tu, lus et appliqués les TUTO suivants : TUTO : Débuter avec un NAS Synology TUTO : Sécuriser les accès à son NAS Dans le cas contraire, avant toutes choses, je t'invite à les suivre. 3 - Le port 443 est-il bien transféré de ta box vers ton NAS et est-il bien ouvert/autorisé dans le pare-feu du NAS ? 4 - As-tu une @IP externe fixe ou dynamique ? si dynamique, as-tu défini un DDNS pour xxx.synology.me qui pointe sur cette @IP externe ? 5 - As-tu défini un certificat pour xxx.synology.me avec dans autre nom de l'objet *.xxx.synology.me ? 6 - Si 3 = oui, alors vérifie que ton domaine pointe bien chez toi, en passant la commande ping calibreweb.xxx.synology.me. La réponse doit être ton @IP Externe (celle de ta box !). idem dans une fenêtre de CMD Windows ou dans un terminal SSH via PuTTY ou WinSCP, sous user root que nslookup calibreweb.xxx.synology.me 8.8.8.8, ça doit aussi te faire tomber sur ton @IP Externe. 7 - NON si tu utilises le proxy inversé, il ne faut pas mettre le port 8085 dans l'URL. Implicitement c'est le port 443 qui est utilisé et que tu dois indiquer dans la définition de la règle de proxy inversé. Par ex : et ton URL de connexion est alors simplement : https://calibreweb.xxx.synology.me . Cordialement oracle7😉

@.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😉

@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😉

@bliz Bonjour, J'ai voulu satisfaire ta curriosité en MP mais tu ne peux recevoir de messages ... Cordialement oracle7😉

@Jeff777 Bonjour, 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😉

@bliz Bonjour, Petite disgression juste pour rafraichir la mémoire. En mathématiques cela s'appelle une permutation à n chiffres qui a pour résultat factoriel n si je ne m'abuse. Nombre de permutations (ou de combinaisons) d'un ensemble à n éléments distincts : n!=n×(n−1)×(n−2)×⋯×3×2×1 Pour le Loto, si mes souvenirs sont bons le nombre de combinaisons possibles pour 49 éléments (n) pris 7 à 7 (k), la formule est : Nombre de combinaisons possibles=n! / k!(n−k)! Cordialement oracle7😉

@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😉

@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😉

@Jeff777 Bonjour, 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😉

@bliz Bonjour, Je n'utilise pas iotop, je vais sous SSH et je tapes alors par ex : ps -aux c'est tout aussi efficace non ? Je te renvoie au "man ps" pour plus de détails sur PS qui est une commande standard des distribution basée sur UNIX/Linux tel que DSM. En plus ainsi il n'y a pas d'outil tiers à rajouter à DSM... De toutes façons, sauf erreur de ma part, ce type d'ajout (iotop) ne résiste pas à une MàJ de DSM. Cordialement oracle7😉

@bliz Bonjour, Je pense qu'il vaut mieux tagger les utilisateurs auquels on répond car sinon d'expérience la réponse peut se retrouvée noyée parmi toutes les autres et ce d'autant plus s'il le destinataire ne suit pas le fil en question. Au moins comme cela on ne rate rien ... Cordialement oracle7😉

@flyjodel Bonjour, Du coup tu n'aurais pas une indexation multimédia en cours ? (d'autant plus longue que tu as beaucoup de photos) A vérifier ... Sinon accessoirement : Astuce : Pour avertir un membre de ta réponse, tu tapes dans ton message "@" + les premiers caractères de son pseudo. Dans le popup qui apparaît tu cliques alors sur le pseudo recherché et il s'affiche sur fond bleu dans ton texte. Ainsi ton interlocuteur est informé/notifié de ta réponse sinon il ne voit rien sauf à rebalayer en arrière tous les messages (ce que peu de monde fait). Cordialement oracle7😉

@flyjodel Bonjour, A tout hasard, tu n'aurais pas une analyse en cours avec le Conseiller du Cache SSD ? Si oui cela pourrait expliquer ton activité disque quasi permanente. Cela dit elle devrait s'arrêter d'elle même au bout de 30 Jours si tu n'interviens pas manuellement ... Sinon tu n'as pas de caméras qui enregistrent en continu sur ton NAS ? Cordialement oracle7😉

@.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😉

@faluorn Bonjour, As-tu trouvé la parade à cette erreur ? Merci de ta réponse. Cordialement oracle7😉

@manu:) Bonjour, Si tes points d'accès wifi sont des MR2200 en mesh alors quand tu importera le fichier .pat de màj il te faudra aussi importer le .pat pour chaque MR2200. Cordialement oracle7😉