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 from a corresponding address that match the regular expression specified in regexp | 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 from a corresponding address 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. |
Multi-line 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 to log the traps:
Now format the traps for Zabbix to recognise them (edit snmptt.conf):
Do not use unknown traps - Zabbix will not be able to recognise them. Unknown traps can be handled by defining a general event in snmptt.conf:
EVENT general .* "General event" Normal
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:
All customised perl trap receivers and SNMPTT trap configuration must format the trap in the following way: [timestamp] [the trap, part 1] ZBXTRAP [address] [the trap, part 2], 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 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:
The maximum log file size supported by Zabbix is 2 gigabytes. The log file must be rotated before reaching this limit.
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:
This results in:
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.