Zabbix 2.2 features, part 4 – HTTP proxy for web monitoring

Having explored two other improvements to the built-in web monitoring – ability to template it and change retry count – let’s take a look at another one. Until Zabbix 2.2, it was not possible to set HTTP proxy for web monitoring… well, that’s not entirely true – with a hack one could set HTTP proxy for the whole Zabbix server (or, since Zabbix 2.0, Zabbix proxy), but there was no way to set it per web scenario. Zabbix 2.2 will provide such a feature.

Articles in 2.2 feature series:

HTTP proxies are fairly popular in larger organisations for accountability, access control and also performance reasons (their ability to cache content in some cases can reduce external traffic significantly). Squid is probably the most popular solution, but there are other proxies available as well.

Hacking HTTP proxy until now

Until now, there was no officially supported way to use HTTP proxy, although one method existed. As Zabbix uses libcurl for web monitoring support, it was possible to export environment variables, which would then be used by the web monitoring – just a side effect of curl supporting such a functionality.

For example, if you would like to use HTTP proxy in some Zabbix version before 2.2, you could export environment variable http_proxy for the corresponding daemon (server or proxy):

http_proxy=http://host_name:3278 zabbix_server

This would make libcurl pick it up and use for all web scenarios – one could not disable it on a specific scenario.

It was also possible to specify HTTPS proxy in the same way:

https_proxy=http://host_name:3128 zabbix_server

By the way, this one could also be specified in uppercase, which was not possible with http_proxy – to cite curl manpage:

The environment variables can be specified in lower case or upper case. The lower case version has precedence. http_proxy is an exception as it is only available in lower case.

The new way – per scenario

Zabbix 2.2 will allow to specify HTTP (or HTTPS) proxy per scenario. The proxy is specified in the web scenario using the very same syntax as environment variables:

http://proxy:port

Or, in the case of HTTPS:

https://proxy:port

Of course, to help you, a hint text is available in that field. This field is available in the scenario properties just below the Agent field:

This has the obvious benefit of checking internal sites without using the proxy and external sites by using it – but in some environments a web page might be available both through a proxy and without using it. That could be tested now in both ways.

User macros (variables) are also supported in this field. That makes it much easier to use with another new feature in 2.2, the ability to template web monitoring scenarios – for example, one could define a user macro ${HTTP_PROXY}, containing string http://internalproxy:3128 . All hosts/web scenarios would use this proxy, but then, for a specific host, it could be changed to http://externalproxy:3128 .

Make sure to test the development versions and report whether you could use this new feature successfully.

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

Comments are closed.