 |
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. ¿Por qué la línea de comandos?
Una vez instalado un sistema Checkmk, se puede configurar y manejar al 100 % a través de la interfaz web. Sin embargo, hay situaciones en las que resulta útil adentrarse en las profundidades de la línea de comandos, por ejemplo:
al buscar el origen de los problemas
al automatizar la administración de Checkmk con la API-REST
al programar y probar tus propias extensiones
para poder entender cómo funciona Checkmk internamente
¡si simplemente te gusta trabajar con la línea de comandos!
En este artículo te presentaremos los comandos, archivos y directorios más importantes de Checkmk.
2. El usuario del site
2.1. Inicio de sesión como usuario del site
Al administrar Checkmk, salvo algunas excepciones, nunca tendrás que trabajar como usuario «root».
En este artículo daremos por hecho que has iniciado sesión como usuario del site.
Para ello, haz lo siguiente, por ejemplo:
También es posible realizar un inicio de sesión directo por SSH en un site sin pasar por root.
Dado que el usuario del site es un usuario de Linux «completamente normal», solo tienes que asignarle una contraseña (lo que requiere permisos de root, solo una vez, para la configuración):
Después, debería ser posible realizar el inicio de sesión por SSH directamente desde otro ordenador (los usuarios de Windows deberían usar preferiblemente PuTTY para esto).
Desde Linux, este inicio de sesión se realiza simplemente con el comando ssh:
En el primer inicio de sesión, probablemente recibirás una advertencia sobre una clave de host UNKNOWN.
Cuando estés seguro de que, en ese breve instante, ningún atacante se ha apoderado de la dirección IP de tu sistema operativo, puedes verificarlo simplemente con yes.
También puedes trabajar con la línea de comandos en la Appliance Checkmk. Cómo hacerlo se explica en un artículo aparte.
2.2. Perfil y variables del entorno
Para que surjan el menor número posible de problemas, especialmente como resultado de distribuciones individuales o configuraciones diferentes del sistema operativo, el sistema Checkmk garantiza que el usuario del site —y, del mismo modo, todos los procesos de monitorización— dispongan siempre de 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 estos procesos invocan indirectamente (por ejemplo, los scripts de notificación propios de un usuario).
|
El nombre del site ( |
|
La ruta del directorio del site ( |
|
Directorios en los que se buscarán los programas ejecutables.
Por ejemplo, Checkmk guarda aquí el |
|
Directorios en los que se buscan bibliotecas binarias adicionales. Con esta variable, Checkmk se asegura de que las bibliotecas que vienen con Checkmk tengan prioridad sobre las instaladas en el sistema operativo normal. |
|
Ruta de búsqueda para módulos de Perl. Aquí también, en caso de duda, tienen prioridad las variantes de módulos proporcionadas por Checkmk. |
|
La configuración de idioma para los comandos de línea de comandos.
Esta configuración se adopta de la instalación de Linux.
Esta variable se elimina automáticamente en los procesos del site, ¡y la configuración vuelve al inglés predeterminado!
Esto también afecta a otras configuraciones regionales.
Eliminar |
Con el comando env puedes mostrar todas las variables del entorno; si añades | sort a este comando, la lista se ordena de forma un poco más clara:
En Linux, el entorno es un atributo de un proceso. Cada proceso tiene sus propias variables, que transmite automáticamente a los subprocesos. Estos comienzan inicialmente con las mismas variables heredadas, pero también pueden modificarlas.
Con el comando `env` solo puedes ver 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 solo necesitas el ID del proceso (PID).
Puedes identificarlo con, por ejemplo, ps ax, pstree -p o top.
Con esto, puedes acceder directamente al archivo environ del proceso a través del sistema de archivos /proc.
Aquí tienes, a modo de 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:
# Custom environment variables
#
# Here you can set environment variables. These will
# be set in interactive mode when logging in as site
# user and also when starting the OMD processes with
# omd start.
#
# This file has shell syntax, but without 'export'.
# Better use quotes if your values contain spaces.
#
# Example:
#
# FOO="bar"
# FOO2="With some spaces"
#
MY_SUPER_VAR=blabla123
MY_OTHER_VAR=10.88.112.172.3. Personalización del shell
Si quieres personalizar tu shell (el indicador de comando u otros aspectos), puedes hacerlo como de costumbre en el archivo .bashrc.
No obstante, las variables del entorno pertenecen a ~/etc/environment, por lo 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.
3. La estructura de directorios
3.1. La separación entre software y datos
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.4.0p24.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ísicos reales se encuentran en /opt
, pero todas las rutas de datos en Checkmk siempre utilizan /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/.
3.2. Directorio del site
Como cualquier usuario de Linux, el usuario del site también tiene un directorio de inicio, al que nos referimos como el directorio del site.
Si tu sitio se llama mysite, lo encontrarás en /omd/sites/mysite/.
Como es habitual en Linux, el shell abrevia su propio directorio de inicio con una tilde (~) (o un guion).
Dado que nada más al iniciar el inicio de sesión te encontrarás en este directorio, la tilde aparece automáticamente en el indicador de entrada:
OMD[mysite]:~$Los subdirectorios del directorio del site se muestran en relación con la tilde:
Hay varios subdirectorios dentro del directorio del site; puedes verlos con «ll» (alias de «ls -l»):
Como se puede ver, los directorios bin, include, lib, share y version son enlaces simbólicos.
El resto son directorios «normales».
Esto refleja la separación entre el software y los datos, tal y como se ha explicado anteriormente.
El directorio del software debe ser accesible como un subdirectorio dentro del site,
pero se encuentra físicamente en /omd/versions/, y también puede ser utilizado por otros sitios.
| Software | Datos | |
|---|---|---|
Directorios |
|
|
Propietario |
|
Usuario del site ( |
Creado por |
Instalación de Checkmk |
Creación, configuración y monitorización del sitio |
Ubicación física |
|
|
Tipo de archivo |
Enlaces simbólicos |
Directorios normales |
3.3. Software
Los directorios de software, como es habitual en Linux, pertenecen a root y, por lo tanto, no pueden ser modificados por un usuario del site.
Existen los siguientes subdirectorios; los del ejemplo se encuentran físicamente en /omd/versions/2.4.0p24.cee/ y se puede acceder a ellos a través de enlaces simbólicos desde el directorio del site:
|
Directorio para programas ejecutables.
Aquí se encuentra, por ejemplo, el comando ` |
|
Directorios C, Plugins para Apache y Python —y en el subdirectorio |
|
La parte principal del software instalado.
Hay muchísimos componentes en |
|
Contiene archivos de inclusión para programas en C, que deben vincularse a las bibliotecas de |
El enlace simbólico version es una «parada intermedia» y sirve como punto de retransmisión para la versión que usa el site.
Durante una actualización de software, se switchará de la versión antigua a la nueva.
No obstante, no intentes realizar una actualización manualmente modificando el enlace, ya que una actualización requiere una serie de pasos adicionales que, de lo contrario, fallarán.
3.4. Datos
Los datos reales de un sitio se encuentran en los subdirectorios restantes del directorio del site. Sin excepción, estos pertenecen al usuario del site. El directorio del site en sí también está incluido. Checkmk no almacena nada aparte de los directorios que aparecen ahí. Puedes crear tus propios archivos y directorios sin problema aquí, en los que se pueden guardar pruebas, datos descargados, copias de archivos de registro, etc., según desees.
Se han predefinido los siguientes directorios:
|
Archivos de configuración. |
|
Datos de tiempo de ejecución. |
|
Datos volátiles. |
|
Extensiones propias. |
3.5. Modificar y ampliar Checkmk: los archivos locales
 |
Algunas afirmaciones realizadas en esta sección sobre la prioridad de los archivos locales (específicos del sitio) frente a los archivos con el mismo nombre en el directorio del software ya no son correctas. Actualizaremos las secciones pertinentes en breve. |
Como se acaba de mostrar en la tabla anterior, el directorio ~/local/, con sus numerosos subdirectorios, está destinado a tus propias extensiones.
En un sitio nuevo, todos los directorios de ~/local/ están inicialmente vacíos.
Con el práctico comando «tree» puedes obtener rápidamente una vista general de la estructura de «~/local/».
La opción «-L 3» limita la profundidad a 3:
Todos los directorios del nivel más bajo están integrados 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 sitio en ~/bin/, ~/lib/ o ~/share/).
Ejemplo: En el site, los programas ejecutables se buscarán en ~/bin/ y en ~/local/bin/.
En este caso, si hay nombres idénticos, el archivo de ~/local/ siempre tiene prioridad.
Esto permite modificar el software sin necesidad de cambiar los archivos de instalación en /omd/versions/.
El procedimiento es sencillo:
Copia el archivo deseado en el directorio correspondiente de
~/local/.Modifica este archivo.
Reinicia el servicio correspondiente para que el cambio surta efecto.
En cuanto al punto 3 anterior, si no sabes exactamente a qué servicio se aplica el cambio, simplemente reinicia todo el site con omd restart.
3.6. Archivos de registro
En Checkmk, como ya se ha descrito, los archivos de registro se almacenan en el directorio de datos var/.
Allí se pueden encontrar los archivos de registro de los componentes relevantes.
A continuación se muestra una versión resumida de la salida de una de las ediciones comerciales:
En la interfaz web puedes configurar fácilmente el alcance de los datos que se deben escribir en los archivos de registro
buscando en Setup > General > Global settings todas las entradas con logging:
|
Los archivos de registro pueden llegar a ser muy grandes rápidamente si se ha establecido un nivel de registro alto. Por lo general, es recomendable utilizar estos ajustes para una personalización temporal, como ayuda para identificar problemas, por ejemplo. |
4. El comando cmk
Junto con el comando omd, que sirve para iniciar y detener sitios, para la configuración básica de componentes
y para iniciar una actualización de software, cmk es el comando más importante.
Con él se puede crear una configuración para un core de monitorización, ejecutar checks manualmente, realizar un descubrimiento de servicios y mucho más.
4.1. Las opciones del comando
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 muy detallada, a la que se puede acceder 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 válido para el comando en sí también lo es para sus opciones:
Cuanto menos haya que escribir, más rápido va.
No para todas las opciones, pero para aquellas que se necesitan a menudo, existe por lo tanto un formulario corto además del formulario largo.
Aunque el formulario largo es más intuitivo, especialmente para principiantes (check_mk --list-hosts) que el formulario corto (cmk -l), usaremos el formulario corto en el Manual de usuario.
En caso de duda, siempre puedes consultar la ayuda del comando.
Echar un vistazo más detallado a la ayuda del comando es una buena idea en cualquier caso, 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 te ofrecemos una vista general de las opciones que presentaremos en este capítulo, pero también en otras partes del manual:
| Opción | Función |
|---|---|
Core de monitorización | |
|
|
|
|
|
|
|
|
Checks | |
|
Ejecutar checks en el host |
Servicios | |
|
|
|
Ejecuta la comprobación de descubrimiento en el host, que busca servicios nuevos y desaparecidos, así como nuevas host labels.
Cuando se produce un cambio, el host queda «marcado» mediante la creación de un archivo con el nombre del host en |
Agentes | |
|
|
|
|
Diagnósticos | |
|
|
|
|
|
|
Información | |
|
Muestra la versión de Checkmk instalada en el site. |
|
|
|
|
|
Mostrar la página del manual del check plugin (en este caso, del plugin |
Temas especiales | |
|
Borra la caché de DNS y la vuelve a crear. Para más detalles sobre la caché de DNS, consulta el artículo sobre hosts. Por defecto, este comando se ejecuta en un site de Checkmk una vez al día mediante cronjob. |
|
Elimina todos los datos obsoletos de piggyback del directorio |
|
|
|
Obtener un recorrido SNMP desde el host |
|
|
|
|
En algunos modos, tienes a tu disposición opciones específicas adicionales;
por ejemplo, puedes limitar el descubrimiento de servicios a determinadas comprobaciones, como la comprobación df con el comando cmk -I --detect-plugins=df myserver123.
Hay una serie de opciones que siempre funcionan, independientemente del modo en el que se ejecute el comando:
| Opción | Función |
|---|---|
|
Solicita a |
|
Lo mismo que lo anterior, pero con aún más detalles: «very verbose» |
|
La información se lee de los archivos de caché, incluso si están desactualizados.
Solo se realiza el contacto con el agente si no existe ningún archivo de caché.
Los datos del agente almacenados en caché del host se pueden encontrar en |
|
Funciona como |
|
La información siempre se recupera actualizada, es decir, no se utilizan archivos de caché. |
|
Para hosts SNMP: en lugar de acceder al agente SNMP, esto utiliza un recorrido SNMP almacenado, que se ha obtenido previamente con |
|
Si se produce un error, esta opción garantiza que ya no se interceptará, sino que se mostrará la excepción original de Python en su totalidad.
Esto puede ser información importante para el desarrollador, ya que muestra la ubicación exacta del programa en la que se encuentra el error.
También será muy útil para localizar errores en los check plugins escritos por ti mismo.
Si al invocar |
En la siguiente sección te mostraremos cómo se pueden utilizar los comandos. Los resultados de los ejemplos se muestran en su mayoría de forma abreviada.
4.2. Comandos para el core de monitorización
Las ediciones comerciales utilizan el Checkmk Micro Core (CMC) como núcleo de monitorización, 
Checkmk Community utiliza Nagios.
Una tarea importante del cmk es la generación de un archivo de configuración que sea legible para el núcleo,
y que contenga todos los hosts, servicios, contactos, grupos de contactos, periodos de tiempo, etc. configurados.
A partir de esta información, el núcleo sabe qué comprobaciones debe ejecutar y qué objetos debe proporcionar a la GUI a través de Livestatus.
Tanto para Nagios como para el CMC, es fundamental que el número de hosts, servicios y otros objetos se mantenga siempre estático durante el funcionamiento, y que este número solo pueda modificarse mediante la generación de una nueva configuración, seguida de una recarga del core. Con Nagios, esto requiere reiniciar el core. El CMC cuenta con una función muy eficiente para recargar su configuración durante el proceso activo.
La siguiente tabla destaca las diferencias importantes entre las configuraciones de ambos cores:
| Nagios | CMC | |
|---|---|---|
Archivo de configuración |
|
|
Tipo de archivo |
Archivo de texto con comandos de |
Archivo binario comprimido y optimizado |
Activación |
Reinicio del core |
Comando del core para recargar la configuración |
Comando |
|
|
Siempre es necesario regenerar la configuración
si se ha modificado el contenido de los archivos 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 dichos cambios y los resalta en la GUI como cambios pendientes de activación.
Los siguientes comandos están disponibles para la activación a través de la línea de comandos:
| Opción | Función |
|---|---|
|
Genera una nueva configuración para el core y reinicia el core (análogo a |
|
Genera la configuración para el core y la carga sin reiniciar el procesamiento activo (análogo a |
|
Genera la configuración para el core sin activarla. |
|
Con fines de diagnóstico, esto muestra la configuración que se va a generar en la salida estándar, sin alterar el archivo de configuración real.
Aquí puedes introducir el nombre del host simplemente para ver la configuración del host (p. ej., |
4.3. Ejecución de checks
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 de inmediato, sin tener que preocuparte por el core de monitorización ni por la GUI.
Para ello, introduce cmk --check seguido del nombre del host configurado en la monitorización.
Dado que la opción --check es la opción predeterminada de cmk, también puedes omitirla.
Además, siempre debes añadir las dos opciones -n (no enviar resultados al core) y -v (mostrar todos los resultados).
Más información al respecto en la descripción de las opciones a continuación.
Más consejos:
No uses este comando en hosts de producción supervisados que utilicen la monitorización de archivos de registro. Los mensajes de registro solo se envían una vez por los agentes, y puede ocurrir que un comando manual «
cmk -nv» los «capture» y que, por lo tanto, se pierdan de la monitorización. En tal situación, utiliza la opción «--no-tcp».Si se utiliza Nagios para el core y se omite
-n, el efecto será una actualización inmediata de los resultados de la check en el core y en la GUI.El comando es útil cuando desarrollas tus propios check plugins, ya que permite realizar una prueba más rápida que utilizando la GUI. Si la comprobación falla y devuelve un UNKNOWN, la opción
--debugpuede ayudar a localizar el problema en el código.
Las siguientes opciones influyen en el comando:
| Opción | Función |
|---|---|
|
Salida de los resultados del check: Sin esta opción, solo verás la salida del propio servicio «Check_MK», y no los resultados de los demás servicios. |
|
Simulación: Los resultados no se pasan al core, el contador de rendimiento no se actualiza. |
|
Restringe la ejecución a los check plugins |
4.4. Recuperación de la salida del agente
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 manera que con la monitorización. No se validan ni se procesan.
Por lo tanto, los datos mostrados coinciden exactamente con los datos que se envían al Controlador de agentes (cuando el cifrado TLS está habilitado) o a un programa de túnel en caso de que se hayan configurado programas de origen 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án los ajustes heredados para el host (conexión TCP al puerto 6556, sin Controlador de agentes, sin cifrado, sin programa de origen de datos).
4.5. Instalación de agentes
En las ediciones comerciales también puedes hornear los agentes desde la línea de comandos, tal y como lo 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 instalar los agentes, utiliza la opción «-A» seguida del nombre del host (o varios):
El resultado muestra que los paquetes del agente disponibles para el host myserver123 se han actualizado correctamente.
Si no especificas un host, los paquetes se actualizarán para todos los hosts.
El comando solo se ejecuta cuando es necesario. Si los paquetes siguen estando actualizados, la salida tendrá un aspecto similar a este:
Aún puedes forzar la compilación con la opción -f (force).
4.6. Lista de hosts
El comando «cmk -l» simplemente muestra la lista de los nombres de todos los hosts configurados en el archivo «Setup»:
Como los datos se proporcionan «sin formato» y «sin procesar», es fácil usarlos en scripts – por ejemplo, se puede crear un bucle que recorra todos los nombres del host:
Si, en lugar de echo, introduce un comando que haga algo útil, esto puede ser realmente práctico.
La llamada a cmk --list-tag también muestra los nombres de los hosts, pero además ofrece la posibilidad de filtrar por tags del host.
Solo tienes que introducir un tag del host y obtendrás todos los hosts que tengan ese tag.
El siguiente ejemplo muestra la lista de todos los hosts sometidos a la monitorización por SNMP:
Introduce varias etiquetas y se enlazarán con «AND». El siguiente comando muestra todos los hosts supervisados tanto por SNMP como por el agente Checkmk. Como ningún host cumple esta condición, la salida permanece vacía:
4.7. Visualización de la configuración del host
Para uno o más hosts especificados, cmk -D muestra los servicios configurados, los tags del host, las etiquetas y otros atributos.
Como la lista de servicios es tan extensa, puede parecer algo confusa en el terminal.
Envía el resultado a través de less -S para evitar que se corte:
4.8. Información sobre los check plugins
Checkmk ofrece de serie un gran número de check plugins listos para usar.
En cada versión se añaden algunos nuevos, y la versión 2.4.0 ya incluye más de 2000 plugins.
Tres opciones del comando cmk te permiten acceder a información sobre estos plugins.
cmk -L genera una lista con todos los Plugins, incluyendo su nombre, tipo y una descripción.
Al mismo tiempo, también se mostrarán los Plugins que hayas escrito tú mismo y que estén guardados en ~/local/.
Los siguientes son los tipos posibles:
|
Evalúa datos de plugins de agente o agentes especiales. El agente se recupera (normalmente) a través del puerto TCP 6556. |
|
Se encarga de la monitorización de dispositivos a través de SNMP. |
|
Llama a una comprobación activa. Esto incluye Plugins de terceros compatibles con Nagios para los que Checkmk solo adopta la configuración. |
Por supuesto, la lista se puede filtrar fácilmente con grep si buscas algo específico:
Si quieres más información sobre un Plugin concreto, puedes consultar la documentación en forma de página de manual con cmk -M:
Esto genera el siguiente resultado:
Si usas cmk -m sin más opciones, accederás a un catálogo completo de todas las páginas de manual de los check plugins.
Puedes navegar de forma interactiva por este catálogo:
5. Archivos de configuración
Conocer la ubicación y la estructura de los archivos de configuración suele ayudar a resolver problemas e identificar errores, por ejemplo, en extensiones descargadas de Checkmk Exchange o programadas por uno mismo.
La comparación entre Setup y los archivos de configuración de este capítulo no pretende fomentar la modificación de los archivos de configuración mediante scripts. Si es necesario automatizar los cambios de configuración, esto se puede hacer de forma segura y sin efectos secundarios utilizando la API-REST.
|
No realices ningún cambio en los archivos de configuración a menos que un representante del soporte técnico de Checkmk te lo haya indicado explícitamente, porque… ¡Hay peligros! |
5.1. ¿Dónde está la documentación?
Aquí no. Los archivos de configuración los definen los componentes que los escriben y leen. En última instancia, solo mirando el código fuente y las pruebas asociadas se puede descubrir la estructura de la configuración almacenada en el sistema de archivos.
Ten en cuenta también que los formatos de los archivos de configuración pueden cambiar entre versiones de parche. En este caso, las rutinas de migración garantizan la conversión de los formatos de datos modificados.
Además, las unidades utilizadas pueden diferir entre la visualización en la interfaz de usuario (Setup) y el almacenamiento en el archivo de configuración. Esto se aplica, por ejemplo, a la visualización de intervalos de tiempo o temperaturas.
El siguiente ejemplo muestra un conjunto completo de parámetros para el check plugin que realiza la monitorización de los sistemas de archivos en Checkmk (aquí en una versión anterior). Debido al gran número de parámetros, la captura de pantalla se ha dividido en dos partes y se ha configurado con una fuente pequeña:
La sección correspondiente en el archivo de configuración real tiene este aspecto (formateada de forma un poco más ordenada):
{ 'inodes_levels' : (10.0, 5.0),
'levels' : (80.0, 90.0),
'levels_low' : (50.0, 60.0),
'magic' : 0.8,
'magic_normsize' : 20,
'show_inodes' : 'onlow',
'show_levels' : 'onmagic',
'show_reserved' : True,
'subtract_reserved' : False,
'trend_mb' : (100, 200),
'trend_perc' : (5.0, 10.0),
'trend_perfdata' : True,
'trend_range' : 24,
'trend_showtimeleft' : True,
'trend_timeleft' : (12, 6)},Como se puede ver, aquí hay más de 10 parámetros diferentes, cada uno de los cuales sigue su propia lógica.
Algunos se configuran utilizando números de coma flotante (0.8), otros utilizando números enteros (24), algunos utilizando palabras clave ('onlow'), otros utilizando valores booleanos (True) y, por último, algunos utilizando tuplas como ((5.0, 10.0)).
Este ejemplo muestra solo uno de los más de 2000 Plugins. Además, Checkmk reconoce otras configuraciones como parámetros de check: piensa, por ejemplo, en intervalos de tiempo, reglas de la Consola de eventos, perfiles de usuario y mucho más.
|
En lo que respecta a los nombres de los directorios de archivos, los archivos o incluso el contenido de los archivos, a menudo encontrarás la abreviatura |
5.2. ¿Qué archivo de configuración se está utilizando actualmente?
Hay un comando muy útil para averiguar qué archivo acaba de cambiar Setup: find.
Si lo ejecutas con los siguientes parámetros, encontrarás todos los archivos (-type f) en ~/etc/ que se han modificado en el último minuto (-mmin -1):
La base de la configuración es siempre el directorio ~/etc/check_mk/.
Este se divide en varios dominios, la mayoría de los cuales se refieren a una funcionalidad específica.
Cada dominio tiene un directorio que termina en .d, desde el cual se leen automáticamente todos los archivos que terminan en .mk en orden alfanumérico.
5.3. Archivos de instalación y configuración
Dentro de los directorios de configuración de .d/, siempre hay un subdirectorio llamado wato, por ejemplo, ~/etc/check_mk/conf.d/wato/.
El Setup normalmente solo lee y escribe en este directorio.
Sin embargo, el servicio responsable del directorio de configuración también lee los demás archivos de su «propio» directorio .d.
Si hay archivos fuera del directorio wato/, o bien se crearon manualmente en algún momento con el objetivo de realizar cambios que son efectivos pero no visibles en el Setup, o bien los crearon otros componentes de Checkmk.
Archivos y carpetas bloqueados
Varios mecanismos de automatización que funcionan dentro de Checkmk o acceden a Checkmk desde fuera (por ejemplo, a través de la API-REST) pueden realizar cambios de configuración. En algunos casos, es deseable que los hosts y las carpetas creados de esta manera sean visibles y verificables en Setup, pero no es deseable que los usuarios «humanos» realicen cambios. En tales casos, se pueden bloquear los hosts o las carpetas.
Puedes reconocer un archivo de hosts.mk de un host bloqueado por la línea con el atributo «lock»:
# Created by WATO
# encoding: utf-8
_lock = True
Al abrir una carpeta de este tipo en el Setup, aparecerá el siguiente mensaje encima de la lista de hosts:
Todas las acciones que requieran un cambio en el archivo hosts.mk quedan entonces bloqueadas en la GUI.
Por cierto, esto no afecta al descubrimiento de servicios.
Los servicios configurados de un host se almacenan en ~/var/check_mk/autochecks/.
Las propiedades de las carpetas también se pueden bloquear.
Esto se hace mediante una entrada en el archivo .wato de la carpeta. En el diccionario del archivo, la clave lock tendrá entonces el valor True:
{'title': 'My folder',
'attributes': {},
'num_hosts': 1,
'lock': True,
'lock_subfolders': False,
'__id': '7f2a8906d3c3448fac8a379e2d1cec0e'}Si el valor de la clave lock_subfolders se establece en True, se impide la creación y eliminación de subcarpetas.
5.4. Contenido y sintaxis de los archivos
Los archivos de configuración pueden ser archivos de texto que se pueden ver en cualquier editor, o archivos binarios que requieren herramientas especiales. Los archivos de texto siguen la sintaxis de Python, pero hay diferencias en cómo los maneja Checkmk:
Los archivos que contienen asignaciones de variables (
=) se ejecutan como un script, p. ej.,hosts.mk.Los archivos que solo contienen valores simples o diccionarios de Python se leen como variables, p. ej.,
.wato.
Siempre se utiliza UTF-8 para la codificación de caracteres. Si necesitas realizar modificaciones por cualquier motivo, asegúrate de que el archivo modificado siga pudiendo ser analizado por Python.
Los archivos binarios tienen la extensión .pb, que significa Protocol Buffers y a veces también se denomina Protobuf.
Este formato, desarrollado por Google para serializar configuraciones y mensajes, se puede escribir y leer con una sobrecarga mínima.
Sin embargo, se necesitan herramientas especiales para verlo.
El paquete Checkmk incluye protoc, que realiza muchas tareas sencillas.
Por ejemplo, lo siguiente ofrece una visión «en bruto» del último estado de un CMC detenido:
Para un análisis más detallado de los archivos Protobuf, puedes usar protoscope.
5.5. Comprobación de los archivos de configuración
Si sospechas que los archivos de configuración pueden estar dañados (por ejemplo, debido a un soporte de datos defectuoso), puedes hacer que los checken.
Checkmk proporciona el programa cmk-validate-config para este fin, que, a diferencia de cmk-update-config, que se ejecuta durante una actualización de software, no realiza ningún cambio, como la migración de formatos de datos.
cmk-validate-configcomprueba tanto la sintaxis (paréntesis, asignaciones correctas, etc.) como, en parte, la semántica (tipos de datos utilizados y la presencia de ciertas claves). Si el programa encuentra errores de sintaxis, se mostrará el primer archivo dañado:
Si los archivos checkados están OK, se mostrará una lista de todos los archivos examinados: