External monitoring is one of the key tasks of the operations department. System engineers have to be able to measure performance degradation in the live setup in order to inform the developers, who in turn have to seek for solutions for these problems. Without monitoring no measurement is possible. Without measurement no debugging will happen. Icinga provides a pretty simple kind of monitoring. You can check whether your service, which is in our case the Play application, responds to a simple request or has to be marked as down.
One of the tools used for such tasks is Icinga, which is used for monitoring of whole networks and service landscapes. Icinga is a fork of the common Nagios monitoring system. It has been forked due to problems in the open source development process.
The source code is available at examples/chapter7/ssl/example-app for the example application used and in examples/chapter7/icinga for the Icinga specific files.
You need an up and running instance of Icinga. No additional tools are needed, as Icinga is shipped with everything needed.
The example listed here checks the output of the / URI. It checks for the occurrence of the string Is secure: true or Is secure: false. The string is created in the template by printing out the ${request.secure} variable. Using this it is simple to create a HTTP as well as a HTTPS check. Therefore, you should make sure that your Play application is configured with SSL support as well.
Create a Play specific Icinga configuration in the objects/ directory. On Ubuntu Linux you could create the following file in /etc/icinga/objects/play_icinga.cfg:
define host {
use generic-host
host_name puck
address 192.168.0.2
}
define service {
use generic-service
host_name puck
service_description HTTP/9000
check_command check_http!-p 9000 -s "Is secure: false"
}
define service {
use generic-service
host_name puck
service_description HTTPS/9443
check_command check_http!-p 9443 -S -s "Is secure: true"
}As you can see, the configuration is pretty short. Basically, there are two service checks defined for the same target host, which has the name puck and is reachable at 192.168.0.2. The check_command parameter defines what kind of check to execute. The first check connects to http://192.168.0.2:9000/ and ensures the defined string, which marks the request as cleartext HTTP, occurs in the response. If this is not the case, the test will not succeed. The same happens to https://192.168.0.2:9443/, however the -S parameter tells Icinga to handle this as an SSL connection and the string searched in this case marks the request as secure.
As you can see, this check is pretty simple, you could possibly go further and check the response times to define a maximum allowed latency, before the service is marked as CRITICAL or WARN in the Icinga system. This helps you to keep track of service level agreements.
Icinga is far more complex and used for complete network monitoring, so you should read about it.
Icinga is a pretty feature complete solution. Check more and especially its documentation at http://www.icinga.org/.