Checkmk
to checkmk.com
Important

This is a machine translation based on the English version of the article. It might or might not have already been subject to text preparation. If you find errors, please file a GitHub issue that states the paragraph that has to be improved.

1. Introducción

Livestatus es la interfaz más importante de Checkmk. Es la forma más rápida de obtener todos los datos de los hosts y servicios supervisados, incluidos los datos en tiempo real. Así, por ejemplo, los datos de la Vista general se recogen directamente a través de esta interfaz. Como se leen directamente desde la RAM, se evita el lento acceso al disco duro, lo que permite un acceso rápido a la monitorización sin sobrecargar demasiado el sistema.

Para estructurar los datos, estos se organizan en tablas y columnas. La tabla «hosts» incluye, por ejemplo, las columnas «name», « state» y muchas otras. Cada línea de la tabla «hosts» representa un host, la tabla «services» un servicio, y así sucesivamente. De esta forma, los datos se pueden buscar y recuperar fácilmente.

Este artículo debería ayudarte a utilizar esta interfaz para tus propias consultas, extensiones y personalizaciones. Como usuario de la instancia, puedes —mediante copiar y pegar— probar directamente todas las consultas y comandos de este artículo.

2. El lenguaje de consulta Livestatus (LQL)

2.1. Usar el LQL en el shell

El acceso a Livestatus se realiza a través de un socket de Unix utilizando el lenguaje de consulta Livestatus (LQL). Su sintaxis se basa en HTTP.

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

OMD[mysite]:~$ printf "GET hosts\nColumns: name\n" | unixcat ~/tmp/run/live
Copiar comando(s) al portapapeles
¡Comandos copiados correctamente al portapapeles!
¡Se ha denegado el acceso de escritura al portapapeles!

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

OMD[mysite]:~$ lq "GET hosts\nColumns: name"
Copiar comando(s) al portapapeles
¡Comandos copiados correctamente al portapapeles!
¡Se ha denegado el acceso de escritura al portapapeles!

O bien puedes iniciar el flujo de entrada interactivo e introducir el comando seguido del encabezado. Con una línea en blanco ejecutas el comando con su encabezado, y con otra línea más se cierra el acceso al socket. Ten en cuenta 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:

OMD[mysite]:~$ lq
GET hosts
Columns: name

myserver123
myserver124
myserver125

OMD[mysite]:~$
Copiar comando(s) al portapapeles
¡Comandos copiados correctamente al portapapeles!
¡Se ha denegado el acceso de escritura al portapapeles!

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

Comandos LQL

En los primeros ejemplos ya has visto el primero de los dos comandos: con GET puedes consultar todas las tablas disponibles. En la referencia de comandos encontrarás una lista completa, con una descripción, de todas las tablas disponibles, y este artículo también contiene una explicación general sobre el uso de Livestatus.

Con COMMAND puedes enviar comandos directamente al core, por ejemplo, para establecer un tiempo de mantenimiento o para desactivar completamente las notificaciones. En cualquier caso, puedes encontrar una lista de todos los comandos disponibles en la referencia de comandos en Comandos.

Encabezados LQL

En cada comando GET puedes insertar varios encabezados para restringir los resultados de una consulta, mostrar solo columnas específicas de una tabla y mucho más. Estos son los dos encabezados más importantes:

Encabezado Descripción

Columnas

La consulta solo mostrará las columnas especificadas.

Filtro

Solo se mostrarán las entradas que cumplan una condición específica.

Aquí puedes encontrar una lista de todos los encabezados, cada uno con una breve descripción.

Mostrar columnas y tablas disponibles

No es posible recordar todas las tablas y sus columnas, y puede que no siempre sea posible acceder a este manual (con las referencias de la versión en línea). Sin embargo, es posible crear rápidamente una consulta que proporcione la información deseada. Para obtener una lista de todas las tablas disponibles, envía la siguiente consulta y elimina las líneas duplicadas en el resultado con « sort». En el resultado se pueden ver las cuatro primeras líneas a modo de vista de tabla:

OMD[mysite]:~$ lq "GET columns\nColumns: table" | sort -u
columns
commands
comments
contactgroups
Copiar comando(s) al portapapeles
¡Comandos copiados correctamente al portapapeles!
¡Se ha denegado el acceso de escritura al portapapeles!

Para una consulta de todas las columnas de una tabla, por supuesto, debes especificarlas. Sustituye hosts por la tabla deseada. Aquí también se puede tener una vista de tabla de las primeras cuatro líneas de la salida como ejemplo:

OMD[mysite]:~$ lq "GET columns\nFilter: table = hosts\nColumns: name"
accept_passive_checks
acknowledged
acknowledgement_type
action_url
Copiar comando(s) al portapapeles
¡Comandos copiados correctamente al portapapeles!
¡Se ha denegado el acceso de escritura al portapapeles!

2.2. Uso de LQL en Python

Dado que Checkmk se basa en gran medida en Python, los scripts en este lenguaje resultan muy prácticos. El siguiente script puede utilizarse como base para acceder al socket de Livestatus:

live_example.py
#!/usr/bin/env python
# Sample program for accessing Livestatus from Python

import json, os, socket

# for local site only: file path to socket
address = f"{os.getenv('OMD_ROOT')}/tmp/run/live"
# for local/remote sites: TCP address/port for Livestatus socket
# address = ("localhost", 6557)

# connect to Livestatus
family = socket.AF_INET if isinstance(address, tuple) else socket.AF_UNIX
with socket.socket(family, socket.SOCK_STREAM) as sock:
    sock.connect(address)

    # send our request and let Livestatus know we're done
    sock.sendall(b"GET status\nOutputFormat: json\n")
    sock.shutdown(socket.SHUT_WR)

    # receive the reply as a JSON string
    chunks = []
    while not chunks or chunks[-1] != b"":
        chunks.append(sock.recv(4096))

reply = b"".join(chunks).decode()

# print the parsed reply
print(json.loads(reply))
Copiar el contenido del archivo al portapapeles
¡Contenido del archivo copiado correctamente al portapapeles!
¡Se ha denegado el acceso de escritura al portapapeles!

2.3. Uso de la API de Livestatus

Checkmk también ofrece una API para el lenguaje de programación Python, que simplifica el acceso a Livestatus. Hay código ejemplo disponible para esta API, que explica su uso. Puedes encontrar esta API en GitHub.

3. Consultas sencillas

3.1. Consultas de columnas (Columns)

En los ejemplos que hemos visto hasta ahora, se ha consultado TODA la información de TODOS los hosts. Sin embargo, en la práctica, probablemente solo necesitarás columnas específicas. Con el encabezado «Columns» que ya hemos mencionado, el resultado se puede limitar a esta columna. Los nombres de las columnas individuales se separarán con un simple espacio en blanco.

OMD[mysite]:~$ lq "GET hosts\nColumns: name address"
myserver123;192.168.0.42
myserver234;192.168.0.73
Copiar comando(s) al portapapeles
¡Comandos copiados correctamente al portapapeles!
¡Se ha denegado el acceso de escritura al portapapeles!

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

Tip

Si utilizas estos encabezados, el encabezado se omitirá en la salida. Esto se puede volver a insertar en la salida con el encabezado ColumnHeaders.

3.2. Configuración de un filtro sencillo

Para limitar la consulta a líneas específicas, se pueden filtrar las columnas según el contenido especificado. Si solo se van a buscar servicios con un estado específico, esto se puede lograr con un filtro:

OMD[mysite]:~$ lq "GET services\nColumns: host_name description state\nFilter: state = 2"
myserver123;Filesystem /;2
myserver234;ORA MYINST Processes;2
Copiar comando(s) al portapapeles
¡Comandos copiados correctamente al portapapeles!
¡Se ha denegado el acceso de escritura al portapapeles!

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 se pueden combinar y restringir a aquellos servicios con estado «CRIT» y que aún no hayan recibido el Reconocimiento:

OMD[mysite]:~$ lq "GET services\nColumns: host_name description state\nFilter: state = 2\nFilter: acknowledged = 0"
myserver234;Filesystem /;2
Copiar comando(s) al portapapeles
¡Comandos copiados correctamente al portapapeles!
¡Se ha denegado el acceso de escritura al portapapeles!

Como puedes ver, también puedes filtrar por columnas que no están en la lista de Columns.

Operadores y expresiones regulares

Hasta ahora solo se han filtrado los números con coincidencias. El resultado provisional de una consulta también se puede buscar por «menor que» con números o por cadenas de caracteres. Los operadores disponibles se pueden encontrar en el capítulo Operadores de la referencia de comandos. Así, por ejemplo, puedes filtrar por expresiones regulares en las columnas:

OMD[mysite]:~$ lq "GET services\nColumns: host_name description state\nFilter: description ~~ exchange database|availability"
myserver123;Exchange Database myinst1;1
myserver123;Exchange Availability Service;0
myserver234;Exchange Database myinst3;0
Copiar comando(s) al portapapeles
¡Comandos copiados correctamente al portapapeles!
¡Se ha denegado el acceso de escritura al portapapeles!

Con el operador adecuado puedes buscar en las columnas de diversas formas. Livestatus siempre interpretará dicha expresión como «puede aparecer en cualquier lugar de la columna», siempre que no se haya definido lo contrario. Indica el inicio de una línea con, por ejemplo, el carácter ^, y el final de una línea con el carácter $. Encontrarás una lista completa de todos los caracteres especiales de las expresiones regulares de Checkmk en el artículo sobre expresiones regulares.

3.3. Ordenar la salida (OrderBy)

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

OMD[mysite]:~$ lq "GET hosts\nColumns: name\nOrderBy: name"
ahost
anotherhost
yetanotherhost
Copiar comando(s) al portapapeles
¡Comandos copiados correctamente al portapapeles!
¡Se ha denegado el acceso de escritura al portapapeles!

De forma implícita, la salida se ordena en orden ascendente (asc), tal y como se espera. Sin embargo, también puedes especificar explícitamente el orden deseado e invertirlo indicando desc`:

OMD[mysite]:~$ lq "GET hosts\nColumns: name\nOrderBy: name desc"
yetanotherhost
anotherhost
ahost
Copiar comando(s) al portapapeles
¡Comandos copiados correctamente al portapapeles!
¡Se ha denegado el acceso de escritura al portapapeles!

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

OMD[mysite]:~$  lq "GET services\nColumns: host_name performance_data\nFilter: description = Uptime\nOrderBy: performance_data.uptime desc"
anotherhost;uptime|249531.1
yetanotherhost;uptime|149142.3
ahost;uptime|48959
Copiar comando(s) al portapapeles
¡Comandos copiados correctamente al portapapeles!
¡Se ha denegado el acceso de escritura al portapapeles!

4. Consultas complejas

4.1. Filtros para listas

Algunas columnas de una tabla no devuelven un solo valor, sino toda una lista de ellos. Para que esa lista se pueda buscar de forma eficaz, en estos casos los operadores tienen otra función. Puedes encontrar una lista completa de los operadores en Operadores para listas. Por ejemplo, el operador >= tiene la función «contiene». Con esto podrías, por ejemplo, buscar contactos específicos:

OMD[mysite]:~$ lq "GET hosts\nColumns: name address contacts\nFilter: contacts >= hhirsch"
myserver123;192.168.0.42;hhirsch,hhirsch,mfrisch
myserver234;192.168.0.73;hhirsch,wherrndorf
Copiar comando(s) al portapapeles
¡Comandos copiados correctamente al portapapeles!
¡Se ha denegado el acceso de escritura al portapapeles!

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

OMD[mysite]:~$ lq "GET hosts\nColumns: name contacts\nFilter: contacts ="
myserver345;
myserver456;
Copiar comando(s) al portapapeles
¡Comandos copiados correctamente al portapapeles!
¡Se ha denegado el acceso de escritura al portapapeles!

4.2. Combinar filtros

Ya se han combinado varios filtros anteriormente. Parecería intuitivo que los datos deban pasar por todos los filtros para que se muestren. Los filtros se enlazarán así mediante la operación lógica «y». Para enlazar filtros concretos con un «o» lógico, al final de la cadena de código del filtro escribe «o:» seguido de un número entero. El contador especifica cuántas de las últimas líneas se pueden combinar con un «o». De esta forma se pueden formar grupos y combinarlos según sea necesario. A continuación tienes un ejemplo sencillo. Aquí se combinan dos filtros para que se muestren todos los servicios que tengan el estado « WARN» o «UNKNOWN»:

OMD[mysite]:~$ lq
GET services
Columns: host_name description state
Filter: state = 1
Filter: state = 3
Or: 2

myserver123;Log /var/log/messages;1
myserver123;Interface 3;1
myserver234;Bonding Interface SAN;3

OMD[mysite]:~$
Copiar comando(s) al portapapeles
¡Comandos copiados correctamente al portapapeles!
¡Se ha denegado el acceso de escritura al portapapeles!

El resultado de una combinación también se puede invertir, o los grupos se pueden a su vez combinar 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»:

OMD[mysite]:~$ lq
GET services
Columns: host_name description state
Filter: state = 3
Filter: description ~ Filesystem
And: 2
Filter: state = 0
Or: 2
Negate:

myserver123;Log /var/log/messages;1
myserver123;Interface 3;1
myserver234;Filesystem /media;2
myserver234;Filesystem /home;2
Copiar comando(s) al portapapeles
¡Comandos copiados correctamente al portapapeles!
¡Se ha denegado el acceso de escritura al portapapeles!

4.3. Especificar un formato de salida

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

Personalización decsv

Como ya se ha descrito, puedes personalizar con precisión el formato de salida estándar csv (¡en minúsculas!) y definir cómo deben separarse entre sí los elementos individuales. Checkmk reconoce cuatro separadores diferentes para estructurar los datos. Después de dos puntos, escribe el valor ASCII estándar adecuado para que el filtro quede estructurado de la siguiente manera:

Separators: 10 59 44 124

Estos separadores tienen las siguientes funciones:

  1. Separador para los conjuntos de datos: 10 (salto de línea)

  2. Separador para las columnas de un conjunto de datos: 59 (punto y coma)

  3. Separador para los elementos de una lista: 44 (coma)

  4. Separador para los elementos de una lista de servicios: 124 (barra vertical)

Puedes elegir cualquiera de estos valores para estructurar el resultado como quieras. En el siguiente ejemplo, las columnas de un conjunto de datos se han separado con un tabulador (9) en lugar de un punto y coma (59):

OMD[mysite]:~$ lq
GET services
Columns: host_name description state
Filter: description ~ Filesystem
Separators: 10 9 44 124

myserver123     Filesystem /opt     0
myserver123     Filesystem /var/some/path       1
myserver123     Filesystem /home        0
Copiar comando(s) al portapapeles
¡Comandos copiados correctamente al portapapeles!
¡Se ha denegado el acceso de escritura al portapapeles!
Tip

El orden de los separadores es fijo y no se puede modificar.

Cambiar los formatos de salida

Además de generar resultados en formato «csv», Livestatus también puede generar resultados en otros formatos. Estos tienen la ventaja de ser más fáciles y limpios de analizar en lenguajes de programación de alto nivel. Por lo tanto, los resultados pueden codificarse en los siguientes formatos:

Formato Descripción

Python

Genera una salida como una lista compatible con 2.x. El texto está formateado en Unicode.

python3

También genera una salida en forma de lista y, al hacerlo, tiene en cuenta los cambios en el tipo de datos; por ejemplo, la conversión automática del texto a Unicode.

json

La salida también se generará como una lista, pero solo se utilizará un formato compatible con JSON.

CSV

Formatea la salida según el estándar RFC-4180.

csv

Consulta la personalización de csv. Este es el formato estándar si no se especifica otro, y se basa en el formato CSV oficial.

No confundas CSV Format con la salida csv de Livestatus, que se usa si no se ha especificado ningún formato de salida. Por lo tanto, es absolutamente esencial respetar las mayúsculas y minúsculas. Para la personalización, al final especifica OutputFormat en lugar de Separator:

OMD[mysite]:~$ lq
GET services
Columns: host_name description state
Filter: description ~ Filesystem
OutputFormat: json

[["myserver123","Filesystem /opt",0]
["myserver123","Filesystem /var/some/path",1]
["myserver123","Filesystem /home",0]]
Copiar comando(s) al portapapeles
¡Comandos copiados correctamente al portapapeles!
¡Se ha denegado el acceso de escritura al portapapeles!

5. Consultar estadísticas (Stats)

5.1. Introducción

Habrá situaciones en las que no te interese el estado de un servicio concreto o de un grupo de servicios. Mucho más importante es el número de servicios con un estado «WARN» (en funcionamiento), o el número de bases de datos sujetas a la monitorización. Livestatus es capaz de generar y mostrar estadísticas con Stats.

5.2. Cifras

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

OMD[mysite]:~$ lq
GET services
Stats: state = 0
Stats: state = 1
Stats: state = 2
Stats: state = 3

34506;124;54;20
Copiar comando(s) al portapapeles
¡Comandos copiados correctamente al portapapeles!
¡Se ha denegado el acceso de escritura al portapapeles!

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

5.3. Agrupación

Las estadísticas también se pueden combinar con and/or. Los encabezados se llaman entonces StatsAnd o StatsOr. Usa StatsNegate si quieres que el resultado se invierta. En el ejemplo, se mostrará el número total de hosts (el Stats inicial) y, además, el resultado 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):

OMD[mysite]:~$ lq
GET hosts
Stats: state >= 0
Stats: staleness >= 3
Stats: scheduled_downtime_depth = 0
StatsAnd: 2

734;23
Copiar comando(s) al portapapeles
¡Comandos copiados correctamente al portapapeles!
¡Se ha denegado el acceso de escritura al portapapeles!

No te confundas con las diversas opciones para combinar los resultados de los filtros y las estadísticas. Aunque todos los hosts que cumplan las condiciones se mostrarán con el encabezado « Filter», con las estadísticas el resultado será la suma de la frecuencia con la que se aplica el filtro «Stats».

5.4. Mínimo, máximo, promedio, etc.

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

En el siguiente ejemplo, la lista mostrará el promedio, el mínimo y el máximo de tiempo que los check plugins de un host necesitan para calcular un estado:

OMD[mysite]:~$ lq
GET services
Filter: host_name = myserver123
Stats: avg execution_time
Stats: max execution_time
Stats: min execution_time

0.0107628;0.452087;0.008593
Copiar comando(s) al portapapeles
¡Comandos copiados correctamente al portapapeles!
¡Se ha denegado el acceso de escritura al portapapeles!

Los cálculos con métricas se manejan de una forma un poco especial. Aquí también están disponibles todas las funciones del encabezado «Stats». Sin embargo, estas se aplican individualmente a todas las métricas de un servicio. Por ejemplo, en el siguiente ejemplo se sumarán las métricas de carga de CPU de un grupo del host:

OMD[mysite]:~$ lq
GET services
Filter: description ~ CPU utilization
Filter: host_groups >= cluster_a
Stats: sum perf_data

guest=0.000000 steal=0.000000 system=34.515000 user=98.209000 wait=23.008000
Copiar comando(s) al portapapeles
¡Comandos copiados correctamente al portapapeles!
¡Se ha denegado el acceso de escritura al portapapeles!

6. Limitar la salida (Limit)

Se puede limitar a propósito el número de líneas de una salida. Esto puede ser útil si, por ejemplo, solo quieres ver si obtienes algún tipo de respuesta a una consulta de Livestatus, pero quieres evitar una salida de varias páginas:

OMD[mysite]:~$  lq "GET hosts\nColumns: name\nLimit: 3"
myserver123
myserver234
myserver345
Copiar comando(s) al portapapeles
¡Comandos copiados correctamente al portapapeles!
¡Se ha denegado el acceso de escritura al portapapeles!

Ten en cuenta que este límite también funciona cuando se combina con otros encabezados. Si, por ejemplo, con Stat cuentas cuántos hosts tienen un estado UP, y limitas la salida a 10, solo se tendrán en cuenta los primeros 10 hosts.

7. Límites de tiempo (Timelimit)

No solo se puede limitar el número de líneas que se van a mostrar, sino que también se puede limitar el tiempo máximo que se permite que una consulta esté en ejecución. Esta opción puede evitar que una consulta de Livestatus bloquee una conexión indefinidamente si se cuelga por alguna razón. La restricción de tiempo especifica el tiempo máximo en segundos que se permite que una consulta se procese:

OMD[mysite]:~$ lq "GET hosts\nTimelimit: 1"
Copiar comando(s) al portapapeles
¡Comandos copiados correctamente al portapapeles!
¡Se ha denegado el acceso de escritura al portapapeles!

8. Activar los encabezados de columna (ColumnHeaders)

Con «ColumnHeaders», se pueden añadir los nombres de las columnas a la salida. Normalmente se omiten para facilitar el proceso posterior:

OMD[mysite]:~$  lq "GET hosts\nColumns name address groups\nColumnHeaders: on"
name;address;groups
myserver123;192.168.0.42;cluster_a,headnode
myserver234;192.168.0.43;cluster_a
myserver345;192.168.0.44;cluster_a
Copiar comando(s) al portapapeles
¡Comandos copiados correctamente al portapapeles!
¡Se ha denegado el acceso de escritura al portapapeles!

9. Autorizaciones (AuthUser)

Si quieres que los scripts estén disponibles en función del Livestatus, es probable que el usuario solo deba ver los datos para los que tiene autorización. Checkmk proporciona el encabezado AuthUser para esta función, con la restricción de que no se puede usar en las siguientes tablas:

  • columns

  • commands

  • contacts

  • contactgroups

  • eventconsolerules

  • eventconsolestatus

  • status

  • timeperiods

Por el contrario, este encabezado se puede utilizar en todas las tablas que accedan a las tablas hosts o services. La autorización de un usuario para una u otra depende de sus grupos de contacto.

De esta manera, una consulta solo mostrará los datos que el contacto también tenga permiso para ver. Ten en cuenta aquí la diferencia entre la configuración de permisos de strict yloose :

OMD[mysite]:~$ lq "GET services\nColumns: host_name description contacts\nAuthUser: hhirsch"
myserver123;Uptime;hhirsch
myserver123;TCP Connections;hhirsch
myserver123;CPU utilization;hhrisch,kkleber
myserver123;File /etc/resolv.conf;hhirsch
myserver123;Kernel Context Switches;hhrisch,kkleber
myserver123;File /etc/passwd;hhirsch
myserver123;Filesystem /home;hhirsch
myserver123;Kernel Major Page Faults;hhrisch
myserver123;Kernel Process Creations;hhirsch
myserver123;CPU load;hhrisch,kkleber
Copiar comando(s) al portapapeles
¡Comandos copiados correctamente al portapapeles!
¡Se ha denegado el acceso de escritura al portapapeles!

10. Retrasos (Wait)

Con el encabezado Wait puedes crear consultas para conjuntos de datos específicos sin necesidad de saber si se han cumplido los requisitos previos para los datos. Esto puede ser útil cuando, por ejemplo, necesitas datos comparativos para una situación de error concreta, pero no quieres sobrecargar el sistema de forma continua e innecesaria. Por lo tanto, la información solo se recuperará cuando sea realmente necesaria.

Aquí puedes encontrar una lista completa de los encabezados Wait.

En el siguiente ejemplo, se mostrará el servicio «Disk IO SUMMARY» de un servidor ESXi tan pronto como el estado del servicio «CPU load» cambie a una CRIT de máquina virtual específica. Con el encabezado «WaitTimeout», la consulta se ejecutará si la condición no se ha cumplido tras 10 000 milisegundos. Esto evita que la conexión de Livestatus quede bloqueada durante mucho tiempo:

OMD[mysite]:~$ lq
GET services
WaitObject: myvmserver CPU load
WaitCondition: state = 2
WaitTrigger: state
WaitTimeout: 10000
Filter: host_name = myesxserver
Filter: description = Disk IO SUMMARY
Columns: host_name description plugin_output

myesxserver;Disk IO SUMMARY;OK - Read: 48.00 kB/s, Write: 454.54 MB/s, Latency: 1.00 ms
Copiar comando(s) al portapapeles
¡Comandos copiados correctamente al portapapeles!
¡Se ha denegado el acceso de escritura al portapapeles!

Otra aplicación consiste en combinar esto con un comando. Puedes ejecutar un comando y recuperar los resultados tan pronto como estén disponibles. En el siguiente ejemplo queremos consultar y mostrar los datos actuales de un servicio. Para ello, primero se enviará el comando y luego se ejecutará una consulta. Esto checkea si los datos del servicio Check_MK son más recientes que los de un momento determinado. Tan pronto como se cumpla la condición previa, se mostrará el estado del servicio Memory.

OMD[mysite]:~$ lq "COMMAND [$(date +%s)] SCHEDULE_FORCED_SVC_CHECK;myserver;Check_MK;$(date +%s)"
OMD[mysite]:~$ lq
GET services
WaitObject: myserver Check_MK
WaitCondition: last_check >= 1517914646
WaitTrigger: check
Filter: host_name = myserver
Filter: description = Memory
Columns: host_name description state

myserver;Memory;0
Copiar comando(s) al portapapeles
¡Comandos copiados correctamente al portapapeles!
¡Se ha denegado el acceso de escritura al portapapeles!
Tip

Ten en cuenta que la marca de tiempo utilizada en last_check en el ejemplo DEBE sustituirse por una adecuada ; de lo contrario, la condición siempre se cumplirá y la salida se generará inmediatamente.

11. Zonas horarias (hora local)

Muchos entornos de monitorización consultan hosts y servicios a nivel global. En esos casos, puede surgir rápidamente una situación en la que las instancias de monitorización distribuidas operen en diferentes zonas horarias. Como Checkmk utiliza la hora Unix, que es independiente de las zonas horarias, esto no debería suponer ningún problema.

No obstante, si se asigna un servidor a una zona horaria incorrecta, esta diferencia se puede compensar con el encabezado Localtime. Indica también la hora actual en la consulta. Checkmk redondeará entonces de forma autónoma a la media hora siguiente y ajustará la diferencia. Puedes indicar la hora automáticamente si ejecutas la consulta directamente:

OMD[mysite]:~$ lq "GET hosts\nColumns: name last_check\nFilter: name = myserver123\nLocaltime: $(date +%s)"
myserver123;1511173526
Copiar comando(s) al portapapeles
¡Comandos copiados correctamente al portapapeles!
¡Se ha denegado el acceso de escritura al portapapeles!

De lo contrario, proporciona el resultado de date +%s si quieres utilizar el flujo de entrada:

OMD[mysite]:~$ lq
GET hosts
Columns: name last_check
Filter: name = myserver123
Localtime: 1511173390

myserver123;Memory;1511173526
Copiar comando(s) al portapapeles
¡Comandos copiados correctamente al portapapeles!
¡Se ha denegado el acceso de escritura al portapapeles!

12. Códigos de estado (ResponseHeader)

Si escribes una API, probablemente querrás recibir un código de estado como respuesta, para poder procesar mejor el resultado. El encabezado «ResponseHeader» admite los valores «off» (Estándar) y «fixed16», y con ellos proporciona un mensaje de estado de exactamente 16 bytes de longitud en la primera línea de la respuesta. En caso de error, las líneas siguientes contendrán una descripción detallada del código de error. Por lo tanto, también son muy útiles para localizar el error en los resultados de la consulta.

El informe de estado de la primera línea combina lo siguiente:

  • Bytes 1-3: El código de estado. La tabla completa de códigos posibles la puedes encontrar aquí.

  • Byte 4: Un simple carácter en blanco (carácter ASCII: 32)

  • Bytes 5-15: La longitud de la respuesta real como un número entero. Los bytes innecesarios se rellenan con caracteres en blanco.

  • Byte 16: Un salto de línea (carácter ASCII: 10)

En el siguiente ejemplo ejecutaremos una consulta errónea en la que un filtro está, de hecho, codificado erróneamente con un nombre de columna.

OMD[mysite]:~$ lq "GET hosts\nName: myserver123\nResponseHeader: fixed16"
400          33
Columns: undefined request header
Copiar comando(s) al portapapeles
¡Comandos copiados correctamente al portapapeles!
¡Se ha denegado el acceso de escritura al portapapeles!

En caso de error, el formato de salida es siempre un mensaje de error en forma de texto. Esto se aplica independientemente de cualquier adaptación que hayas realizado.

13. Mantener la conexión activa (KeepAlive)

Especialmente con scripts que establecen una conexión Livestatus a través de la red, es posible que quieras mantener el canal abierto para ahorrarte la sobrecarga que genera el tener que establecer la conexión repetidamente. Puedes conseguirlo con el encabezado KeepAlive, y de esta forma podrás reservar un canal. Por cierto, tras ejecutar un comando, una conexión Livestatus siempre permanece abierta. No es necesario introducir ningún encabezado adicional para ello.

Tip

Dado que el canal queda bloqueado para otros procesos mientras dura la conexión, puede suponer un problema si no hay otras conexiones disponibles. Por lo tanto, los demás procesos deben esperar hasta que se libere una conexión. En la configuración estándar, Checkmk mantiene 20 conexiones listas; aumenta el número máximo de estas conexiones según sea necesario con Setup > General > Global Settings > Monitoring Core > Maximum concurrent Livestatus connections.

Combina siempre KeepAlive con Response header, para poder distinguir correctamente las respuestas individuales entre sí:

OMD[mysite]:~$ lq
GET hosts
ResponseHeader: fixed16
Columns: name
KeepAlive: on

200          33
myserver123
myserver234
myserver345
GET services
ResponseHeader: fixed16
Columns: host_name description last_check
Filter: description = Memory

200          58
myserver123;Memory;1511261122
myserver234;Memory;1511261183
Copiar comando(s) al portapapeles
¡Comandos copiados correctamente al portapapeles!
¡Se ha denegado el acceso de escritura al portapapeles!

Asegúrate de que no haya ninguna línea en blanco entre la primera respuesta y la segunda solicitud. En cuanto se omita un encabezado en una consulta, tras la siguiente salida, la conexión se cerrará como de costumbre mediante la línea en blanco.

14. Recuperación de registros

14.1. Vista general

Con la tabla log en Livestatus tienes acceso directo al historial de monitorización del core, de modo que, utilizando el LQL, puedes filtrar fácilmente eventos concretos. Las tablas de disponibilidad, por ejemplo, se generarán con la ayuda de estas tablas. Para mejorar la Vista general y restringir una consulta por temas, tienes acceso a las siguientes clases de registros:

Clase Descripción

0

Todos los mensajes no incluidos en otras clases

1

Alertas de host y servicio

2

Eventos importantes del programa

3

Notificaciones

4

Comprobaciones pasivas

5

Comandos externos

6

Entradas de estado iniciales o actuales (por ejemplo, tras una rotación de registros)

7

Cambios en el estado del programa

Con solo usar estas clases de registro ya puedes restringir muy bien qué tipo de entrada debe mostrarse. El intervalo de tiempo que se tiene en cuenta en la consulta se restringirá adicionalmente. Esto es importante, ya que, de lo contrario, se buscaría en todo el historial de la instancia , lo que lógicamente podría ralentizar mucho el sistema debido a la avalancha de información.

Otra restricción útil 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:

OMD[mysite]:~$ lq "GET log\nFilter: class = 3\nFilter: time >= $(($(date +%s) - 3600))\nColumns: host_name service_description time state"
myserver123;Memory;1511343365;0
myserver234;CPU load;1511343360;3
myserver123;Memory;1511343338;2
myserver234;CPU load;1511342512;0
Copiar comando(s) al portapapeles
¡Comandos copiados correctamente al portapapeles!
¡Se ha denegado el acceso de escritura al portapapeles!
Tip

Asegúrate de que, en el modo interactivo del flujo de entradas, no se pueda utilizar ninguna de las variables empleadas en el ejemplo, y limita siempre las consultas a un intervalo de tiempo.

14.2. Configuración del historial de monitorización

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 configuración de la instancia. Hay disponibles los tres parámetros siguientes, que puedes encontrar y personalizar en Setup > General > Global Settings > Monitoring Core:

Nombre Descripción

History log rotation: Regular interval of rotations

Aquí se puede definir en qué intervalo de tiempo debe continuar el historial en un nuevo archivo.

History log rotation: Rotate by size (Limit of the size)

Independientemente del intervalo de tiempo, aquí se define el tamaño máximo de un archivo. El tamaño representa un equilibrio entre la velocidad de lectura posible y las E/S posibles.

Maximum number of parsed lines per log file

Cuando se haya leído el número de líneas especificado, la lectura del archivo se detendrá. Esto evita los tiempos de espera si, por cualquier motivo, un archivo se vuelve muy grande.

15. Checking availability

Con la tabla statehist puedes consultar los datos sin procesar sobre la disponibilidad de hosts y servicios, y así tener acceso a toda la información que utiliza la pantalla de disponibilidad de la interfaz. Introduce siempre un intervalo de tiempo; de lo contrario, se buscarán todos los registros disponibles, lo que puede suponer una gran carga para el sistema. También se aplican las siguientes especificaciones adicionales:

  • El intervalo de tiempo en el que un host/servicio tuvo un estado concreto se puede mostrar como un valor absoluto o como hora Unix, y también como un valor relativo o como porcentaje del intervalo de tiempo consultado.

  • Durante los periodos en los que no hubo monitorización de un host/servicio, el estado será «-1».

Comprobar si, cuándo y durante cuánto tiempo se ha realizado la monitorización de un host o servicio es posible en Checkmk gracias al registro del estado inicial. Así, no solo puedes ver qué estado existía en un momento específico, sino que también puedes rastrear si realmente se estaba realizando la monitorización en ese momento. Importante: Este registro también está activo con un Nagios-Core. Sin embargo, aquí se puede desactivar:

~/etc/nagios/nagios.d/logging.cfg
log_initial_states=0

En el ejemplo siguiente se puede ver cómo se ve la consulta de una distribución porcentual y los tiempos absolutos para un estado concreto. Se han especificado las últimas 24 horas como intervalo de tiempo, y la consulta se ha restringido a la disponibilidad de un servicio en un host concreto:

OMD[mysite]:~$ lq
GET statehist
Columns: host_name service_description
Filter: time >= 1511421739
Filter: time < 1511436139
Filter: host_name = myserver123
Filter: service_description = Memory
Stats: sum duration_ok
Stats: sum duration_warning
Stats: sum duration_critical
Stats: sum duration_part_ok
Stats: sum duration_part_warning
Stats: sum duration_part_critical

myserver123;Memory;893;0;9299;0.0620139;0;0.645764
Copiar comando(s) al portapapeles
¡Comandos copiados correctamente al portapapeles!
¡Se ha denegado el acceso de escritura al portapapeles!

En la Referencia de comandos se explica con más detalle cómo se puede obtener una lista completa de las columnas disponibles.

16. Variables en Livestatus

En varios lugares de la interfaz de Checkmk puedes usar variables para realizar asignaciones basadas en el contexto. Algunos de estos datos también se pueden recuperar a través de Livestatus. Como estas variables también deben resolverse, los valores de estas columnas se duplican en una tabla: una vez como entrada literal y otra vez con la variable sustituida por el valor adecuado. Un ejemplo de ello es la columna «notes_url», que muestra una URL con la variable:

OMD[mysite]:~$ lq "GET hosts\nColumns: name notes_url"
myserver123;https://mymonitoring/heute/wiki/doku.php?id=hosts:$HOSTNAME$
Copiar comando(s) al portapapeles
¡Comandos copiados correctamente al portapapeles!
¡Se ha denegado el acceso de escritura al portapapeles!

Sin embargo, si en lugar de esto consultas la columna note_url_expanded, recibirás el valor real de la macro:

OMD[mysite]:~$ lq "GET hosts\nColumns: name notes_url_expanded"
myserver123;https://mymonitoring/heute/wiki/doku.php?id=hosts:myserver123
Copiar comando(s) al portapapeles
¡Comandos copiados correctamente al portapapeles!
¡Se ha denegado el acceso de escritura al portapapeles!

17. Uso de Livestatus a través de una red

17.1. Conexiones a través de TCP/IP

Para acceder a Livestatus a través de la red, puedes establecer una conexión entre el socket Unix del proceso de estado en vivo y un puerto TCP. De esta forma, puedes ejecutar scripts en máquinas remotas y recopilar los datos directamente desde donde deben procesarse.

Cuando un site está desactivado, se puede habilitar el acceso a través de TCP con el comando « omd»:

OMD[mysite]:~$ omd config set LIVESTATUS_TCP on
Copiar comando(s) al portapapeles
¡Comandos copiados correctamente al portapapeles!
¡Se ha denegado el acceso de escritura al portapapeles!

Una vez que se ha iniciado el site, Livestatus a través de TCP suele estar activo en el puerto predeterminado 6557. Para servidores Checkmk con varios sitios que utilizan Livestatus a través de TCP, se elige el siguiente puerto sin usar más alto.

Todos los ajustes, como el puerto y las direcciones IP autorizadas, se pueden configurar mediante omd config. También puedes realizar estos ajustes en la configuración. En Checkmk, el cifrado SSL de la comunicación de Livestatus está habilitado por defecto:

Livestatus configuration in Setup.
Configuración de Livestatus en la configuración

Prueba de conexión SSL local

Livestatus utiliza un certificado que se genera automáticamente al crear el sitio. Este certificado se encuentra en el archivo var/ssl/ca-certificates.crt junto con todos los demás certificados de CA en los que confía el sitio. Para que la herramienta de línea de comandos openssl s_client pueda validar el certificado utilizado por el servidor de Livestatus, este archivo debe designarse como «Archivo de autoridad de certificación».

Hemos acortado mucho la salida de la llamada al comando aquí; […​] muestra lo que nos hemos saltado:

OMD[mysite]:~$ openssl s_client -CAfile var/ssl/ca-certificates.crt -connect localhost:6557
CONNECTED(00000003)
Can't use SSL_get_servername
depth=1 CN = Site 'mysite' local CA
verify return:1
depth=0 CN = mysite
verify return:1
---
Certificate chain
 0 s:CN = mysite
   i:CN = Site 'mysite' local CA
 1 s:CN = Site 'mysite' local CA
   i:CN = Site 'mysite' local CA
---
Server certificate
[...]
    Start Time: 1664965470
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
    Max Early Data: 0
---
read R BLOCK
Copiar comando(s) al portapapeles
¡Comandos copiados correctamente al portapapeles!
¡Se ha denegado el acceso de escritura al portapapeles!

En cuanto no haya más salida, puedes ejecutar comandos LQL de forma interactiva y terminar la interacción con una línea en blanco (pulsa dos veces Enter). Si esto funciona, también puedes canalizar consultas de Livestatus y usar el parámetro adicional -quiet para suprimir la salida de depuración:

OMD[mysite]:~$ echo -e "GET hosts\nColumns: name\n\n" | \
    openssl s_client -quiet  -CAfile var/ssl/ca-certificates.crt -connect localhost:6557
Can't use SSL_get_servername
depth=1 CN = Site 'mysite' local CA
verify return:1
depth=0 CN = mysite
verify return:1
myserver23
myserver42
myserver123
myserver124
Copiar comando(s) al portapapeles
¡Comandos copiados correctamente al portapapeles!
¡Se ha denegado el acceso de escritura al portapapeles!

La salida que precede a los cuatro nombres del host se escribe en STDERR mediante el comando openssl. Se puede suprimir añadiendo 2>/dev/null.

Acceso remoto a Livestatus

Si accedes a Livestatus desde máquinas remotas, no debes usar toda la lista de certificados en los que confía el sitio de Checkmk en esas máquinas. En su lugar, lee el certificado de la CA del sitio solo desde la configuración.

Para ello, ve a Global Settings > Site management > Trusted certificate authorities for SSL. Aquí puedes copiar y pegar el certificado utilizado por la CA del sitio. Copia el texto completo del primer certificado que aparece en Content of CRT/PEM file en un archivo; en nuestro ejemplo utilizamos /tmp/mysite_ca.pem.

Display of the site CA's certificate in the Setup.
Visualización del certificado de la CA del site en la configuración

Si ya se ha habilitado el acceso a Livestatus para el host remoto, podrás realizar consultas a Livestatus mediante scripts con este archivo de certificado:

user@host:~$ echo -e "GET hosts\nColumns: name\n\n" | \
    openssl s_client -quiet  -CAfile /tmp/mysite_ca.pem -connect cmkserver:6557
Copiar comando(s) al portapapeles
¡Comandos copiados correctamente al portapapeles!
¡Se ha denegado el acceso de escritura al portapapeles!

Nota: El archivo de certificado no proporciona autenticación, ¡solo garantiza el cifrado del transporte! La protección de acceso se regula exclusivamente a través de las direcciones IP autorizadas para acceder al puerto de Livestatus.

Livestatus con stunnel

Si quieres que el puerto remoto cifrado de Livestatus esté disponible como puerto local sin cifrar, puedes usar el programa stunnel.

/etc/stunnel/cmk_myremotesite.conf
[pinning client]
client = yes
accept = 0.0.0.0:6557
connect = <myremotesiteip>:6557
verifyPeer = yes
CAfile = /etc/stunnel/myremotesite.pem

Tras reiniciar stunnel, es posible el acceso sin cifrar al puerto local.

user@host:~$ echo -e "GET hosts\nColumns: name\n\n" | nc localhost 6557
Copiar comando(s) al portapapeles
¡Comandos copiados correctamente al portapapeles!
¡Se ha denegado el acceso de escritura al portapapeles!

SSL in scripts

Si quieres usar scripts para acceder a Livestatus a través de SSL, evita usar openssl s_client. El objetivo principal de esta herramienta es probar el establecimiento de la conexión y depurar las cadenas de certificados. Para comprobar si la salida esperada es completa en caso de fallos de conexión, te recomendamos evaluar el encabezado de la respuesta. Una API bien mantenida que admite SSL y la evaluación de encabezados es la de Python, que puedes encontrar en GitHub.

17.2. Conexiones a través de SSH

Si necesitas acceder a Livestatus desde fuera de tu red local, la protección de acceso basada únicamente en direcciones IP puede no ser práctica. La forma más fácil de obtener acceso autenticado en este caso es utilizar Secure Shell.

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

user@host:~$ ssh mysite@myserver 'lq "GET hosts\nColumns: name"'
myserver123
myserver234
Copiar comando(s) al portapapeles
¡Comandos copiados correctamente al portapapeles!
¡Se ha denegado el acceso de escritura al portapapeles!

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

user@host:~$ ssh -L 6557:localhost:6557 mysite@myserver
Copiar comando(s) al portapapeles
¡Comandos copiados correctamente al portapapeles!
¡Se ha denegado el acceso de escritura al portapapeles!

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

user@host:~$ openssl s_client -CAfile /tmp/mysite_ca.pem -connect localhost:6557
Copiar comando(s) al portapapeles
¡Comandos copiados correctamente al portapapeles!
¡Se ha denegado el acceso de escritura al portapapeles!

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

18. Comandos de configuración

18.1. Vista general

Livestatus no solo se puede usar para consultar datos, sino también para enviar comandos directamente al core (CMC o Nagios). Un comando correcto siempre incluye una marca de tiempo; de hecho, esta puede ser cualquier cosa que se necesite. Sin embargo, como también se utilizará en los registros para rastrear la hora del proceso, es recomendable introducir la hora con la mayor precisión posible. Los comandos a los que les falte la marca de tiempo se descartarán, sin generar un mensaje de error , y solo aparecerá una simple entrada en el archivo 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 ejecutarlo directamente. En tal situación también hay acceso a variables y se puede proporcionar la hora actual real:

OMD[mysite]:~$ lq "COMMAND [$(date +%s)] DISABLE_NOTIFICATIONS"
Copiar comando(s) al portapapeles
¡Comandos copiados correctamente al portapapeles!
¡Se ha denegado el acceso de escritura al portapapeles!

Este formato funciona tanto con el Nagios-Core de CRE Checkmk Community como con el CMC de las ediciones comerciales. Sin embargo, en los dos núcleos los comandos solo se solapan parcialmente. Puedes encontrar una lista completa de los comandos para el Nagios-Core directamente en el sitio web de Nagios. Los comandos disponibles para el CMC se pueden encontrar en la Referencia de comandos.

18.2. Características especiales de Nagios

CRE En la lista de comandos, la sintaxis tiene el siguiente formato:

#!/bin/sh
# This is a sample shell script showing how you can submit the CHANGE_CUSTOM_HOST_VAR command
# to Nagios.  Adjust variables to fit your environment as necessary.

now=`date +%s`
commandfile='/usr/local/nagios/var/rw/nagios.cmd'

/bin/printf "[%lu] CHANGE_CUSTOM_HOST_VAR;host1;_SOMEVAR;SOMEVALUE\n" $now > $commandfile

Como ya sabes, Checkmk utiliza un formato mucho más sencillo para ejecutar comandos. Para que el formato de Nagios sea compatible con Checkmk, solo necesitas el comando, la marca de tiempo y, cuando sea aplicable, las variables:

OMD[mysite]:~$ lq "COMMAND [$(date +%s)] CHANGE_CUSTOM_HOST_VAR;host1;_SOMEVAR;SOMEVALUE"
Copiar comando(s) al portapapeles
¡Comandos copiados correctamente al portapapeles!
¡Se ha denegado el acceso de escritura al portapapeles!

19. Archivos y directorios

Ruta Función

~/tmp/run/live

El socket de Unix a través del cual se envían las consultas y los comandos.

~/bin/lq

Comando de script para simplificar el envío de consultas y comandos al socket de Unix en Livestatus.

~/var/log/cmc.log

El archivo de registro del CMC, en el que, junto con otros datos, se documentan las consultas y los comandos.

~/var/check_mk/core/history

El archivo de registro del CMC, en el que se registran todos los cambios que se producen durante el tiempo de ejecución del core, por ejemplo, cambios en el estado de un host o servicio.

~/var/check_mk/core/archive/

Los archivos de registro de history se archivan aquí. Solo se leerán si es necesario.

~/var/log/nagios.log

El archivo de registro de Nagios-Core, en el que, junto con otros datos, se documentan las consultas y los comandos.

~/var/nagios/archive/

Los archivos de registro de history se archivan aquí. Solo se leerán si es necesario.

~/share/doc/check_mk/livestatus/LQL-examples/

En este directorio encontrarás varios ejemplos de consultas de Livestatus que puedes probar. Los ejemplos se basan en el comando del script lq, por ejemplo: lq < 1.lql


Last modified: Tue, 27 Jan 2026 10:58:11 GMT via commit 3d944493f
En esta página