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

[joschi99]

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]

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]

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]

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]

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]

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]

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]

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]

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

[NTIC94130]

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

[lucie-tirand]

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]

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-tirand]

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]

I have no information about them, sorry

[lucie-tirand]

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]

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