Introducción
Después de tratar en artículos con MK Livestatus y con las distintas formas de instalarlo / obtenerlo ya sea integrado en check_mk , en OMD o bien mediante una instalación individual, vamos a iniciar con este articulo una serie para aprender a acceder a los datos de Nagios con distintas variantes.
Para familiarizarse un poco más con MK Livestatus recomiendo leer al menos este artículo de instalación o directamente la documentación oficial.
Lo más importante inicialmente es familiarizarse con los datos que podemos obtener y la forma de estos para lo que usaremos una utilidad propia de MK Livestatus para el acceso a estos, unixcat. Posteriormente en otro artículo veremos como acceder a los datos a través de una de las APIs que nos incluye MKL en Python.
Acceso local mediante socket.
LQL – The Livestatus Query Language
Podemos consultar a MK Livestatus por datos de Nagios con un lenguaje propio, LQL, creado a tal efecto. Dicho lenguaje tiene una sintaxis similar en cierto punto a un SQL pero adaptado para consultar tablas de objetos de Nagios, Tenemos numerosos ejemplos en la documentación oficial.
Usaremos dicho lenguaje LQL tanto para acceder a los datos mediante la utilidad unixcat como posteriormente cuando veamos como acceder mediante la API de Python.
Acceso a datos mediante la utilidad “unixcat”
Como toma de contacto para conocer la presentación de los datos vamos a usar la utilidad “unixcat” proporcionada por la instalación de livestatus. Mediante dicha utilidad podemos, de forma muy sencilla, realizar consultas a CMK Livestatus adjuntándoles el fichero “lql” con la sintaxis de lo que buscamos. Unixcat está instalado normalmente con los binarios de check_mk pero es posible que no esté en los paths habituales.
Un ejemplo sencillo. Creamos primero un fichero LQL “test.lql”.
GET services Columns: host_name description state Filter: state = 2 Filter: in_notification_period = 1
Ejecutamos unixcat pasándole el contenido del archivo al socket de livestatus y obtenemos las columnas y los registros que coinciden con el filtro.
$ unixcat < test.lql /opt/omd/sites/jrm2/tmp/run/live
localhost;Interface 2;2
srv-debian;Interface 2;2
srv-ubuntu;Interface 2;2
Si es una consulta sencilla podemos pasarla directamente en línea de comandos. P.e. obtener todos los hosts:
$ echo 'GET hosts' | unixcat /usr/local/nagios/var/rw/live
Como vemos la sintaxis es muy sencilla pero… ¿como sabemos los campos disponibles y valores de campos estándar para realizar filtrados?
Tablas de datos.
Para saber los campos que contiene una tabla (que no aparecen en la documentación) debemos preguntar a una tabla especial “columns”. Así que la consulta lql para conocer los campos de todas las tablas sería obtener todas las columnas
$ 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 ….
Donde aparecerían todas los campos de todas las tablas siendo la penúltima columna la tabla a la que pertenece cada uno. Para poder ser más concretos podemos obtener la información de una tabla con la “query” siguiente en un fichero p.e. “hosts.lql”
GET columns Filter: table = hosts
La ejecutamos y obtenemos todos los campos de la tabla hosts:
descripción (con posibles valores cuando proceda); nombre_campo; tabla; tipo_valor
$ 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
La salida por defecto es en formato CSV. Podríamos cambiar los caracteres e incluso obtener la salida en formato JSON o salida de Python. Solo habría que añadir una línea en la sentencia lql:
OutputFormat: json OutputFormat: python
Un buen punto de partida será listar y guardar en un formato adecuado la información de cada tabla, bien creado los ficheros lql o bien en línea de comandos especificando la tabla. P.e. “hosts.lql”
GET columns Columns: description name type Filter: table = hosts
unixcat < hosts.lql /opt/omd/sites/jrm2/tmp/run/live
O bien mandando a fichero directamente la orden desde línea de comandos,
printf 'GET columns \nFilter: table = hosts \n' | unixcat /opt/omd/sites/jrm2/tmp/run/live >> hosts.csv
En definitiva, tener estas tablas a mano ya que es posible las usemos muy a menudo.
Unixcat es muy útil para familiarizarse con las posibilidades y para con scripting con bash o cualquier otro lenguaje incluso desde otros equipos con ssh. Para programas / sripts más elaborados será mejor usar la API pensada para acceder a estos datos que veremos en un artículo posterior en su variante Python.
Podremos acceder al fichero socket directamente o, con muchas más posibilidades, a través de red habilitando el acceso a dicho fichero con xinetd.
Configuración de acceso remoto al socket livestatus.
Una vez que tenemos check_mk funcionando la configuración para acceder a través de un socket TCP a Livestatus es sencilla y está bien documentada en la página de doc. de livestatus. Vermos ambas posibilidades: configurarlo en una instalación de OMD o bien en una instalación sencilla ya sea de MK Livestatus solamente o integrado con Check_mk.
Configuración en una instalación de OMD (para un site concreto)
Para poder acceder a Livestatus por red en una instalación de OMD ejecutaremos la configuración para la “instancia / usuario” deseado. P.e. dada una instancia previamente creada “jrm2”:
omd config jrm2
Seleccionaremos “Distributed Monitoring” y posteriormente activaremos “LIVESTUS_TCP”
Si la instancia está en ejecución es posible que sea necesario reiniciarla y nos pregunte a tal efecto. Básicamente lo que hace es añadir un fichero de configuración a xinetd para poder acceder a través de este al fichero socket usando la utilidad unixcat.
Una vez configurado creará el fichero de configuración en el etc/xinetd del usuario del site de OMD con las variables de configuración. Inicialmente nos interesa sobre todo “only from” si queremos acceder desde otro equipo al 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 }
Será necesario recargar el site en el caso de OMD: omd reload jrm2 (jrm2 = site)
Instalación independiente de MK Livestatus (o integrada en check_mk)
En el caso de una instalación independiente de check_mk entero o solo de Livestatus deberemos realizar nosotros esta parte. Nos aseguraremos que esté instalado xinetd y crearemos el fichero para poder acceder desde otro sistemas a este. Tenemos un ejemplo para un fichero /etc/xinetd.d/livestatus en la documentación de cmk livestatus … Básicamente sería similar claro al de OMD.
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
instances = 500
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
}
Tendremos que tener cuidado de habilitar tanto las direcciones IP de los equipos permitidos (parámetro only_from) como, si procede, habilitar el acceso en el Firewall local al puerto 6557 desde el exterior y filtrarlo como se desee.
Probando acceso remoto a livestatus.
Podemos usar por ejemplo la utilidad Netcat para acceder de forma remota a livestatus de otro equipo y obtener datos:.
echo ‘GET hosts’ | nc host_remoto 6557
echo ‘GET status’ | nc host_remoto 6557
En próximos artículos echaremos un ojo a la API para Python que nos proporciona MK Livestatus para poder hacer ya desarrollos “serios”.
Bajate el artículo en PDF.
