All of the clients use the same basic method to get data from Nagios: scrape the data from a web page. The biggest problem comes when that web page is not available – or is incorrect. Most of these applications request a URL, but sometimes are unclear as to what URL they want exactly. Add to that the fact that Nagios changed its URL structure slightly between versions and it gets even more complicated.
To discover what was happening, I used tcpdump to watch the accesses to the web server from the Nagios clients, as well as watching the Apache logs. By doing this, I was able to discern what URLs were being loaded.
Here are some of the URL paths being looked for by the various clients:
Further complicating matters in my case was the fact that any unrecognized URL was massaged (via mod_rewrite) into serving the main Nagios page via SSL.
However, by using mod_rewrite it was possible to rewrite the old /cgi-bin paths to a newer /cgi-bin/nagios3 path, and things started working.
In the case of the statuswml.cgi file, Google Chrome wanted to download the resulting file instead of actually using it somehow.
The main choices for Nagios clients on Android are these:
I have gone with aNag – it has a nice interface, good use of notification, and worked without trouble once the URL was fixed up. Several of the others never did work right – or they gave no indication that they were working right. In the case of jNag, it also requires a modified Nagios server and the installation of mkLivestatus. aNag was the one that was easiest to work with and get working.
aNag does use a mostly text-based format to show data, but it has the ability to manipulate services as well as one-button access to the web interface directly.