Do you have servers that have multiple web services running? Or non-trivial web applications using a reverse proxy, a web server and application servers?
Wouldn’t it be great if we could configure individual alerts for each of these services and display their status individually on the Xymon web interface?
This article shows 2 different approaches to achieve exactly that.
server.example.com has 3 webservices running. If we just configure
http check we get a single
http column with all the http-checks
on it. The
hosts.cfg entry in that case would be:
188.8.131.52 server.example.com # http://server.example.com/ \ http://server.example.com:81/ \ http://server.example.com:81/webapp
If any one of these three services is not responding the (combined)
http status will turn red and we have to click it open to see which of the
three checks is failing. Individual alerts are not possible either in that
configuration: we can configure alerts only on that single
We have two possibilities to break up this
http–“multi status” into separate
create “service-host entries”
Both ways will allow alerting to be configured for each of the three web services separately. It depends on the individual monitoring requirements which one to use.
Using “service-host entries”
We create “service-host entries”: These are “fake” hostnames that have not necessarily a valid DNS entrie associated with them as in the example below. The only check configured for these service-hosts is one web service each:
184.108.40.206 server.example.com # <conn and ssh are check here -- this is the hardware, VM, ...> 0.0.0.0 server.example.com_http80 # noconn http://server.example.com/ 0.0.0.0 server.example.com_http81 # noconn http://server.example.com:81/ 0.0.0.0 server.example.com_webapp # noconn http://server.example.com:81/webapp
This results in 4 rows of hosts
the first one being the physical host or virtual machine that receives the data from the installed xymon-client and is the target for the
the other three only doing an
http-check. As we used a fake hostname here to indicated the service a
conn-check does not make sense (and would duplicate the check for the server anyway). Thus the
noconntag to supresses the ping probe.
The trend graphs for the checks are available on each column as usual. Alerting can be configured in the natural way, using the fake hostnames.
Using “service-host entries” is good for services that are relatively independent. But what if all three http services are required to make sure that the whole web app is running fine?
In that case breaking it up in multiple service-hosts is not very logical1. It would be better to have 3 check-columns for the server, leaving us with only one hosts but three more services (yes, “+3” as we will see below).
This can be done with the
httpstatus-check2, where we can configure an
optional column-name, from
The example from above would then transform to (using the same bad service names)
220.127.116.11 server.example.com # httpstatus=http80;http://server.example.com/;200 \ httpstatus=http81;http://server.example.com:81/;200 \ httpstatus=webapp;http://server.example.com:81/webapp;200
This would (http wise) result in a total of 4 columns;
http. The latter is automatically generated by Xymon. It
gathers/replicates/mirrors all the other checks resulting in that column
looking identical to our first version were we only used the plain
The trend graphs for all three checks are also shown on the
not on the other three).
As with the service-host entries above with this setup we
have a better overview on the web interface for the http checks.
can configure alerts for each http-check individually (by using
There are two ways to configure http monitoring to get finer control and better overview. It depends on the type of applications we are monitoring, organisational requirements and of course personal taste which one to use.
I tend to use the
httpstatus in cases where I have an application served via
different protocols (http and https) or with multi-homed hosts, e.g. public and
private IPs where I want to monitor both to quickly rule out external
On the other hand I use “service-host entries” for applications that are more
complex and where other application monitoring metrics come into play, e.g.
jmx-monitoring for the application server. In that case the “service-host” has
not only the single
http-column but also some additional ones.
The two methods can be combined even (and I do that in practice) to have individual statuses on the “service-hosts”.
We could use a
combo-check to re-combine the statuses but that would involve another configuration file — which makes the setup more prone to errors.↩
Only a simple use of
httpstatus, that resembles the basic http check, is used in our example. It is possible to have more sophisticated checks on the returned http statuscodes.↩