Receiving SNMP traps is the opposite to querying SNMP-enabled devices.
In this case the information is sent from a SNMP-enabled device and is collected or "trapped" by Zabbix.
Usually traps are sent upon some condition change and the agent connects to the server on port 162 (as opposed to port 161 on the agent side that is used for queries). Using traps may detect some short problems that occur amidst the query interval and may be missed by the query data.
Receiving SNMP traps in Zabbix is designed to work with snmptrapd and one of the built-in mechanisms for passing the traps to Zabbix - either a perl script or SNMPTT.
The workflow of receiving a trap:
Configuring the following fields in the frontend is specific for this item type:
In Configuration → Hosts, in the Host interface field set an SNMP interface with the correct IP or DNS address. The address from each received trap is compared to the IP and DNS addresses of all SNMP interfaces to find the corresponding hosts.
In the Key field use one of the SNMP trap keys:
Key | ||
---|---|---|
Description | Return value | Comments |
snmptrap[regexp] | ||
Catches all SNMP traps that match the regular expression specified in regexp. If regexp is unspecified, catches any trap. | SNMP trap | This item can be set only for SNMP interfaces. This item is supported since Zabbix 2.0.0. Note: Starting with Zabbix 2.0.5, user macros and global regular expressions are supported in the parameter of this item key. |
snmptrap.fallback | ||
Catches all SNMP traps that were not caught by any of the snmptrap[] items for that interface. | SNMP trap | This item can be set only for SNMP interfaces. This item is supported since Zabbix 2.0.0. |
Multiline regexp matching is not supported at this time.
Set the Type of information to be 'Log' for the timestamps to be parsed. Note that other formats such as 'Numeric' are also acceptable but might require a custom trap handler.
For SNMP trap monitoring to work, it must first be correctly set up.
To read the traps, Zabbix server or proxy must be configured to start the SNMP trapper process and point to the trap file that is being written by SNMPTT or a perl trap receiver. To do that, edit the configuration file (zabbix_server.conf or zabbix_proxy.conf):
If systemd parameter PrivateTmp is used, this file is unlikely to work in /tmp.
At first, snmptrapd should be configured to use SNMPTT.
For the best performance, SNMPTT should be configured as a daemon using snmptthandler-embedded to pass the traps to it. See instructions for configuring SNMPTT in its homepage:
http://snmptt.sourceforge.net/docs/snmptt.shtml
When SNMPTT is configured to receive the traps, configure snmptt.ini
:
The "net-snmp-perl" package has been removed in RHEL/CentOS 8.0-8.2; re-added in RHEL 8.3. For more information, see the known issues.
Now format the traps for Zabbix to recognize them (edit snmptt.conf):
EVENT coldStart .1.3.6.1.6.3.1.1.5.1 "Status Events" Normal
FORMAT ZBXTRAP $aA Device reinitialized (coldStart)
Do not use unknown traps - Zabbix will not be able to recognize them. Unknown traps can be handled by defining a general event in snmptt.conf:
Requirements: Perl, Net-SNMP compiled with --enable-embedded-perl (done by default since Net-SNMP 5.4)
Perl trap receiver (look for misc/snmptrap/zabbix_trap_receiver.pl) can be used to pass traps to Zabbix server directly from snmptrapd. To configure it:
If script name is not quoted, snmptrapd will refuse to start up with messages, similar to these:
net-snmp agent does not support AES256 with SNMPv3/USM.
All customized perl trap receivers and SNMPTT trap configuration must format the trap in the following way:
where
Note that "ZBXTRAP" and "[address]" will be cut out from the message during processing. If the trap is formatted otherwise, Zabbix might parse the traps unexpectedly.
Example trap:
11:30:15 2011/07/27 .1.3.6.1.6.3.1.1.5.3 Normal "Status Events" localhost - ZBXTRAP 192.168.1.1 Link down on interface 2. Admin state: 1. Operational state: 2
This will result in the following trap for SNMP interface with IP=192.168.1.1:
11:30:15 2011/07/27 .1.3.6.1.6.3.1.1.5.3 Normal "Status Events"
localhost - Link down on interface 2. Admin state: 1.
Zabbix has "Large file support" for SNMP trapper files. The maximum file size that Zabbix can read is 2^63 (8 EiB). Note that the filesystem may impose a lower limit on the file size.
Zabbix does not provide any log rotation system - that should be handled by the user. The log rotation should first rename the old file and only later delete it so that no traps are lost:
Because of the trap file implementation, Zabbix needs the file system to support inodes to differentiate files (the information is acquired by a stat() call).
This example uses snmptrapd + SNMPTT to pass traps to Zabbix server. Setup:
configure output file and time format:
Create an SNMP item TEST:
Host's SNMP interface IP: 127.0.0.1
Key: snmptrap["General"]
Log time format: hh:mm:ss yyyy/MM/dd
This results in:
snmptrap -v 1 -c public 127.0.0.1 '.1.3.6.1.6.3.1.1.5.3' '0.0.0.0' 6 33 '55' .1.3.6.1.6.3.1.1.5.3 s "teststring000"
15:48:18 2011/07/26 .1.3.6.1.6.3.1.1.5.3.0.33 Normal "General event"
localhost - ZBXTRAP 127.0.0.1 127.0.0.1
This simple example uses SNMPTT as traphandle. For better performance on production systems, use embedded Perl to pass traps from snmptrapd to SNMPTT or directly to Zabbix.