zabbix / community-templates

Zabbix Community Templates repository
https://share.zabbix.com
MIT License
1.25k stars 1.77k forks source link

Template: Synology DiskStation SNMPv3: Fixing Storage Size in Low Level Discovery #297

Closed sscheib closed 8 months ago

sscheib commented 8 months ago

The template Synology DiskStation SNMPv3 hardcoded 4096 as custom multiplier for the following discovered items:

The Synology Storage MIB Guide clearly states:

hrStorageSize: The size of the storage represented by this entry, in units of hrStorageAllocationUnits

hrStorageAllocationUnits: The size, in bytes, of the data objects allocated from this pool

Therefore, the correct calculation of the hrStorageSize would be: hrStorageSize * hrStorageAllocationUnits

This will yield the correct Storage Size and Storage Used in bytes.

I have tested and verified this on two different Synology systems:

  1. DS918+
  2. DS3617xs

Each hrStorageDescr (e.g. /volume1) has its own hrStorageAllocationUnits, as seen in the following output of SNMP walk:

# OIDs
.1.3.6.1.2.1.25.2.3.1.4.1 = INTEGER: 1024 Bytes
.1.3.6.1.2.1.25.2.3.1.4.3 = INTEGER: 1024 Bytes
.1.3.6.1.2.1.25.2.3.1.4.6 = INTEGER: 1024 Bytes
.1.3.6.1.2.1.25.2.3.1.4.7 = INTEGER: 1024 Bytes
.1.3.6.1.2.1.25.2.3.1.4.8 = INTEGER: 1024 Bytes
.1.3.6.1.2.1.25.2.3.1.4.10 = INTEGER: 1024 Bytes
.1.3.6.1.2.1.25.2.3.1.4.11 = INTEGER: 1024 Bytes
.1.3.6.1.2.1.25.2.3.1.4.31 = INTEGER: 4096 Bytes
.1.3.6.1.2.1.25.2.3.1.4.36 = INTEGER: 4096 Bytes
.1.3.6.1.2.1.25.2.3.1.4.38 = INTEGER: 4096 Bytes
.1.3.6.1.2.1.25.2.3.1.4.39 = INTEGER: 4096 Bytes
.1.3.6.1.2.1.25.2.3.1.4.50 = INTEGER: 4096 Bytes
.1.3.6.1.2.1.25.2.3.1.4.55 = INTEGER: 65536 Bytes
.1.3.6.1.2.1.25.2.3.1.4.56 = INTEGER: 65536 Bytes
.1.3.6.1.2.1.25.2.3.1.4.57 = INTEGER: 65536 Bytes
.1.3.6.1.2.1.25.2.3.1.4.58 = INTEGER: 131072 Bytes
.1.3.6.1.2.1.25.2.3.1.4.59 = INTEGER: 131072 Bytes

# OIDs translated
HOST-RESOURCES-MIB::hrStorageAllocationUnits.1 = INTEGER: 1024 Bytes
HOST-RESOURCES-MIB::hrStorageAllocationUnits.3 = INTEGER: 1024 Bytes
HOST-RESOURCES-MIB::hrStorageAllocationUnits.6 = INTEGER: 1024 Bytes
HOST-RESOURCES-MIB::hrStorageAllocationUnits.7 = INTEGER: 1024 Bytes
HOST-RESOURCES-MIB::hrStorageAllocationUnits.8 = INTEGER: 1024 Bytes
HOST-RESOURCES-MIB::hrStorageAllocationUnits.10 = INTEGER: 1024 Bytes
HOST-RESOURCES-MIB::hrStorageAllocationUnits.11 = INTEGER: 1024 Bytes
HOST-RESOURCES-MIB::hrStorageAllocationUnits.31 = INTEGER: 4096 Bytes
HOST-RESOURCES-MIB::hrStorageAllocationUnits.36 = INTEGER: 4096 Bytes
HOST-RESOURCES-MIB::hrStorageAllocationUnits.38 = INTEGER: 4096 Bytes
HOST-RESOURCES-MIB::hrStorageAllocationUnits.39 = INTEGER: 4096 Bytes
HOST-RESOURCES-MIB::hrStorageAllocationUnits.50 = INTEGER: 4096 Bytes
HOST-RESOURCES-MIB::hrStorageAllocationUnits.55 = INTEGER: 65536 Bytes
HOST-RESOURCES-MIB::hrStorageAllocationUnits.56 = INTEGER: 65536 Bytes
HOST-RESOURCES-MIB::hrStorageAllocationUnits.57 = INTEGER: 65536 Bytes
HOST-RESOURCES-MIB::hrStorageAllocationUnits.58 = INTEGER: 131072 Bytes
HOST-RESOURCES-MIB::hrStorageAllocationUnits.59 = INTEGER: 131072 Bytes

The last digit of the OID .1.3.6.1.2.1.25.2.3.1.4. (e.g. 56) represents the device index number and is consistent with the respective discoveries of each of the hrStorageDescr.

Coincidentally, hrStorageAllocationUnits is retrieved already via Low Level Discovery as {#IFUNIT}:

discovery[{#IFINDEX},.1.3.6.1.2.1.25.2.3.1.1,{#IFDESCR},.1.3.6.1.2.1.25.2.3.1.3,{#IFUNIT},.1.3.6.1.2.1.25.2.3.1.4]

The fix is quite trivial: Simply replace 4096 with {#IFUNIT} in the preprocessing steps 🙂