Zabbix offers a lot of methods for data gathering, including SNMP. SNMP has been a popular protocol for many years and probably will stay that way – it’s used on routers, switches, UPS devices, storage arrays and lots of other devices. Zabbix 2.2 will improve the existing SNMP support in several ways.
Articles in 2.2 feature series:
- Part 1 – Automatic database upgrading
- Part 2 – Templated web monitoring
- Part 3 – Web scenario retries
- Part 4 – HTTP proxy for web monitoring
- Part 5 – Better value mapping
- Part 6 – Returning values from webpages
- Part 7 – Value extracting from logfiles and more
- Part 8 – Reusing content in web monitoring
- Part 9 – No more full page reload in latest data
- Part 10 – Support of loadable modules
- Part 11 – SNMP monitoring improvements
SNMPv3 related improvements
SNMP versions 1 and 2c are still popular, but offer very weak security measures. SNMPv3, among other improvements, does provide better security as well and is gaining popularity lately. Zabbix 2.2 has two SNMPv3 related improvements.
Context name support
SNMPv3 offers the ability to specify a “context”. Context is a way to identify one of many identical or similar entities behind a single SNMP endpoint. Citing from RFC 3411:
An SNMP context, or just “context” for short, is a collection of management information accessible by an SNMP entity. An item of management information may exist in more than one context. An SNMP entity potentially has access to many contexts.
For example, a UPS management station might be connected to individual devices, but expose only a single SNMP interface. These devices would have identical OIDs for some things (system description, temperature), but it would not be able to identify which device we want the information about. This is where SNMP context comes into play – here the context would be the individual UPS device name.
Starting with Zabbix 2.2, for SNMPv3 a context name may be specified. It is supported in:
- normal items
- low level discovery rule
- low level discovery item prototype
- network discovery
To allow easy management of devices where multiple items would need to use context, user macros may be used in the context field in all of the supported locations.
Currently only MD5 for authentication and DES for privacy in SNMPv3 are supported by Zabbix. More secure methods are available and have been requested by Zabbix users, thus 2.2 will also support SHA for authentication and AES for privacy.
SNMP retry and timeout changes
Currently, Zabbix server or proxy will not specify timeout or retry for SNMP operations, resulting in the defaults from the Net-SNMP library being used. The default timeout is one second and the default retry count is 5 seconds, thus a check which would take a bit longer than one second would never succeed, but would still be attempted 6 times in total. Additionally, this would significantly slow down SNMP network discovery, as any device not responding to SNMP would still take around 6 seconds to probe (for each SNMP check).
Starting with Zabbix 2.2, the daemons will use the Timeout parameter value from the corresponding configuration file (defaulting to 3 seconds) and will attempt no retries if the request failed (for example, timed out because of network issues or incorrect credentials).
Complex OIDs for low level discovery
Currently, SNMP low level discovery only used the last value from the OID. This caused problems when the index was longer. For example, in the following OIDs the last two numbers together represent the index:
CISCO-POP-MGMT-MIB::cpmDS1ActiveDS0s.6.0 CISCO-POP-MGMT-MIB::cpmDS1ActiveDS0s.6.1 CISCO-POP-MGMT-MIB::cpmDS1ActiveDS0s.7.0
When discovering by OID CISCO-POP-MGMT-MIB::cpmDS1ActiveDS0s, Zabbix would create items for the first two OIDs as 0 and 1, then fail to create item for the third OID. Now the full OID part will be used.
Additionally, strings as indexes will be supported in Zabbix 2.2.