Creating items for all discovered entities is useful, but even looking through them would be quite a task. Luckily, LLD allows us to create triggers automatically as well. The same as with items, this is done by creating prototypes first; actual triggers will be created by the discovery process later.
To create the prototypes, follow these steps:
- Navigate to Configuration | Templates, click on Discovery next to C_Template_Linux, and then click on Trigger prototypes. In the upper-right corner, click on Create trigger prototype, and configure it as follows:
-
- Name: Incoming traffic too high for {#IFNAME} on {HOST.NAME}.
- Expression: Click on Add next to this field. In the popup, click on Select prototype, and then click on Incoming traffic on {#IFNAME} in the Name column. Click on Insert and modify the generated expression. Change =0 to >5K. This will alert you whenever the incoming traffic exceeds 5,000 bytes per second, as the item is collecting in bytes per second.
- Severity: Select Warning.
The fields can be seen in the following screenshot:
- When done, click on the Add button at the bottom.
That was for incoming traffic; now, let's create a prototype for outgoing traffic. Click on the name of the prototype we just created, and then click on Clone. In the new form, change Incoming in the Name field to Outgoing and net.if.in in the Expression field to net.if.out, and then click on the Add button at the bottom.
With both prototypes in place, let's go to Configuration | Hosts and click on Triggers next to A test host. It is likely that there are several new triggers here already. For the incoming traffic, we created that prototype first, so discovery might have had a chance to process it already. Nevertheless, it should not take longer than a few minutes for all of the LLD-created triggers to show up. Make sure to refresh the page manually to see any changes—configuration pages do not get automatically refreshed like monitoring ones do:
In the same way as with items, triggers are prefixed with the LLD rule name. Notice how we got one trigger from each prototype for each interface, the same as with the items. The {#IFNAME} LLD macro was replaced by the interface name as well. Note that we did not have to worry about making the created triggers unique—we must reference an item key in a trigger, and that already includes the appropriate LLD macros in item key parameters.
The threshold we chose here is very low—it is likely to fire even on our small test systems. What if we had various systems and we wanted to have a different threshold on each of them? The concept we discussed earlier, user macros, would help here. Instead of a hardcoded value, we would use a user macro in the trigger expression and override it on specific hosts as required. We discussed user macros in Chapter 8, Simplifying Complex Configurations with Templates.