search

centreon / centreon-plugins

Collection of standard plugins to discover and gather cloud-to-edge metrics and status across your whole IT infrastructure.
https://www.centreon.com
Apache License 2.0
308 stars 270 forks source link

[storage::qnap::snmp::plugin] --mode=hardware: UNKNOWN - SNMP timeout #4647

Open joschi99 opened 10 months ago

joschi99 commented 10 months ago

On newer QNAP Firmwares (5.1.x) the hardware mode will fail, because a legacy counter is not more available:

UNKNOWN: SNMP Table Request: Timeout
.1.3.6.1.4.1.24681.2.2.4.0 = undef
.1.3.6.1.4.1.55062.1.12.3.0 = TVS-471U-RP
Checking disks
.1.3.6.1.4.1.55062.1.10.2.1.2.1 = 1
.1.3.6.1.4.1.55062.1.10.2.1.2.2 = 2
.1.3.6.1.4.1.55062.1.10.2.1.2.3 = 3
.1.3.6.1.4.1.55062.1.10.2.1.2.4 = 4
.1.3.6.1.4.1.55062.1.10.2.1.3.1 = WDC
.1.3.6.1.4.1.55062.1.10.2.1.3.2 = WDC

The Enterprise OID .1.3.6.1.4.1.24681. does not respond anymore and the plugin failes.

Workaround: add option --snmp-force-getnext, but maybe you will change the behaviour on plugin.

NTIC94130 commented 10 months ago

Hello,

I have the same problem here with new version of firmware QNAP : QTS 5.1.1.2491

Snmp walk is fine

But with this 2 sensors i have this message : SNMP Table Request: Timeout

Volumes and Hardware.

For the hardware sensor , i use the workaround add --snmp-force-getnext

But for the volumes sensor, it's not working still have the message : /usr/lib/centreon/plugins//centreon_qnap.pl --plugin=storage::qnap::snmp::plugin --mode=volumes --hostname='172.26.0.22' --snmp-version='2c' --snmp-community='public' --filter-name='' --warning-space-usage='' --critical-space-usage='' --warning-space-usage-free='' --critical-space-usage-free='' --warning-space-usage-prct='' --critical-space-usage-prct='' --warning-volume-status='%{status} =~ /degraded|warning/i' --critical-volume-status='%{status} =~ /critical/i' --verbose --snmp-autoreduce UNKNOWN: SNMP Table Request: Timeout

I try to add also : --snmp-timeout:10 --snmp-force-getnext --snmp-autoreduce and still message : /usr/lib/centreon/plugins//centreon_qnap.pl --plugin=storage::qnap::snmp::plugin --mode=volumes --hostname='172.26.0.22' --snmp-version='2c' --snmp-community='public' --filter-name='' --warning-space-usage='' --critical-space-usage='' --warning-space-usage-free='' --critical-space-usage-free='' --warning-space-usage-prct='' --critical-space-usage-prct='' --warning-volume-status='%{status} =~ /degraded|warning/i' --critical-volume-status='%{status} =~ /critical/i' --verbose --snmp-timeout=10 --snmp-force-getnext --snmp-autoreduce UNKNOWN: SNMP Table Request: Timeout

Sincerelly

Add SNMP Walk and Mibs of QNAP NAS_QNAP_08092023.zip QNAP_snmp_walk_11092023.zip

omercier commented 9 months ago

Hi, The --snmp-autoreduce option is meant to divide by two the bulk size of the requests until the device answers correctly, but your device does not seem to handle bulk requests well. Instead, can you try using --snmp-version='1' ?

NTIC94130 commented 9 months ago

Hello, sorry for the delay. So i have change the snmp version to 1 and i dont need anymore the option for the sensor hardware.

I still have the problem with the sensor volumes since i have upgraded the firmware on the qnap : UNKNOWN: SNMP Table Request: Timeout.

Any advice is welcome.

Sincerelly

lzmarouane commented 8 months ago

Hi @omercier , I have the same issue since i've upgraded the firmware on the qnap : here is the command that i'm using : /usr/lib/centreon/plugins//centreon_qnap.pl --plugin=storage::qnap::snmp::plugin --mode=volumes --hostname='IP' --snmp-version='1' --snmp-community='public' --filter-name='' --warning-space-usage='' --critical-space-usage='' --warning-space-usage-free='' --critical-space-usage-free='' --warning-space-usage-prct='' --critical-space-usage-prct='' --warning-volume-status='%{status} =~ /degraded|warning/i' --critical-volume-status='%{status} =~ /critical/i' --snmp-autoreduce --verbose

But i get : UNKNOWN: SNMP Table Request: Timeout

Any advice is welcome.

Sincerelly

NTIC94130 commented 7 months ago

Hello,

Can you confirm the issue or give us a workaround for this sensor. I use snmp version 1 and still UNKNOWN: SNMP Table Request: Timeout

Sincerelly

joschi99 commented 7 months ago

Hi @NTIC94130, which plugin version are you using? Have you tried the option --snmp-force-getnext, because QNAP has removed the legacy counters on never firmware.

NTIC94130 commented 7 months ago

Hello,

So the command to check is : /usr/lib/centreon/plugins//centreon_qnap.pl --plugin=storage::qnap::snmp::plugin --mode=volumes --hostname='172.26.0.22' --snmp-version='1' --snmp-community='public' --filter-name='' --warning-space-usage='' --critical-space-usage='' --warning-space-usage-free='' --critical-space-usage-free='' --warning-space-usage-prct='' --critical-space-usage-prct='' --warning-volume-status='%{status} =~ /degraded|warning/i' --critical-volume-status='%{status} =~ /critical/i' --verbose --snmp-timeout=1 --snmp-force-getnext --snmp-autoreduce

And result : UNKNOWN: SNMP Table Request: Timeout

I am using latest version : centreon 23.10 and plugins : centreon-plugin-hardware-storage-qnap-snmp est déjà la version la plus récente (20231114-140340) and connectors : QNAP version 23.04.3 stable

I join the latest snmp walk in v1 and v2c

Sincerelly QNAP_snmp_walk_v1_29112023.txt QNAP_snmp_walk_v2c_29112023.txt

lzmarouane commented 7 months ago

can you add --snmp-timeout='10' --force-counters-legacy ??

NTIC94130 commented 7 months ago

Hello, many thanx for this solution. Worked like a charm. No more error

lucie-dubrunfaut commented 2 weeks ago

Hello :)

Thanks for the workaround proposed here to help users. About the initial issue @joschi99, if I understand well after an upgrade of QNAP Firmwares the OID .1.3.6.1.4.1.24681.2.2.4.0 is no longer supported. Can you tell us which new OID should be request to get the uptime?

joschi99 commented 2 weeks ago

QNAP has changed some OID in never firmwares, but as I know uptime is still the same on every firmware version. Did you have other informations about them?

lucie-dubrunfaut commented 2 weeks ago

I asked about uptime because the OID about which we are speaking (or how I understand) is related to systemUptime : $oid_es_uptime = '.1.3.6.1.4.1.24681.2.2.4.0'; # es-SystemUptime in the mode hardware line 89 I'm wondering if this OID doesn't work for all qnap monitored by this plugin or only for your type of equipment (QNAP Firmwares (5.1.x) and above)?

joschi99 commented 2 weeks ago

I have no information about them, sorry

lucie-dubrunfaut commented 1 week ago

Hello :)

Ok no worries, but the snmpwalk provided above didn't contain the .55062 oids so I can't rely them with the MIB to find another way to catch the es_uptime. Can you provide us an anonymized .snmpwalk (full snmpwalk of enterprise branch : snmpwalk -ObentU -v 2c -c public address .1.3.6.1.4.1 > equipment.snmpwalk) of your equipment to help us troubleshooting this issue ?

joschi99 commented 1 week ago

here you can find a snmpwalk for a QNAP containing .55062: qnap-55062.snmpwalk.txt