MK Livestatus. Accessing Nagios data with “unixcat” and LQL.


Introduction.

In recent posts we have installed check_mk in Centos / Redhat 6 or Centos / Redhat 7. Installing full check_mk integrates MK Livestatus component although it is also possible to install it separately to access a Nagios standalone data.

The most important thing is to know initially that data can be obtained and the format of these. We will use a utility included with MK Livestatus for Nagios data access, unixcat. Then in another post we will see how to access data through one of the APIs that includes MK Livestatus (Python).

Local access via socket.

 

LQL – The Livestatus Query Language

We can ask for Nagios data to MK Livestatus with its own language, LQL, created for this purpose. This language has a similar sintaxis to SQL by adapted to query Nagios object tables, There are numerous examples in the official documentation.

We will use LQL to access Nagios data using the utility unixcat.

 

Access to data by “unixcat” utility

Let’s use the “unixcat” utility provided by the installation of Livestatus. By this utility you can, very easily, perform queries to MK Livestatus by attaching the “LQL” file with the syntax of the data to search. Unixcat binary is normally installed with check_mk but maybe not in the user path.

A simple example. We create a file LQL “test.lql” to get Nagios services in critical state.

GET services
Columns: host_name description state
Filter: state = 2
Filter: in_notification_period = 1

Run unixcat passing LQL file to MK Livestatus socket and we get the columns and records that match the filter.

$ unixcat < test.lql /opt/omd/sites/jrm2/tmp/run/live
localhost;Interface 2;2
srv-debian;Interface 2;2
srv-ubuntu;Interface 2;2

 

With a simple query we can pass it directly on the command line. E.g. all hosts:

$ echo 'GET hosts' | unixcat /usr/local/nagios/var/rw/live

The syntax is very simple but … how do we know the available fields and values of tables for filtering?

Data tables.

To find fields that contains a table we must query to a special table “columns”. LQL query to know all fields in all tables coul be:

$ echo 'GET columns' | unixcat /opt/omd/sites/jrm2/tmp/run/live
The name of the column within the table;name;columns;string
The name of the table;table;columns;string
….

You can get at all the fields of all tables. In the the next to last column, the table name to which each field belongs to. To be more specific we can get the information for a table with the following filter query and LQL file “Hosts.lql

GET columns
Filter: table = hosts

Execute with unixcat and get all the fields of hosts table with description (with possible values where appropriate); field_name; table; value_type

$ unixcat < hosts.lql /opt/omd/sites/jrm2/tmp/run/live
description;name;table;type
Whether passive host checks are accepted (0/1);accept_passive_checks;hosts;int
Whether the current host problem has been acknowledged (0/1);acknowledged;hosts;int
Type of acknowledgement (0: none, 1: normal, 2: stick);acknowledgement_type;hosts;int

Default return is in CSV format. We can change this to get data in JSON or Python format with a descripción line about exit type in LQL query file:

OutputFormat: json
OutputFormat: python

 

A good starting point is to list and store in an appropriate format all information of each table, either created the LQL files or directly on the command line by specifying the table and save this info. E.g.

GET columns
Columns: description name type
Filter: table = hosts
unixcat < hosts.lql /opt/omd/sites/jrm2/tmp/run/live

With command line direcly (without use a LQL file)

printf 'GET columns \nFilter: table = hosts \n' | unixcat /opt/omd/sites/jrm2/tmp/run/live >> hosts.csv

In conclusion, having these tables by hand, it is possible we use them very often.
Unixcat is helpful to become familiar with the possibilities and with scripting with bash or any other language even from other computers with ssh. For more complex programs / scripts is better use the Python, Perl or C++ API designed for accessing data that include MK Livestatus. There is documentacion about this in sofware directory install.
We can access the socket file directly or through network providing access to the file with Xinet.

 

Configuring remote access to Livestatus socket.

With check_mk running configuration for access through a TCP socket to Livestatus is simple and well documented . There are two possibilities: configure an installation of OMD or in simple installation either MK Livestatus alone or integrated with full install Check_mk.

Configuring an installation of OMD (for a specific site)

To access network in Livestatus by OMD run the configuration for the “instance / user” desired. E.g. with an instance OMD “jrm2” previously created:

omd config jrm2

omd_config_jrm2_livestatus1

 

Select “Distributed Monitoring” and activate “LIVESTUS_TCP”

 

omd_config_jrm2_livestatus2

If the instance is running, it may be necessary to restart and ask us to do so. Basically it add a xinetd configuration file to access the file through this socket using unixcat utility. This menu utility create the configuration file in the etc/xinetd directory in OMD user instance site. Initially we were particularly interested in “only from” parameter to access from another computer to the socket.

{
 type = UNLISTED
 socket_type = stream
 protocol = tcp
 wait = no
 cps = 100 3
 instances = 500
 per_source = 250 
 flags = NODELAY
 only_from = 127.0.0.1 10.0.20.1 10.0.20.2
 disable = no
 port = 6557
 user = jrm2
 server = /omd/sites/jrm2/bin/unixcat
 server_args = /omd/sites/jrm2/tmp/run/live
}

You will need to reload the site in OMD: omd reload jrm2

 

Configure a standalone Installation of MK Livestatus (or integrated into check_mk)

For a standalone installation of MK Livestatus or integrated in check_mk full install we must make this part. We will make sure that xinetd is installed and create the file to be accessed from other systems. An example for a /etc/xinetd.d/livestatus file in the documentation cmk Livestatus. Basically it would be similar at OMD config file.

service livestatus
{
 type = UNLISTED
 port = 6557
 socket_type = stream
 protocol = tcp
 wait = no
# limit to 100 connections per second. Disable 3 secs if above.
 cps = 100 3
# set the number of maximum allowed parallel instances of unixcat.
# Please make sure that this values is at least as high as
# the number of threads defined with num_client_threads in
# etc/mk-livestatus/nagios.cfg
 instances = 500
# limit the maximum number of simultaneous connections from
# one source IP address
 per_source = 250
# Disable TCP delay, makes connection more responsive
 flags = NODELAY
 user = nagios
 server = /usr/bin/unixcat
 server_args = /var/lib/nagios/rw/live
# configure the IP address(es) of your Nagios server here:
 only_from = 127.0.0.1 10.0.20.1 10.0.20.2
 disable = no
}

Careful, you must enable both IP addresses of computers allowed (parameter only_from) and enable / filter access to the local Firewall tcp port 6557 from the outside.

Testing remote access to Livestatus.

We can use for example the Netcat utility to remotely access another computer Livestatus and get information:

echo 'GET hosts' | nc host_remoto 6557
echo 'GET status' | nc host_remoto 6557

Continue with post “MK Livestatus. Get Nagios data with Python API2.

Download this post.

 

Leave a comment

Your email address will not be published. Required fields are marked *

*