Now that we know about some of the automation features, let's take a look at a feature in Zabbix that allows us to define regular expressions in an easier – and sometimes more powerful – way. This feature can be used in low-level discovery, as discussed here, and in other locations.

There are quite a lot of places in Zabbix where regular expressions can be used. We already looked at icon mapping in Chapter 21, Visualizing Data with Graphs and Maps, and log filtering in Chapter 10, Advanced Item Monitoring. In all these places, we defined the regular expression directly. But sometimes, we might want to have a single expression that we could reuse, or the expression could be overly complicated when typed in directly. For example, our filtering of loopback interfaces earlier was not the most readable thing. This is where global regular expressions can help.

Let's see how we could have used this feature to simplify that filtering:

Navigate to Administration | General, choose Regular expressions from the drop-down, and click on New regular expression. To see what we could potentially do here, expand the Expression type drop-down:

Character string included and Character string not included both seem pretty straightforward. This expression would match or negate the matching of a single string. Any character string included is a bit more complicated, according to the Delimiter drop-down (which appears when we choose Any character string). We could enter multiple values and, if any of those were found, it would be a match:

For example, leaving the Delimiter drop-down at the default setting, retaining the comma, and entering ERROR, WARNING in the Expression field, would match either the ERROR or WARNING string.

The two remaining options, Result is TRUE and Result is FALSE, are the powerful ones. Here, we could enter ^[0-9] in the Expression field and match when the string either starts or does not start with a number. Actually, only these last two work with regular expressions; the first three are string-matching options. They do not even offer any extra functionality besides making things a bit simpler; technically, they are not regular expressions, but are supported here for convenience.

Previously, when we wanted to filter out an interface with the name lo, we used a filter that referenced us to the following regular expression rule—Network interfaces for discovery.

Creating something familiar is fairly complicated. Let's create a global regular expression that would do the same:

1. Enter Name as Exclude loopback.
2. In the Expressions block, fill in the following:

• • Expression type: Result is FALSE
  • Expression: ^lo$

The fields can be seen in the following screenshot:

3. Click on the Add button at the very bottom.

Now, let's reference it in our global regular expression:

1. To do so, go to Configuration | Templates, click on Discovery next to C_Template_Linux, and click on Interface discovery in the Name column. Switch to the Filters tab and replace the value in the Regular expression column with @Exclude loopback.

2. When done, click on Update. The new configuration should work exactly the same. Another solution could be to just write the regular expression itself in this box.

Another place where global regular expressions come in handy is log monitoring. Similar to LLD rule filters, we just use an @ prefixed expression name instead of typing the regular expression directly. For example, we could define a regular expression as follows:

(ERROR|WARNING) 13[0-9]{3} 

It would catch any errors and warnings with the error code in the 13,000 range—because that might be defined to be of concern to us. Assuming we named our global regexp errors and warnings 13k, the log monitoring key would look like this:

log[/path/to/the/file,@errors and warnings 13k]