See www.zabbix.com for the official Zabbix site.

Docs/specs/ZBXNEXT-1554

From Zabbix.org
Jump to: navigation, search

Discovery of arbitrary number of SNMP LLD values

ZBXNEXT-1554

Status: v1.0

Owner: Alexei

Summary

Zabbix should support LLD discovery of multiple SNMP values. This feature would allow to get information about ifDescr, ifAlias, etc using one discovery rule.

Specification

Item OID field will accept values in the existing format used for Zabbix keys, quotes are supported as well:

 discovery[{#MACRO1}, oid1, {#MACRO2}, oid2, {#MACRO3}, oid3, ...]

At least one combination of {#MACRO} and OID must be given.

For example:

 discovery[{#IFDESCR}, ifDescr, {#IFALIAS}, ifAlias]

The item will return LLD compatible JSON structure having {#SNMPINDEX}, {#MACRO1}, {#MACRO2}, etc defined. If there is no value for a particular combination of index and OID, the value will be skipped, however values from other OIDs will present. Indexes of all OIDs will be merged, therefore if there is oid2.indexABC but no oid1.indexABC then the item will return {#SNMPINDEX}==indexABC and {#MACRO2}. No {#MACRO1} will be included.

If one of OID does not exist, it will be skipped, i.e. no values for this OID will be generated.

Compound indexes will be supported same way as for existing SNMP checks.

OIDs will never be processed as a dynamic SNMP index.

Existing SNMP discovery

Existing SNMP discovery rules will be converted to take advantage of the new syntax, old syntax will no longer will be supported.

Database changes

A new patch will update all SNMP discovery rules to a new syntax. Existing field SNMP OID will be converted the following way:

 Before: OID
 After: discovery[{#SNMPVALUE}, OID]

Example

 ifDescr.1 "Interface #1"
 ifDescr.2 "Interface #2"
 ifDescr.4 "Interface #4"
 ifAlias.1 "eth0"
 ifAlias.2 "eth1"
 ifAlias.3 "eth2"
 ifAlias.5 "eth4"
 ifState  # this OID does not exist

In this case item discovery[{#IFDESCR}, ifDescr, {#IFALIAS}, ifAlias, {#IFSTATE}, ifState] will return the following structure:

  {
     "data":[
        {"{#SNMPINDEX}":1,"{#IFDESCR}":"Interface #1","{#IFALIAS}":"eth0"},
        {"{#SNMPINDEX}":2,"{#IFDESCR}":"Interface #2","{#IFALIAS}":"eth1"},
        {"{#SNMPINDEX}":3,"{#IFALIAS}":"eth2"},
        {"{#SNMPINDEX}":4,"{#IFDESCR}":"Interface #4"},
        {"{#SNMPINDEX}":5,"{#IFALIAS}":"eth4"}
     ]
  }

Validation

Server will validate discovery rules:

  • It is allowed to have same OIDs in different MACRO/OID pairs
  • No limit on number of MACRO/OID pairs
  • OID must match "discovery[*]", other OIDs will not be accepted
 Invalid SNMP OID: prefix "discovery[" expected.
  • Macros must be unique and must not be equal to {#SNMPINDEX}
 Invalid SNMP OID: unique macros expected.
 Invalid SNMP OID: macro "{#SNMPINDEX}" is not allowed.
  • Format of the macros must be validated
 Invalid SNMP OID: macro "%s" is invalid.
  • We must validate that there are exactly two elements for each parameter
 Invalid SNMP OID: pairs of macro and OID are expected.

Documentation

Also discussed

  • No OID syntax validation will be introduced on front-end side. We'll implement it after transferring API to the server.

ChangeLog

  • N/A