Looking at the items, triggers, and graphs that were created, besides real interfaces, the loopback interface also got discovered, and all of those entities got created for it. In some cases, it would be useful to monitor that interface as well, but for most systems, such data would not be useful.

If we look at the list of items in the configuration, the LLD-generated items had the checkbox next to them disabled. This is no longer the case, and we can now delete the discovered items. The controls in the STATUS column allow us to enable or disable them individually. LLD-generated items on a host cannot be edited, except for being disabled or enabled. Note that in the frontend, this can be done by selecting a list of items all at once, something that was not possible with the older 3.0 version.

Disabling an LLD-generated item on many hosts could be a massive manual task. We could think about disabling the prototype, but that would not work for two reasons:

• Firstly, we only want to disable items for the loopback interface, but the same prototype is used for items on all interfaces.
• Secondly, state changes in the prototype are not propagated to the generated items. The initial state in which these items are created – enabled or disabled – will be kept for them.

What about other changes to these items, such as changing the item key or some other property? Those would get propagated downstream, but only when the discovery itself was run by the Zabbix server, and not when we made the changes to the prototype in the frontend. In practice, this means that we would have to wait for up to the LLD rule interval to see these changes applied downstream.

Luckily, there's a way to easily avoid creating items for some of the discovered entities, such as in our case, not creating items for the loopback interface. This is possible by filtering the entities LLD returns on the LLD rule level. Let's change our existing rule to ignore interfaces with the name lo.

Navigate to Configuration | Templates and click on Discovery next to C_Template_Linux. Then, click on Interface discovery in the Name column. Notice how there's another tab here—Filters. Switch to that tab, and in the first and only Filters entry, fill in the following:

• Macro: {#IFNAME}, and select matches in the drop-down
• Regular expression: @Network interfaces for discovery

These fields can be seen in the following screenshot:

When done, click on Update. LLD filters work by only returning matching entries. In this case, we wanted to exclude the entry lo and keep everything else. The filter we used will exclude lo but match everything else—including eth0, enp0s3, and loop.

The regular expression here is a reference to the Network interfaces for discovery regular expression that is available as standard in Zabbix under the Administration | General | Regular expression menu:

To see whether this worked, navigate to Configuration | Hosts and click on Items next to A test host. In the list, notice how both lo interface items have an orange icon with an exclamation mark in the Info column. If you move the mouse cursor over it, a message explains that this item is no longer classed as discovered and will be deleted at a later date:

In this case, the item is not discovered because it got excluded by the filter, but the reason does not matter that much; it could be an interface being removed or having its name changed as well. But why will it be removed after that specific amount of time, a bit more than 29 days? If we look at the properties of our LLD rule again, there's a field called Keep lost resources period:

Here, we may specify how long items will be kept for when they are not discovered again, and the default is 30 days. The tooltip helpfully told us how much time we have left before the item will be deleted and at what precise time it will be deleted. Other entities, including triggers and custom graphs, are kept as long as the underlying items are kept.

Now, navigate to Monitoring | Latest data and click on Graph for Incoming traffic on lo. Let some time pass. You will notice that items that are scheduled for deletion still continue collecting data. This might have been undesirable when we had initially been monitoring a lot of things on a device, overloaded it, and then applied filtering, hoping to remedy the situation. There is no way to directly control this, but we may temporarily set the resource—keeping to 0, which would remove the items that are no longer discovered the next time the LLD rule runs. In the LLD rule properties, set the value of this field to 0 and click on Update. After a couple of minutes, check the item list for A test host in the configuration—both of the automatic lo interface items should now be gone.

What if we would like to have a different set of items for different discovered entities, for example, monitoring more things on interfaces with a specific name? That is not easily possible, unfortunately. One way would be by creating two different LLD rules with different item prototypes, and then filtering for one set of entities in one LLD rule, and another set in the other LLD rule. Still, that is more complicated than you might expect. LLD rules have the same uniqueness criteria as items—the key. With some items, we can use a little trick and have one item with a key called key and another with key[]. Specifying empty square brackets will denote empty parameters, but from a functional perspective, the item will be exactly the same. Unfortunately, the agent LLD keys do not accept parameters, so this trick won't work. One workaround would be specifying an alias on an item key—we will discuss how that can be done in Chapter 20, Zabbix Maintenance.