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.
- 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.
A list of the build in actions already provided in Zabbix: