Checkmk en la línea de comando

Cuando administres Checkmk, salvo algunas excepciones, nunca tendrás que trabajar como usuario de root. En este artículo supondremos, en general, que has iniciado sesión como usuario del site. Esto se hace, por ejemplo, con

También es posible hacer un inicio de sesión SSH directo a un site sin rodeo a través de root. Como el usuario del site es un usuario de Linux "completamente normal", sólo tienes que asignarle una contraseña para ello (lo que requiere root-permisos, una sola vez, para la configuración):

Después debería ser posible un inicio de sesión SSH directamente desde otro ordenador (los usuarios de Windows utilizan preferentemente PuTTY para ello). Desde Linux, este inicio de sesión se realiza simplemente en la línea de comandos utilizando el comando ssh:

En el primer inicio de sesión es probable que se reciba una "advertencia" sobre una clave de host desconocida. Cuando estés seguro de que en este breve momento ningún atacante se ha apoderado de la dirección IP de tu sistema operativo, puedes simplemente verificarla con yes.

También puedes trabajar con la línea de comandos en el appliance Checkmk. Cómo se hace se explica en su propio artículo.

Para que surjan el menor número posible de problemas, sobre todo como consecuencia de distribuciones individuales o configuraciones distintas del sistema operativo, el sistema Checkmk se asegura de que el usuario del site -y también todos los procesos de monitorización- tengan siempre un entorno claramente definido. Junto con el directorio de inicio y los permisos, las variables del entorno desempeñan un papel importante.

Entre otras cosas, al iniciar sesión como usuario del site se establecerán o modificarán las siguientes variables. Estas variables están disponibles para su uso en todos los procesos que se ejecuten dentro del site. Esto también se aplica a los scripts que son invocados indirectamente por estos procesos (por ejemplo, los propios scripts de notificación de un usuario).

Con el comando env puedes mostrar todas las variables del entorno; si añades | sort a este comando, la lista quedará un poco más clara:

En Linux, el entorno es un atributo de un proceso. Cada proceso tiene sus propias variables, que pasa automáticamente a los subprocesos. Éstos parten inicialmente con las mismas variables heredadas, pero también pueden modificarlas.

Con el comando env siempre puedes ver sólo el entorno del shell actual. Si sospechas que hay un error en el entorno de un proceso concreto, con un pequeño truco puedes, no obstante, obtener una lista de su entorno. Para ello sólo necesitas el identificador del proceso (PID). Puedes identificarlo, por ejemplo, con ps ax, pstree -p o top. Con ello podrás acceder directamente al archivo environ del proceso a través del sistema de archivos /proc. Aquí tienes como ejemplo un comando adecuado para el PID 13222:

Si necesitas variables definidas por el usuario para tus propios scripts u otro software que se ejecute en el site, guárdalas en el archivo etc/environment que se ha creado especialmente para este fin. Todas las variables definidas aquí estarán disponibles en cualquier parte del site:

Si deseas personalizar tu shell (Prompt u otras cosas), puedes hacerlo como de costumbre en el archivo .bashrc. No obstante, las variables del entorno pertenecen aetc/environment, por lo que es seguro que estarán disponibles para todos los procesos.

Tampoco hay nada que te impida tener tu propio archivo .vimrc si te gusta trabajar con VIM.

El siguiente gráfico muestra los directorios más importantes de una instalación de Checkmk con un site llamado mysite y un <version> llamado, por ejemplo, 2.0.0p8.cee:

La base de esta estructura la proporciona el directorio /omd. Sin excepción, todos los archivos de Checkmk se encuentran aquí./omd es, de hecho, un enlace simbólico a /opt/omd, mientras que los datos físicosreales se encuentran en /opt - pero todas las rutas de datos de Checkmk utilizan siempre /omd.

Es importante la separación entre los datos (resaltados en amarillo) y el software (azul). Los datos del site se encuentran en /omd/sites, y el software instalado en /omd/versions.

Como cualquier usuario de Linux, el usuario del site también tiene un directorio de inicio, al que nos referimos como directorio del site. Si tu site se llamamysite, se encontrará en /omd/sites/mysite. Como es habitual en Linux, el shell abrevia el directorio de inicio propio con una tilde (~) (o guión oscilante). Como inmediatamente después de un inicio de sesión estarás realmente en este directorio, la tilde aparece automáticamente en el prompt de entrada:

Los subdirectorios del directorio del site se muestran relativos a la tilde:

Dentro del directorio del site hay una serie de subdirectorios que se pueden listar con ll:

Como puede verse, los directorios bin, include, lib,share y version son enlaces simbólicos. El resto son directorios "normales". Esto refleja la separación entre software y datos explicada anteriormente. El directorio de software debe ser accesible como subdirectorio en el site, pero se encuentra físicamente en /omd/versions, y posiblemente también pueda ser utilizado por otros sites.

Los directorios de software, como es habitual en Linux, pertenecen a rooty, por tanto, no pueden ser alterados por un usuario del site. Existen los siguientes subdirectorios - los del ejemplo se encuentran físicamente dentro de/omd/versions/2.0.0p8.cee, y son accesibles mediante enlaces simbólicos desde el directorio del site:

El enlace simbólico version/ es una "parada intermedia" y sirve como punto de relevo para la versión utilizada por el site. Durante una actualización del software se cambiará de la versión antigua a la nueva. No obstante, no intentes realizar una actualización manualmente alterando el enlace, ya que una actualización requiere una serie de pasos adicionales, que fracasarán.

Los datos reales de un site se encuentran en los subdirectorios restantes del directorio del site. Sin excepción, éstos pertenecen al usuario del site. También se incluye el propio directorio del site. Checkmk no almacena nada aparte de los directorios allí listados. Aquí puedes crear sin problema tus propios archivos y directorios, en los que se pueden guardar, según se desee, pruebas, datos descargados, copias de archivos de registro, etc.

Se han predefinido los siguientes directorios:

Como se acaba de mostrar en la tabla anterior, el directorio local con sus numerosos subdirectorios está destinado a tus propias ampliaciones. En un site nuevo, todos los directorios de local/ están inicialmente vacíos.

Con el práctico comando tree puedes obtener rápidamente una visión general de la estructura de local. La opción -L 3 restringe la profundidad a 3:

Todos los directorios del nivel más bajo se integran activamente en el software. Un archivo almacenado aquí se tratará del mismo modo que si estuviera en el directorio con el mismo nombre dentro de /omd/versions/…​ (o respectivamente, en la ruta lógica del site bajo bin, lib o share).

Ejemplo: En el site, los programas ejecutables se buscarán en biny en local/bin.

Aquí se aplica que en caso de nombres idénticos el archivo en localsiempre tiene prioridad. Esto permite modificar el software sin necesidad de cambiar los archivos de instalación en /omd/versions/. El procedimiento es sencillo:

Respecto al punto 3 anterior, si no se sabe exactamente a qué servicio se aplica el cambio, basta con reiniciar el site completo con omd restart.

En Checkmk -como ya se ha descrito- los archivos de registro se almacenan en eldirectorio var/. Allí se pueden encontrar todos los archivos de registro de los componentes relevantes:

En la interfaz web puedes configurar fácilmente hasta qué punto se deben escribir datos en los archivos de registro buscando en Setup > General > Global settings todas las entradas con logging:

Alternativamente, también es posible personalizar los niveles de registro en la línea de comandos de los archivos de configuración. Cada uno de los archivos se llama global.mk, pero están ubicados en directorios diferentes. Especifica las entradas si no están ya presentes, como es el caso, si todavía no se ha modificado Factory setting.

En este archivo se establecen las entradas Monitoring Core, Notifications y Alert Handlers:

En este archivo puedes configurar el registro de User Interface.

La cantidad de datos registrados aumenta de forma inversa a medida que disminuye el recuento. El nivel de registro más bajo es 50 (Critical), mientras que la mayor cantidad de datos se registrará a 10, que corresponde al más alto (Debug).

Este archivo se utiliza para Livestatus Proxy logging. Los valores posibles aquí corresponden a los del registro de User Interface.

Importante: Los archivos de registro pueden llegar a ser muy grandes rápidamente si se ha establecido un nivel alto. Por lo general, es aconsejable utilizar estos ajustes para una personalización "temporal", como ayuda en la identificación de problemas, por ejemplo.

El comando cmk es en realidad una abreviatura de check_mk, introducida para que el comando sea más rápido de escribir. El comando incluye una ayuda en línea integrada y muy detallada, que se puede llamar con la opción --help:

Como puedes ver en el comando anterior, hemos llamado a la ayuda con la opción -h en lugar de --help. Porque lo que es cierto para el comando en sí, también lo es para sus opciones: Cuanto menos haya que teclear, más rápido se va. No para todas las opciones, pero para las que se necesitan a menudo, existe por tanto una forma abreviada además de la forma larga. Aunque la forma larga es más intuitiva, especialmente para los principiantes (check_mk --list-hosts) que la forma abreviada (cmk -l), utilizaremos la forma abreviada en el Manual de usuario. En caso de duda, siempre puedes consultar la ayuda del comando. En cualquier caso, es buena idea echar un vistazo más largo a la ayuda del comando, ya que no presentaremos todas las opciones en el Manual de usuario.

Al introducir una opción, inicias el comando cmk en un modo determinado. A continuación se presenta una Vista general de las opciones que presentaremos en este capítulo, pero también en otras partes del manual:

En algunos modos, dispones de otras opciones específicas, por ejemplo, puedes limitar el descubrimiento de servicios a determinados checks, por ejemplo, al check df con el comando cmk -I --detect-plugins=df myserver123.

Hay una serie de opciones que siempre funcionan, independientemente del modo con el que se ejecute el comando:

En la siguiente sección mostraremos cómo se pueden utilizar los comandos. Los ejemplos se muestran en su mayoría de forma abreviada.

Las ediciones comerciales utilizan el Checkmk Micro Core (CMC) como núcleo de monitorización, Checkmk edición Raw utiliza Nagios. Una tarea importante para el cmk es la generación de un archivo de configuración que sea legible para el núcleo, y que contenga todos los host, servicios, contactos, grupos de contacto, periodicidades, etc. configurados. A partir de esta información, el núcleo sabe qué checks deben ejecutarse y qué objetos debe proporcionar mediante el Livestatus de la GUI.

Tanto para Nagios como para la CMC, es fundamental que el número de host, servicios y otros objetos permanezca siempre estático durante la operación, y que este número sólo pueda alterarse mediante la generación de una nueva configuración, seguida de una recarga del núcleo. Con Nagios también es necesario reiniciar el núcleo. La CMC dispone de una función muy eficaz para la recarga de su configuración durante el proceso activo.

La siguiente tabla destaca las diferencias importantes entre las configuraciones de ambos núcleos:

Regenerar la configuración siempre es necesario si se ha modificado el contenido del archivo de configuración en etc/check_mk/conf.d, o de los servicios detectados automáticamente en var/check_mk/autochecks. El Setup guarda un registro de tales cambios y los resalta en la GUI para activarlos. Si te "saltas el Setup" modificando la configuración manualmente o con un script, también tendrás que ocuparte de la activación manualmente. Los siguientes comandos cumplen esta función:

En resumen: Si quieres personalizar una configuración de Checkmk y activar los cambios, en Nagios necesitarás posteriormente:

Y con la CMC:

Un segundo modo de Checkmk se ocupa de la ejecución de las comprobaciones basadas en Checkmk de un host. Con esto puedes permitir que todos los servicios detectados automáticamente, y también los configurados manualmente, se comprueben inmediatamente, sin necesidad de molestarte con el núcleo de monitorización o la GUI.

Para ello, introduce cmk --check seguido del nombre de un host configurado en la monitorización. Como la opción --check es la opción por defecto de cmk, también puedes omitirla. Además, siempre debes añadir las dos opciones -n (no enviar los resultados al núcleo) y -v (emitir todos los resultados). Encontrarás más información al respecto en la descripción de las opciones que figura más abajo.

Más consejos:

Las siguientes opciones influyen en el comando:

El comando cmk -d recupera y muestra la salida del agente Checkmk de un host. Con cmk -d los datos del agente se recuperan de la misma forma que con la monitorización. No se validan ni se procesan. Así, los datos mostrados coinciden exactamente con los que se entregan al Controlador de agentes (cuando está activado el cifrado TLS) o a un programa de tunelización en caso de que estén configurados los programas de fuentes de datos.

Incluso puedes ejecutar cmk -d utilizando el nombre o la dirección IP de un host que no esté configurado en la monitorización. En este caso se asumirá la configuración heredada del host (conexión TCP al puerto 6556, sin Controlador de agentes, sin encriptación, sin programa fuente de datos).

En las ediciones comerciales también puedes preparar los agentes desde la línea de comandos, como harías a través de la interfaz web. Esto te da la opción, por ejemplo, de actualizar los agentes regularmente, por ejemplo mediante un cronjob.

Para crear los agentes, utiliza la opción -A seguida del nombre de un host (o de varios):

La salida muestra que los paquetes de agentes disponibles para el host myserver123 se han preparado correctamente. Si no especificas un host, los paquetes se prepararán para todos los hosts.

El comando sólo prepara los paquetes cuando es necesario. Si los paquetes aún están actualizados, el resultado será algo parecido a esto:

Puedes forzar la preparación con la opción -f (forzar).

El comando cmk -l simplemente lista los nombres de todos los host configurados en la Configuración:

Como los datos se proporcionan "desnudos" y "sin procesar", es fácil utilizarlos en scripts; por ejemplo, se puede construir un bucle con todos los nombres del host:

Si en lugar de echo introduces un comando que realice algo con sentido, puede ser realmente útil.

La invocación cmk --list-tag también muestra los nombres del host, pero también ofrece la posibilidad de filtrar por tags del host. Simplemente introduce un tag del host y recibirás todos los hosts que tengan ese tag. El siguiente ejemplo muestra una lista de todos los host monitorizados por SNMP:

Introduce varias etiquetas y se enlazarán con "y". El siguiente comando muestra todos los hosts que son monitorizados tanto por agentes SNMP como por agentes Checkmk. Como ningún host cumple esta condición, la salida queda vacía:

Para uno o más host especificados, cmk -D muestra los servicios, tags del host, etiquetas y otros atributos configurados. Como la lista de servicios es tan extensa, puede parecer algo confusa en el terminal. Envía la salida a través de less -S para evitar una interrupción:

Checkmk proporciona de serie un gran número de Plugin listos para usar. En cada versión se añaden algunos nuevos, y la versión 2.0.0 ya incluye unos 2.000 Plugin. Tres opciones del comando cmk te dan acceso a información sobre estos Plugin.

cmk -L produce una tabla de todos los Plugin con su nombre, tipo y descripción. Al mismo tiempo, también se listarán los Plugin de escritura propia almacenados en local/.

Los tipos posibles son los siguientes:

Por supuesto, la lista se puede filtrar simplemente con grep si se busca algo concreto:

Si quieres más información sobre un determinado Plugin, se puede llamar a la documentación como página de manual (o página man) con cmk -M:

Esto produce el siguiente resultado:

Si utilizas cmk -m sin más opciones, accederás a un catálogo completo de todas las páginas man de los plugins de check.

Puedes navegar interactivamente por este catálogo:

Si esperas un compendio exhaustivo que cubra la estructura exacta de todos los archivos de configuración que utiliza Checkmk, lamentablemente tendremos que decepcionarte en este punto. La complejidad y diversidad que contienen los archivos de configuración es sencillamente excesiva para describirla por completo en este Manual de usuario.

El siguiente ejemplo muestra un conjunto de parámetros completo para el plugin de check que monitoriza los sistemas de archivos en Checkmk. Debido a la gran cantidad de parámetros, la captura de pantalla está dividida en dos partes y en minúsculas:

El pasaje correspondiente en el archivo de configuración tiene este aspecto (con un formato algo más agradable):

Como se puede ver, hay más de 10 parámetros diferentes, cada uno con su propia lógica individual. Algunos se configuran utilizando números de coma flotante (0.8), otros con números enteros (24), otros con palabras clave ('onlow'), otros con valores booleanos (True), y otros utilizando tuplas para codificar diversas combinaciones de éstos ((5.0, 10.0)).

Éste es sólo un ejemplo de entre más de 2.000 Plugins. Y, por supuesto, hay otras configuraciones posibles como parámetros de check: Basta pensar en periodicidades, reglas de la Consola de eventos, perfiles de usuario y muchas más.

Por supuesto, ¡eso no significa que no puedas utilizar archivos de texto como configuración! Si aún no conoces la sintaxis exacta de la tarea de configuración que has elegido, sólo necesitas la herramienta adecuada para ello, y a esta herramienta la llamamos Configuración:

Por tanto, sólo necesitas saber en qué archivo escribe Setup.

Nota: Cuando se trate de nombres de directorios, archivos o incluso contenidos de archivos, a menudo encontrarás el término wato. WATO es la abreviatura de Web Administration Tool: la herramienta de configuración de Checkmk hasta la versión 1.6.0 inclusive. La función de WATO ha sido asumida por el menú Setup, o Setup para abreviar, a partir de la versión 2.0.0. Aunque WATO ha sido (casi) completamente sustituido por Setup en la interfaz web, sigue vivo en el sistema de archivos.

Existe un comando práctico para averiguar qué archivo acaba de modificar Setup: find. Invocando "find" con los siguientes parámetros puedes encontrar todos los archivos (-type f) bajo etc/ que han sido modificados en el último minuto (-mmin -1):

La base de una configuración es siempre el directorio etc/check_mk. Debajo de éste hay una subdivisión en varios dominios, que generalmente se aplican a un servicio específico. Al mismo tiempo, cada uno tiene un directorio con el sufijo .d, bajo el cual se leerán automáticamente todos los archivos con el sufijo .mk en orden alfabético. En algunos habrá también una carpeta principal que se lee en primer lugar. Ésta está destinada únicamente a la alteración manual, y nunca es modificada por Setup.

Debajo de los directorios de configuración .d/ siempre hay el subdirectorio wato, por ejemplo etc/check_mk/conf.d/wato. El Setup fundamentalmente sólo lee y escribe aquí. Sin embargo, el servicio responsable del directorio de configuración también lee los demás archivos de "su" directorio .d, si has almacenado allí algunos archivos creados manualmente. Esto significa:

En términos puramente formales, todos los archivos de configuración de Checkmk están escritos en sintaxis Python 3. Hay dos tipos de archivos:

Los archivos ejecutables se reconocen por tener variables que se sustituyen por asignaciones con valores (=). Los demás archivos suelen contener un diccionario Python que comienza con un corchete de apertura {. A veces son simples valores.

Si se requiere un carácter no ASCII en un archivo (una diéresis alemana (ä, ö, ü), por ejemplo), se debe codificar el siguiente comentario en la primera o segunda línea:

De lo contrario, se producirá un error de sintaxis al leer el archivo. Para más consejos sobre la sintaxis de Python, te recomendamos que visites un site especializado, por ejemplo:The Python Language Reference.

Si editas manualmente los archivos de configuración en etc/check_mk/, es conveniente que compruebes la configuración. Puedes hacerlo con la herramienta cmk-update-config, que en realidad sólo se ejecuta automáticamente tras una actualización de versión con omd update:

Por ejemplo, en el extracto anterior puedes ver la referencia a un corchete no cerrado.