Our previous action, which we created in Chapter 2, Getting Your First Notification, matched any event, as we had not limited its scope in any way. Now, we will try matching only a specific condition:

1. Navigate to Configuration | Actions, select Triggers as the event source, and then click on Create action.

2. In the Name field, enter SNMP action.
3. Now, look at the Conditions. By default, there were two conditions that were already added in earlier versions. In Zabbix 4, this is no longer the case, and Maintenance status has been renamed to Problem is suppressed, while the option Trigger value has made way for Trigger severity. A few new conditions have been added so that we can react based on our tags.

4. For now, let's add Problem is not suppressed and Trigger severity is greater than or equals Not classified:

For our action right now, let's leave the default conditions in place and move to operations. Operations are the actual activities that are performed:

1. Switch to the Operations tab and click on the New link in the Action operations block. To start with, we will configure a very simple action—sending an email to a single user group. This form can be fairly confusing.

2. Click on Add in the Send to User groups section, and, in the window that appears, click on Our users. The result should look like this:

3. Continue from here and click on the main Add link in the Operation details block (just below the Conditions section).
4. Finally, click on the Add button at the bottom. As we want to properly test how emails are sent, we should now disable the action we added previously.
5. Mark the checkbox next to SNMP Action, click on the Disable button at the bottom, and then confirm disabling in the popup.

Now, we require triggers on our SNMP trap items.

Navigate to Configuration | Hosts, click on Triggers next to snmptraps, and click on Create trigger. Enter the following information:

• Name: SNMP trap has arrived on {HOST.NAME}
• Expression: {snmptraps:snmptraps.nodata(30)}=0
• Severity: Information

Such a trigger will fire whenever a trap arrives, and clear itself approximately 30 seconds later. We discussed the nodata() trigger function in Chapter 6, Detecting Problems with Triggers. When done, click on the Add button at the bottom.

We will also want to have a trigger fire on Another host:

1. Let's copy the one we just created. Mark the checkbox next to it and click on Copy.
2. Choose Hosts in the Target type drop-down, Linux servers in the Group drop-down, and then select Another host:

When done, click on Copy.

One link is still missing—none of the two users in the Our users group has user media defined. To add media, navigate to Administration | Users, and click on monitoring_user in the Alias column. Switch to the Media tab and click Add, enter the email address in the Send to field, and then close the popup by clicking on Add. We now have to save this change as well, so click on Update.

Now, we have to make a trigger fire. Execute the following from Another host:

$ snmptrap -Ci -v 2c -c public <Zabbix server> "" "NET-SNMP-MIB::netSnmpExperimental" NET-SNMP-MIB::netSnmpExperimental s "Critical Error" 

Replace <Zabbix server> with the IP or DNS name of the Zabbix server. This value should end up in the snmptraps item in Another host and make the associated trigger fire. You can verify that the trigger fires in the Monitoring | Triggers section:

Then, send another trap from Another host:

$ snmptrap -Ci -v 2c -c public <Zabbix server> "" "NET-SNMP-MIB::netSnmpExperimental" NET-SNMP-MIB::netSnmpExperimental s "Critical Error"

As Another host no longer has any snmptraps item, this value should go to the snmptraps host instead. By now, we should have received an email from our new action. Let's check out another view—the event view. Open Monitoring | Events and, take a look at the final few entries:

We can see that three events have been successfully registered by now; first, the SNMP trap item reporting an error on Another host, then resolving it, and, finally, the trigger on the snmptraps host has fired. But the last column, titled ACTIONS, is notably different. While the first PROBLEM event has some numbers listed, the most recent one has nothing. Here's why.

The snmptraps host was located in the important SNMP host group, and permissions on it for our user group were explicitly set to deny.

That allows us to overlap host group permissions with action conditions to create quite sophisticated notification scenarios.