Forcing a network discovery run

Zabbix network discovery is a way to scan a network range and automatically start monitoring the discovered devices and services. Network discovery can look for basic services like HTTP, IMAP or SMTP. It can also scan the specified network range for SNMP, Zabbix agent or ICMP ping responses.

Zabbix network discovery is not to be confused with the space shuttle

Constant network scanning is not desirable, thus the discovery is usually set to run not too frequently – once every few hours to once every few days. If you have added a new Zabbix action for network discovery that links a fresh template, there is no way to see when will the discovery rule run next time, and no way to force it to run sooner.

Or is there?

Finding out discovery rule status

Let’s look at the Zabbix database for more information on the network discovery rule status. Discovery rules are stored in the drules table:

mysql> select * from drules;
| druleid | proxy_hostid | name    | iprange        | delay | nextcheck  | status |
|      22 |         NULL | Drule 1 | | 14400 | 1517289376 |      0 |
|      23 |         NULL | Drule 2 |  | 14400 | 1517289383 |      0 |
|      24 |         NULL | Drule 3 | | 14400 | 1517289339 |      0 |

Here we have the discovery rule ID, proxy (NULL meaning that these all are handled by the server), name and IP range. In the status column, 0 means enabled.

The two numbers, delay and nextcheck, are more interesting to us right now. Delay is the interval between two runs of discovery, in seconds. 14400/3600=4 – so these rules are run 4 hours apart.

Zabbix 3.4 added support for time suffixes for the interval/delay field, thus you might also see values like 4h.

The nextcheck is Unix timestamp – seconds since 00:00:00 on January 1st, 1970 (UTC). This tells us when the rule will be run next. That number is not very readable, though. There are many ways we could convert it to a more readable number, for example, using the date utility with the nextcheck value for the first rule:

> date -d@1517289376
O  jan 30 07:16:16 EET 2018

The -d parameter specifies date and time to use instead of the current time, and the @ syntax supplies Unix timestamp.

And if we check the current time:

> date
O  jan 30 03:44:11 EET 2018

If we would add a new discovery action now, it would take a long time, more than 3 hours, until we’d see whether it works as expected. What about the other two rules? We could tell the database to give us more readable values right away. For example, with MySQL:

mysql> select name,from_unixtime(nextcheck) from drules;
| name    | from_unixtime(nextcheck) |
| Drule 1 | 2018-01-29 23:16:16      |
| Drule 2 | 2018-01-29 23:16:23      |
| Drule 3 | 2018-01-29 23:15:39      |
3 rows in set (0.02 sec)

Huh, what happened there, why are the times completely different? I used date utility on my local workstation, but the server is in a different timezone. Let’s check the current time on the server:

> date
P  jan 29 19:49:34 CST 2018

We can see that my workstation time is 8 hours ahead of the server time, and that we should always be careful with dates and times if the timezone is not specified. Getting back to the times, all 3 rules will be executed more than 3 hours from now.

Forcing a rule to run sooner

To force Zabbix server to start working on them sooner, we can choose a value a few minutes in the future:

> date -d "2018-01-30 04:20:00" "+%s"

Here we use “normal” format for the -d option, and the %s format specifier instructs date to return Unix timestamp. We can now plug it in an SQL update statement:

mysql> update drules set nextcheck=1517278800 where druleid=22;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

The time was some 2-3 minutes in the future, giving us a chance to make the database update before that timestamp was in the past. Setting it to a value in the past might make Zabbix server execute the rule right away, but that behaviour is not documented, thus we should not rely on it. Additionally, in this case we needed a relative time, thus it did not matter in which timezone we determined the value. If we wanted to set this rule to run at an absolute time in some point in the future, we would have to be extra careful about timezones – or just use the server timezone everywhere.

In earlier versions of Zabbix, items could also be forced to be polled this way. Zabbix 1.8 removed the nextcheck field from the items table – covered as “Added configuration data cache module” in the 1.8 What’s new page.

Database was able to tell us what’s the human-readable value for nextcheck. It can also help to set nextcheck to some time in the future more easily:

mysql> update drules set nextcheck=unix_timestamp(now())+30 where druleid=22;

The now() function returns the current time which is converted to the Unix timestamp format with the unix_timestamp function, and then 30 seconds are added to it. Here we can more safely use a smaller number – 30 seconds instead of several minutes – as the change will be nearly instant.

Now the changed rule will be run by server in a few seconds or minutes instead of several hours, and we will be able to see the results from our new or changed discovery action much sooner.

Leave a Reply