Recuperación de datos de estado a través de Livestatus

El acceso al Livestatus se realiza a través de un socket Unix utilizando elLenguaje de Consulta del Livestatus (LQL). Su sintaxis está basada en HTTP.

A través de la línea de comandos hay varias formas de acceder a la interfaz. Una posibilidad es utilizar los comandos printf y unixcat para enviar una instrucción al socket. La herramienta unixcat ya está incluida en Checkmk para el usuario de instancia. Importante: todas las entradas al socket distinguen entre mayúsculas y minúsculas, por lo que siempre hay que tenerlo en cuenta:

La interfaz espera todos los comandos y cabeceras en una línea separada. Puedes marcar dicho salto de línea con \n. Como alternativa al comando anterior, también puedes utilizar el comando script lq, que te ahorra un poco de trabajo al autocompletar algunos campos al entrar:

O puedes iniciar el flujo de entrada interactivo e introducir el comando seguido de la cabecera. Con una línea en blanco ejecutas el comando con su cabecera, y con otra línea se finaliza el acceso al socket. Observa que en el ejemplo, todo lo que hay antes de la línea en blanco pertenece al comando, y todo lo que hay entre la primera y la segunda línea en blanco es la respuesta:

Los siguientes ejemplos se ejecutan siempre con el comando lq: de forma directa cuando la consulta es breve, y como flujo de entrada para consultas más largas.

Dado que Checkmk se basa en gran medida en Python, resulta práctico utilizar scripts en este lenguaje. El siguiente script puede utilizarse como base para un acceso al socket de Livestatus:

Checkmk proporciona una API para los lenguajes de programación Python, Perl y C++, que simplifica el acceso a Livestatus. Hay disponible un código de ejemplo para cada lenguaje que explica su uso. Las rutas a estos ejemplos se encuentran en el capítulo Archivos y directorios.

En los ejemplos que hemos visto hasta ahora, se ha consultado TODA la información de TODOS los host. En la práctica, sin embargo, es probable que sólo se necesiten columnas concretas. Con la cabecera Columns que ya se ha mencionado, la salida puede limitarse a esta columna. Los nombres de las columnas individuales estarán separados por un simple espacio en blanco.

Como puedes ver, en una línea los valores individuales están separados por punto y coma.

Importante: Si utilizas estas cabeceras, se suprimirá la cabecera en la salida. Ésta se puede volver a insertar en la salida con la cabecera ColumnHeaders.

Para limitar la consulta a líneas concretas, se pueden filtrar las columnas por contenidos específicos. Si sólo se quieren buscar servicios con un estado concreto, se puede conseguir con un filtro:

En el ejemplo, se buscarán todos los servicios con estado CRIT, y se mostrarán el nombre del host, la descripción del servicio y su estado. Por supuesto, estos filtros pueden combinarse y limitarse a los servicios con estadoCRIT que aún no hayan sido reconocidos:

Como se puede ver, también se puede filtrar por columnas que no aparecen en Columns.

Puedes utilizar la cabecera OrderBy para ordenar la salida según el contenido de cualquier columna o incluso según los valores de cualquier clave del diccionario. Esto te permite crear una lista alfabética de todos los host, por ejemplo:

Implícitamente, la salida se ordena en orden ascendente (asc) como era de esperar. Sin embargo, también puedes especificar explícitamente la ordenación deseada e invertirla especificando desc`:

Con consultas algo más largas y ordenación por, por ejemplo, datos de rendimiento, se pueden crear listas de clasificación interesantes. En el siguiente ejemplo, los host se muestran en orden descendente según su tiempo de actividad:

Algunas columnas de una tabla no devuelven un único valor, sino toda una lista de ellos. Para que esa lista pueda buscarse eficazmente, en estos casos los operadores tienen otra función. Puedes encontrar una lista completa de los operadores en Operadores para listas. Así, por ejemplo, el operador >= tiene la función "contiene". Con él podrías, por ejemplo, buscar contactos concretos:

Como puede verse en el ejemplo anterior, los contactos se enumerarán, separados por comas, en la columna contacts. Esto permite distinguirlos claramente por no ser el inicio de otra columna. Una característica especial del operador de igualdad es que comprueba si una lista está vacía:

Anteriormente ya se han combinado varios filtros. Parece intuitivo que los datos deban pasar por todos los filtros para poder mostrarse. Así, los filtros se enlazarán mediante la operación lógica y. Para enlazar filtros concretos con un operador lógico y, al final de la cadena de filtros codifica un o: seguido de un número entero. El contador especifica cuántas de las últimas líneas pueden combinarse con una o. De esta forma, se pueden formar grupos y combinarlos como se desee. A continuación se muestra un ejemplo sencillo. Aquí se combinan dos filtros para que se muestren todos los servicios que tengan el estadoWARN o UNKNOWN:

El resultado de una combinación también se puede negar, o los grupos se pueden combinar a su vez en otros grupos. En el ejemplo, se muestran todos los servicios cuyo estado no sea OK y cuya descripción empiece por Filesystem, o que tengan un estado distinto de UNKNOWN:

El formato de salida puede especificarse de dos formas. Un método consiste en redefinir los separadores utilizados en la salida estándar. El otro método consiste en obtener una salida conforme a los formatos Python o JSON.

Habrá situaciones en las que no te interese el estado de un único servicio o grupo de servicios. Mucho más importante es el número de servicios con un estado WARN actual, o el número de bases de datos monitorizadas. Livestatus puede generar y dar salida a estadísticas con Stats.

Overview recibe sus datos recuperando estadísticas de host, servicios y eventos a través de Livestatus y mostrándolas en la interfaz de Checkmk. Con el acceso directo a Livestatus puedes elaborar tu propio resumen:

Por cierto, estas estadísticas se pueden combinar con todos los filtros.

Las estadísticas también se pueden combinar con and/or. Las cabeceras se llaman entonces StatsAnd o StatsOr. Utiliza StatsNegate si la salida debe ser inversa. En el ejemplo se mostrará el número total de hosts (el Stats inicial), y además se incluirá el recuento de hosts marcados como stale y que tampoco aparecen en una lista de tiempo de mantenimiento (las estadísticas 2 y 3 están enlazadas con un "Y" lógico):

No te confundas con las distintas opciones para combinar los resultados de los filtros y las estadísticas. Mientras que todos los host que cumplan las condiciones se mostrarán utilizando la cabeceraFilter la salida será la suma de las veces que se aplique el filtro Stats.

También es posible realizar cálculos sobre valores y, por ejemplo, mostrar un valor medio o un valor máximo. Aquí encontrarás una lista completa de todos los operadores posibles.

En el siguiente ejemplo, la salida listará los tiempos medio, mínimo y máximo que requieren los plugins de check plugin de un host para calcular un estado:

Los cálculos con métricas se gestionan de una forma un tanto especial. Aquí también se pueden utilizar todas las funciones de encabezado Stats. Sin embargo, se aplican individualmente a todas las métricas de un servicio. Por ejemplo, en el siguiente ejemplo se sumarán las métricas de la carga de CPU de un grupo del host:

Con la tabla log de Livestatus tienes un acceso directo al historial de monitorización del núcleo, de modo que utilizando el LQL puedes filtrar convenientemente por eventos concretos. Las tablas de disponibilidad, por ejemplo, se generarán con la ayuda de estas tablas. Para mejorar la visión general y restringir una consulta temáticamente, tienes acceso a las siguientes clases de registro:

Con sólo utilizar estas clases de registro ya puedes restringir muy bien qué tipo de entrada debe mostrarse. Además, se restringirá el intervalo de tiempo que se tiene en cuenta en la consulta, lo cual es importante porque, de lo contrario, se buscará en todo el historial de la instancia, lo que lógicamente podría suponer un fuerte freno para el sistema debido a la avalancha de información.

Otra restricción sensata de la salida son los (Columns) que se mostrarán para una entrada. En el ejemplo siguiente buscaremos todas las notificaciones que se hayan registrado en la última hora:

Importante: Asegúrate de que en el modo interactivo del flujo de entrada no se puede utilizar ninguna de las variables utilizadas en el ejemplo, y restringe siempre las consultas a un intervalo de tiempo.

Es posible influir en la rotación de los archivos y en sus tamaños máximos. Además, puedes especificar cuántas líneas de un archivo deben leerse antes de que Checkmk interrumpa. Todo esto puede afectar al rendimiento de tus consultas, dependiendo de la construcción de la instancia. Dispones de los tres parámetros siguientes, que puedes encontrar y personalizar en Setup > General > Global Settings > Monitoring Core:

Para acceder a Livestatus a través de la red, puedes conectar el socket Unix del proceso de estado en vivo a un puerto TCP. De esta forma puedes ejecutar scripts en máquinas remotas y recoger los datos directamente desde donde deben ser procesados.

Cuando un site está apagado, se puede habilitar el acceso vía TCP con el comandoomd:

Una vez iniciado el site, Livestatus vía TCP suele estar activo en el puerto por defecto 6557. Para servidores Checkmk con múltiples sites que utilicen Livestatus vía TCP, se elige el siguiente puerto superior no utilizado.

Todos los ajustes, como el puerto y las direcciones IP autorizadas, pueden configurarse a través de omd config. Alternativamente, estos ajustes pueden hacerse en la configuración. En Checkmk, la encriptación SSL de la comunicación Livestatus está activada por defecto:

Si es necesario acceder a Livestatus desde fuera de tu red local, la protección de acceso basada sólo en direcciones IP puede no ser práctica. La forma más sencilla de obtener acceso autentificado en este caso es utilizar el Secure Shell.

Con SSH, tienes la posibilidad de pasar un comando que se ejecutará en el servidor remoto:

Alternativamente, puedes reenviar el puerto de Livestatus al host en el que estés trabajando a través de un túnel SSH:

Si se ha establecido la conexión, en una segunda sesión de consola puedes probar si es posible el acceso con openssl s_client:

Si esta prueba tiene éxito, cualquier script que hayas escrito para el acceso directo a la red Livestatus puede utilizarse en localhost.

Livestatus no sólo se puede utilizar para consultar datos, sino también para emitir comandos directamente al núcleo (CMC o Nagios). Un comando correcto siempre incluye una marca de tiempo, que puede ser cualquier cosa que se desee. Sin embargo, como se utilizará también en los Registros para hacer un seguimiento de la hora del proceso, es conveniente introducir la hora con la mayor precisión posible. Los comandos a los que les falte una marca de tiempo se descartarán, sin emitir un mensaje de error y con una simple entrada en el campo cmc.log¡!

Para que la marca de tiempo sea lo más precisa posible, se recomienda no establecer el comando en el flujo de entrada, sino emitirlo directamente. En tal situación también se tiene acceso a variables y se puede proporcionar la hora actual real:

Este formato funciona tanto con el Nagios-Core en Checkmk edición Raw como con la CMC en las ediciones comerciales. Sin embargo, en los dos núcleos los comandos sólo se solapan parcialmente. Puedes encontrar una lista completa de los comandos para el Nagios-Core directamente en el sitio webde Nagios. Los comandos disponibles para la CMC se encuentran en laReferencia de comandos.

En la lista de comandos, la sintaxis es la siguiente:

Como has aprendido, Checkmk utiliza un formato mucho más sencillo para emitir comandos. Para que el formato de Nagios sea compatible con Checkmk, sólo necesitas el comando, la marca de tiempo y, si procede, las variables: