Zabbix 2.2 features, part 2 – Templated web monitoring

Continuing with the series on upcoming Zabbix 2.2, the second feature we will look at will be related to the built-in web monitoring that has been available in Zabbix for quite some time already. One problem some users faced – there was no way to use the extensive Zabbix templating system for web monitoring. This was not an issue if all we wanted to monitor were standard websites, but as soon as there would be a large amount of identical webservers, one would have to either do a lot of manual configuration or some scripting via the Zabbix API. Zabbix 2.2 will greatly simplify this by providing templatable web monitoring.

Articles in 2.2 feature series:

Web scenario as a host and template object

Previously, web scenarios weren’t really associated with hosts or templates that much. While technically they were tied to a specific host, they mostly operated as separate entities, host linkage seemingly being arbitrary. Now a web scenario is quite explicitly shown by the frontend as belonging to a specific host – but what is even more important, they can be defined on a template level and all hosts linked to that template would gain the same web scenario. As the URL that should be checked is defined inside web scenario steps, it wouldn’t be too useful as-is – all those hosts would only result in the same website being checked. To provide an easy way to customise checked URLs the following macros (variables) are supported in the step URL:

  • {HOST.CONN}
  • {HOST.DNS}
  • {HOST.HOST}
  • {HOST.IP}
  • {HOST.NAME}
  • user macros

For example, adding DNS to a host and making it monitored by DNS would allow to use an URL like this in the web scenario step:

http://{HOST.CONN}/web/service

Application linkage now optional

While adding this great feature it was also decided to make scenario linkage to applications optional – previously it was mandatory. Before Zabbix 2.2, the application field in web scenario properties was a freeform field where application name could be entered. If an application by that name existed, it was used. If not, a new application was created and scenario linked to it. Of course, making a simple typo in an application name would create a new application… This has been changed now to an approach more similar to how applications are configured in item properties – there is a New application field, and entering anything here would create the application and link the scenario to it. Application choice is a dropdown (what is different from the item’s multi-select – web scenario may be associated only with one application) where an empty value is valid as well.

User interface changes

The functional changes also required some user interface changes in addition to the changed application area in the scenario properties.

Changed configuration layout

Illustrating the “disconnectedness” of web scenarios from hosts, web scenario configuration previously was done in a separate section, Configuration -> Web. With web scenarios becoming more of a host property similar to an item, this section was removed and web scenario entry added in the host (and template) configuration lists. For example, in the host list there would an extra column labeled Web.

Web scenarios may be both directly attached to hosts and templates, or they may be templated – and this is identified in the scenario list the same way as it is done for other entity types (items, triggers etc) – by prefixing scenario name with the originating template name in grey:

Web scenarios available from global search results

Another change that was not done right away (to be honest, we just forgot to include it in the specification :) ) – web scenarios were not available in global search results. After a brief period of testing this omission was obvious, and links to web monitoring were added as follows:

  • To configuration section for templates
  • To monitoring and configuration sections for hosts

For example, search results could look like this:

Further reading

Of course, that’s not all – there are more details on how this operates. For example, which fields can be overridden in downstream hosts and templates, more macros supported (including user macros in username and password fields) and what other features are not available yet (these include no cloning of web scenarios and no XML import/export of them). For all of that and more see the original specification.

Special thanks

Special thanks for help and support with this feature goes to Mirth Corporation for financing the development.

This entry was posted in Technical and tagged , . Bookmark the permalink.

Comments are closed.