Checkmk en la línea de comando

Cuando administre Checkmk, salvo algunas excepciones, nunca tendrá que trabajar como usuario de root. En este artículo asumiremos generalmente que ha 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. Dado que el usuario del site es un usuario Linux "completamente normal", simplemente debe asignar 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 preferiblemente PuTTY para esto). Desde Linux este inicio de sesión se realiza simplemente en la línea de comando utilizando el comando ssh:

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

También puede 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 resultado de distribuciones individuales o configuraciones diferentes 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 ejecutan 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 puede mostrar todas las variables del entorno - añadiendo | sort a este comando la lista queda 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 comienzan inicialmente con las mismas variables heredadas, pero también pueden alterarlas.

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

Si necesita variables definidas por el usuario para sus propios scripts u otro software a ejecutar en el site, guárdelas en el fichero etc/environment que ha sido creado especialmente para este propósito. Todas las variables definidas aquí estarán disponibles en cualquier lugar dentro 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 en una instalación 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 en Checkmk utilizan siempre /omd.

Es importante la separación entre datos (resaltados en amarillo) y software (en 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 su site se llamamysite se encontrará en /omd/sites/mysite. Como es habitual en Linux el shell abrevia el propio directorio de inicio con una tilde (~) (o guión girado). Dado que inmediatamente después de un inicio de sesión se encontrará 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 se encuentran varios 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 un subdirectorio en el site, pero se encuentra físicamente en /omd/versions, y también puede ser utilizado posiblemente por otros sites.

Los directorios de software, como es habitual en Linux, pertenecen a rooty, por tanto, no pueden ser modificados 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 intente realizar una actualización manualmente modificando el enlace, ya que una actualización requiere una serie de pasos adicionales, que fallarán.

Los datos reales de un site se encuentran en el resto de subdirectorios 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í puede crear sin problemas sus propios archivos y directorios, en los que se pueden guardar a voluntad 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 sus propias ampliaciones. En un site nuevo, todos los directorios de local/ están inicialmente vacíos.

Con el práctico comando tree puede 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á de la misma manera que si estuviera en el directorio con el mismo nombre dentro de /omd/versions/…​ (o respectivamente, en la ruta lógica desde el 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 el 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:

En relación con el 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 encuentran todos los archivos de registro de los componentes relevantes:

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

Como alternativa, también es posible personalizar los niveles de registro en la línea de comandos de los archivos de configuración. Los archivos se denominan global.mk, pero se encuentran en directorios diferentes. Especifique las entradas si aún no están presentes, como es el caso, si un Factory setting aún no se ha modificado.

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

En este archivo puede 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 rápidamente muy grandes 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 hacer el comando más rápido de escribir. El comando incluye una ayuda en línea integrada, muy detallada, que puede ser llamada con la opción --help:

Como puede 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í mismo 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 aquellas que se necesitan a menudo, existe por tanto una forma corta además de la forma larga. Aunque la forma larga es más intuitiva, especialmente para principiantes (check_mk --list-hosts) que la forma corta (cmk -l), utilizaremos la forma corta en el Manual de usuario. En caso de duda, siempre puede consultar la ayuda del comando. En cualquier caso, es conveniente 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, se inicia 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, además, dispone de opciones específicas, por ejemplo, puede 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 en 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 su core de monitorización, el Checkmk Raw Edition 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 configurados, servicios, contactos, grupos de contacto, periodicidades, etc. En base a 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:

La regeneración de la configuración siempre es necesaria si se ha modificado el contenido del archivo de configuración en etc/check_mk/conf.d, o los servicios detectados automáticamente en var/check_mk/autochecks. El Setup mantiene un registro de tales cambios y los resalta en la GUI como activación de cambios. En caso de "saltarse el Setup" modificando la configuración manualmente o con un script, también tendrá que ocuparse de la activación manualmente. Los siguientes comandos cumplen esta función:

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

Y con la CMC:

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

Para ello, introduzca cmk --check seguido del nombre de un host configurado en la monitorización. Dado que la opción --check es la opción por defecto de cmk, también puede omitirla. Además, siempre debe añadir las dos opciones -n (no enviar los resultados al núcleo) y -v (mostrar todos los resultados). Encontrará más información al respecto en la descripción de las opciones que aparece a continuación.

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. Por lo tanto, los datos mostrados coinciden exactamente con los datos que se entregan al Controlador de agentes (cuando el cifrado TLS está activado) o a un programa de tunelización en caso de que los programas de origen de datos estén configurados.

Puede incluso 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 para el 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 puede bakear los agentes desde la línea de comandos, como lo haría a través de la interfaz web. Esto le da la opción, por ejemplo, de actualizar los agentes regularmente, por ejemplo mediante un cronjob.

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

La salida muestra que los paquetes de agentes disponibles para el host myserver123 han sido bakeados con éxito. Si no se especifica un host, los paquetes serán bakeados para todos los hosts.

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

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

El comando cmk -l simplemente lista los nombres de todos los host configurados en el Setup:

Dado que los datos se proporcionan 'desnudos' y 'sin procesar', es fácil utilizarlos en scripts - por ejemplo, se puede construir un bucle a través de todos los nombres del host:

Si, en lugar de echo insertas un comando que realice algo significativo, esto puede ser realmente útil.

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

Introduzca múltiples tags y se enlazarán con 'y'. El siguiente comando muestra todos los hosts que son monitorizados tanto por SNMP como por agentes Checkmk. Como ningún host cumple esta condición, la salida permanece vacía:

Para uno o más hosts especificados, cmk -D muestra los servicios configurados, tags del host, etiquetas y otros atributos. Como la lista de servicios es tan extensa, puede parecer algo confusa en el terminal. Envíe 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 alrededor de 2.000 Plugin. Tres opciones del comando cmk le 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 puede filtrarse simplemente con grep si se busca algo específico:

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

Esto produce la siguiente salida:

Usando cmk -m sin más opciones accederá a un catálogo completo de todas las páginas de manual de los plugins de check.

Puede navegar interactivamente en este catálogo:

Si espera un compendio exhaustivo que cubra la estructura exacta de todos los archivos de configuración utilizados por Checkmk, lamentablemente tendremos que decepcionarle. La complejidad y diversidad contenida en los ficheros de configuración es simplemente demasiado para describirla completamente en este Manual de usuario.

El siguiente ejemplo muestra un conjunto completo de parámetros para el plugin de check que monitoriza 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 puede verse, 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 de tiempo, reglas de la Consola de eventos, perfiles de usuario, y muchas más.

Por supuesto, eso no significa que no pueda utilizar archivos de texto como configuración. Si aún no conoce la sintaxis exacta para la tarea de configuración que ha elegido, sólo necesita la herramienta adecuada para ello, y a esta herramienta la llamamos Setup:

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

Nota: Cuando se trata de nombres de directorios, archivos o incluso contenidos de archivos, a menudo encontrará 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 reemplazado por Setup en la interfaz web, sigue vivo en el sistema de archivos.

Existe un comando práctico para saber qué fichero acaba de modificar Setup: find. Invocando 'find' con los siguientes parámetros puede encontrar todos los archivos (-type f) bajo etc/ que han sido alterados 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á prevista sólo para alteraciones manuales, 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 otros archivos en "su" directorio .d, si ha 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. Existen dos tipos de archivos:

Los archivos ejecutables pueden ser reconocidos por tener variables que son sustituidas por asignaciones con valores (=). Los otros 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 información sobre la sintaxis de Python, le recomendamos que visite un site especializado, por ejemplo:The Python Language Reference.

Si edita manualmente archivos de configuración en etc/check_mk/, es una buena idea hacer check de la configuración. Puede hacerlo con la herramienta cmk-update-config, que en realidad sólo se ejecuta automáticamente después de una actualización de versión con omd update:

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