Keep Your Software’s Up to Date with Zabbix

Monitoring tools are increasingly going beyond their usual perimeter of just monitoring metrics. Modern tools, like Zabbix, can watch files for any change and raise warning whenever it occurs. An example I found the “Linux by Zabbix agent” template: Computing the /etc/passwd checksum and raise an alert if it changes.

In this blog post, I will explain how to get information about the latest WildFly version available and raise a trigger (ie. alert in Zabbix language) whenever a new version is available and does not match the installed version.

Getting Latest Version

I will create a item of type HTTP agent to get this information from WildFly website (https://www.wildfly.org/downloads/). I don’t want this HTTP GET to run for each WildFly server as it will add unnecessary calls to their website. So, the item must be associated to the host which is unique in my Zabbix system: The Zabbix server.

In Zabbix Front End, on the Zabbix server, I create a new item with the following setting:

I chose to name it “wildfly.version.latest”.

As is, this item will store the whole HTML result of the page which I am obviously not interested in. So, I need to add preprocessing steps to extract the version:

I looked inside the page code and came to the regular expression on the screenshot. “\1” will be the first match. The second preprocessing step is to avoid storing the result every time. There is no need to store it if the version does not change.

A quick check on latest data shows that it works perfectly:

Creating a Trigger

I had to do several try-and-fail because it is not possible to share data between two different templates. It can raise this kind of error:

Trigger “Not latest software installed” belongs to templates with different linkages.

That’s why I associated “wildfly.version.latest” item directly to the Zabbix server. Now, how to compare it with installed WildFly version? First, I need to make the data available from the WildFly template. To do so, I simply create a calculated item which looks like this:

The simplest trigger will be to compare the version from the download URL and the installed URL with formula:

last(/WildFly Server by JMX/wildfly.version.latest)<>last(/WildFly Server by JMX/jmx["jboss.as:management-root=server","productVersion"])

To decompose this formula:

• last is a trigger function that return the most recent value of what is passed as parameter
• /WildFly Server by JMX/wildfly.version.latest
  • First string between two slash is the template name
  • After slash is the item key

Next, we have “<>” to compare with the second half of expression.

As template is already applied, problem should arise almost immediately after trigger creation.

Now, you are aware that a new release is available, and you can update it.

As “OK event generation” is set to expression, problem will automatically close whenever WildFly will be updated to the latest release available on download site.

Next Steps

As Zabbix supports Event-Driven Ansible, it should not be too difficult to call a Wildfly upgrade playbook directly from Zabbix server without any human intervention (if this is really you want to do :)).

A possible improvement could be to only get an alert whenever a new final version is released and not a beta release.