Mar/108
LivestatusSlave – Webservice for MKLivestatus
MKLivestatus is a Nagios Event Broker (NEB) Module which can be used to extend the core of Nagios. The MKLivestatus module provides access to the live status information kept in the running Nagios process. It serves a unix socket for data exchange with external scripts/addons.
Making Livestatus available on the Network
It is possible to make the Livstatus unix socket (which is only available on the system where Livestatus runs) to remote systems on the network e.g. using xinetd.
Using xinetd the unix socket is served as tcp socket on the network. This tcp/unix sockets can be queried using the most programming languages.
But in many cases it would be better to have an easier way reaching the Livestatus information.
A big benefit could be to have the livestatus socket available via HTTP to make it queryable for example using XMLHttpRequest.
With this idea the LivestatusSlave was born.
What is the LivestatusSlave?
The LivestatusSlave is a so called “webservice” written in PHP. Basically LivestatusSlave is a single PHP script which gets the plain livestatus query from a parameter and returns the livestatus response as array in JSON syntax.
LivestatusSlave does not really care about authentication, authorisation or the syntax of the livestatus query. It is only a small translator between the HTTP client and the Livestatus socket.
Downloading LivestatusSlave
LivestatusSlave is in early developement. A package of livestatus slave can be downloaded here: livestatus-slave-1.1.tar.gz.
There is also a public git repository available which contains the newest sources: mklivestatus-slave.
System Requirements
LivestatusSlave needs a webserver which supports at least PHP 5. The PHP needs suport for json and socket functions. You might need to install additional packages to get those modules.
And you also need a running Nagios with a loaded MKLivestatus NEB module.
Installing LivestatusSlave
Just drop the live.php somewhere on your system where it is reachable via a webserver which supports PHP. For example you could place it in your nagios/share directory.
Then you need to edit the $conf Array in live.php to point to your Livestatus socket path.
Example
I placed the live.php in my nagios/share directory so it is reachable now via:
http://<my-nagios-server>/nagios/live.php
It is very easy to query the LivestatusSlave. Simply open the live.php in your Browser with the following URL:
http://<my-nagios-server>/nagios/live.php?q=GET hosts\nColumns: name state\nFilter: name = www.nagvis.org\n
Now I get the following response:
[[0,"OK"],[["www.nagvis.org",0]]]
More readable and with comments added:
[ // Header [ // Response Code 0, // Response Message "OK" ], // Body [["www.nagvis.org",0]] ]
The response is in JSON format. It is an array where the first element is the header which is an array itselfs and the second element is the response body which may be an array of elements.
The response header is built of two elements. The first element is the response code, the second element is the description of the response, for example an error message.
The response code is 0 on a successful query and different than 0 when a problem occured.







09:32 on December 15th, 2010
Hello, interesting code for use with livestatus. I had to correct line 215 (socketAddres should be written socketAddress) for use with tcp socket.
I had to put complementary “\” in the URL to access livestatus data, aka http://…/live.php?q=GET hosts\\nColumns: name state\\n
Great job though, very helpful.
Loran
01:25 on August 18th, 2011
Thanks for this code! Like Loran, I also had to fix the mispelling of socketAdres to socketAddress before I could get tcp working. I am having to make some other very minor modifications and am hoping they might be rolled into your code so we don’t have problems upgrading any time you come out with new releases
Firstly, we want to only support the GET operation, and so it would be nice to move “define(‘QUERY_TYPES’, ‘(GET|LOGROTATE|COMMAND)’);” into the $config array so that it can easily be over-ridden.
Also, we want to have optional support for jsonp to get around cross-site scripting issues (http://en.wikipedia.org/wiki/JSONP), and so have redefined the “response” function to be as follows and would appreciate any feedback:
function response($head, $body) { $json_result = json_encode(Array($head, $body)); // Support jsonp (see http://en.wikipedia.org/wiki/JSONP). if(isset($_REQUEST['callback']) && $_REQUEST['callback'] != ”) { $callback_name = $_REQUEST['callback']; $json_result = “$callback_name($json_result)”; } header(“content-type:application/json”); echo $json_result; }
01:27 on August 18th, 2011
I don’t know if you are interested in feature requests, but it would be nice to be able to force calls to “GET log” to have filters restricting the time range to be less than a certain amount (eg. must range over less than a week).
22:53 on August 18th, 2011
Hello,
David, thank you for the ideas. I just applied the changes but haven’t tested them yet.
The idea with the time range filter sounds like a configuration based hard coded filter based on the different tables which is then added to each query, correct?
01:45 on August 19th, 2011
Thanks for that! I have just had a loot at the git repo and I notice that you have added a new version of the response function without deleting the old one.
As a first step, it would be nice to have a hook to preprocess the query . Maybe add a line after $query = getQuery(); that looks like this $query = preprocess_hook($query);
The do-nothing default would be defined before you include the live_config.php file.
03:10 on August 19th, 2011
By the way, you left out a “global $conf;” at the start of getQuery(). Cheers, David.
07:19 on August 19th, 2011
Damn, was untested
was coding too much python in the last days where you don’t need the global keyword just for reading global vars.
I just pushed the fixed version. And I also added command line support. You can do the following now:
php live.php “GET services\n”