Internal events and unknown triggers

Alerting on unsupported items, which we covered a moment ago, is likely the best approach, as it allows us to have a small number of triggers and a relatively easy way to split up alerting about them. There's another built-in approach that allows us to alert about unsupported items and triggers in an unknown state; Zabbix has the concept of internal events.

To configure an alert based on those internal events, follow these steps:

Go to Configuration | Actions, choose Internal in the Event source drop-down menu and click on Create action. In the Action tab, enter these values:

Name: A trigger changed state to unknown
In the New condition block, select Event type in the first drop-down menu, and choose Trigger in "unknown" state in the last drop-down menu, and press Add (below the condition not the one at the bottom):

Switch to the Operations tab and enter the following values:

Default subject: {TRIGGER.STATE}: {TRIGGER.NAME}
Click on New in the Operations block, and then click on Add in the Send to Users section.

We set up email for monitoring_user in Chapter 2, Getting Your First Notification—if another user has email properly set up in your Zabbix instance, choose that user instead.

Click on monitoring_user in the popup, and then click on the small Add link in the Operation details block—the last one, just above the buttons at the very bottom. Be careful; this form is very confusing.

Switch to the Recovery operations tab and enter the following.

Recovery subject: {TRIGGER.STATE}: {TRIGGER.NAME}
Click on New in the Operations block, and then click on Add in the Send to Users section and, just like in the Operations tab, select the monitoring_user.

When done, click on the Add button at the bottom.

We discussed actions in more detail in Chapter 7, Acting upon Monitored Conditions.

Now, whenever a trigger becomes unknown, an alert will be sent.

While we can limit these actions by application, host, template, or host group, we cannot react to internal events in the same actions we use for trigger events. If we already have a lot of actions carefully splitting up notification per host groups, applications, and other conditions, we would have to replicate all of them for internal events to get the same granularity. That's highly impractical so, at this time, it might be best to have a few generic actions, such as ones that inform key responsible persons, who would investigate and pass the issue to the team assigned to that host group, application, or other unit.

If you looked carefully, then you noticed that Zabbix already provided three internal operations: one for items in a not supported state, another one for low-level discovery rules in a not supported stated, and one for triggers in an unknown state. They're all disabled and will inform the Zabbix administrators once they're enabled. My advice is to enable them and to tune them to you needs.

A list of the build in actions already provided in Zabbix:

Table of Contents for Internal events and unknown triggers

Create new playlist

Sign In

Sign Up

Table of Contents for
Internal events and unknown triggers