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.

Our Server server.example.com has 3 webservices running. If we just configure the simple http check we get a single http column with all the http-checks on it. The hosts.cfg entry in that case would be:

1.2.3.4 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 http status.

We have two possibilities to break up this http–“multi status” into separate statuses:

  1. create “service-host entries”

  2. use the httpstatus-check

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:

1.2.3.4 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 conn-check.

  • 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 noconn tag 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 the httpstatus-check

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 hosts.cfg(5)

httpstatus[=COLUMN];URL;okstatusexpr;notokstatusexpr

The example from above would then transform to (using the same bad service names)

1.2.3.4 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; http80, http81, webapp and 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 http-check.

The trend graphs for all three checks are also shown on the http-column (and 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 SERVICE=http80|http81|webapp).

Conclusion

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 connection problems.

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”.


  1. 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.

  2. 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.