The method covered earlier, the embedded Perl receiver, is easy to set up and performs well. If it is not possible to use it for some reason or some advanced filtering is required, a custom script could push trap values to items. This subsection will use an example script shipped with Zabbix to demonstrate such a solution.

We'll place the example SNMP trap-parsing script in the Zabbix user's home directory:

# cp misc/snmptrap/snmptrap.sh /home/zabbix/bin  

Let's take a look at that script now. Open the file we just copied to /home/zabbix/bin/snmptrap.sh. As you can see, this is a very simplistic script, which gets passed trap information and then sends it to the Zabbix server, using both host snmptrap and key snmptrap instances. If you are reading carefully enough, you've probably already noticed one problem—we didn't install any software as ~zabbix/bin/zabbix_sender, so that's probably wrong.

First, let's find out where zabbix_sender is actually located:

$ whereis zabbix_sender
zabbix_sender: /usr/local/bin/zabbix_sender

On this system, it's /usr/local/bin/zabbix_sender. It might be a good idea to look at its syntax by running this:

$ zabbix_sender --help  

This allows you to send a value to the Zabbix server, specifying the server with the -z flag, port with -p, and so on. Now let's return to the script. With our new knowledge, let's look at the last line—the one that invokes zabbix_sender. The script seems to pass values retrieved from the SNMP trap as parameters to zabbix_sender; hence, we can't make any decisions and information transformation between snmptrapd and Zabbix. Now, let's fix the problem we noticed:

• Change ZABBIX_SENDER to read /usr/local/bin/zabbix_sender (or another path if that's different for you)
• Additionally, change the last line to read $ZABBIX_SENDER -z $ZABBIX_SERVER -p $ZABBIX_PORT -s "$HOST" -k "$KEY" -o "$str"—this way, we are also quoting host and key names, just in case they might include spaces or other characters that might break command execution

Save the file. Let's prepare the Zabbix side now for trap receiving. On the frontend, do the following:

1. Navigate to Configuration | Hosts and click on Create host. Fill in the following values:

• •  Name: snmptraps
  • Groups: Click on SNMP devices in the Other groups box, then click on the button; if there are any other groups in the Groups listbox, remove them

2. Click on the Add button at the bottom.

Notice that the hostname used here, snmptraps, must be the same as the one we configured in the snmptrap.sh script; otherwise, the traps won't be received in Zabbix.

Now, click on Items next to the snmptraps host, and then click on Create item. Enter these values:

• Name: Received SNMP traps
• Type: Zabbix trapper
• Key: snmptraps
• Type of information: Character

When you are done, click on the Add button at the bottom. Again, notice how we used the exact same key spelling as in the snmptrap.sh script.

We're done with configuring Zabbix for SNMP trap receiving, but how will the traps get to the script we edited and, in turn, to Zabbix? The same as before, this is where snmptrapd steps in.

Let's create a simplistic configuration that will pass all the received traps to our script. To do this, we will edit snmptrapd.conf. If you created it earlier, edit it (you may comment out the lines we added previously); if it's missing, create the file. Edit it as root and make it look as follows:

authCommunity execute public 
#perl do "/home/zabbix/bin/zabbix_trap_receiver.pl"; 
traphandle default /bin/bash /home/zabbix/bin/snmptrap.sh 

We commented out the Perl receiver line and added a line to call our new script. The default keyword will make sure that all received traps go to this script (that is, unless we have other traphandle statements with OIDs specified, in which case only those received traps will get to this script that don't match any other traphandle statement). Save this file, and then start or restart the snmptrapd daemon as appropriate for your distribution.

Now, we should be able to receive SNMP traps through all the chain links. Let's test that by sending a trap same the way as before from the Zabbix server:

$ snmptrap -Ci -v 2c -c public localhost "" "NET-SNMP-MIB::netSnmpExperimental" NET-SNMP-MIB::netSnmpExperimental s "test" 

Once the command completes successfully, check the frontend for the results. Go to Monitoring | Latest data and select SNMP devices in the filter:

Great, data from our test trap has been received here. It's trimmed in the table view, though, so click on History to view all of it:

Excellent, we can see our trap in its entirety. Notice how with this custom script we decided to parse out only the specific string, instead of pushing all the details about the trap to Zabbix. Let's check what it looks like with several traps received one after another. From the console again, execute the following:

$ snmptrap -Ci -v 2c -c public localhost "" "NET-SNMP-MIB::netSnmpExperimental" NET-SNMP-MIB::netSnmpExperimental s "another test"  

Refresh the History screen we had open in the browser and check whether the result is satisfactory:

Our latest trap is nicely listed, with entries being ordered in descending order.

But wait, everything after the first space is missing from the informative text. That's not desirable, so let's try to fix this problem. As root, open the /home/zabbix/bin/snmptrap.sh file and look for the line that strips out addresses from received information:

oid=`echo $oid|cut -f2 -d' '` 
address=`echo $address|cut -f2 -d' '` 
community=`echo $community|cut -f2 -d' '` 
enterprise=`echo $enterprise|cut -f2 -d' '` 

As seen here, when using a space as the separator, only the second field is grabbed. We want the full details captured instead as, otherwise, a very important failure would simply show up as A for us. Let's add a dash to the field parameter so that all trailing fields are captured as well:

address=`echo $address|cut -f2- -d' '` 

This should solve the problem, so let's test it again:

$ snmptrap -Ci -v 2c -c public localhost "" "NET-SNMP-MIB::netSnmpExperimental" NET-SNMP-MIB::netSnmpExperimental s "A Very Important Failure"  

Return to the frontend and refresh the history listing:

Finally! The data from our important traps will no longer be lost.