 |
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é check propios?
Checkmk ya supervisa muchos tipos de datos relevantes utilizando un gran número de sus propios plugins de comprobación estándar. Sin embargo, cada entorno informático es único, por lo que a menudo pueden surgir requisitos muy especializados. Con las comprobaciones locales tienes la posibilidad de ampliar el agente en el host de destino para crear rápida y fácilmente tus propios servicios.
Estos plugins locales difieren en un aspecto significativo de otros checks: el cálculo de un estado se produce directamente en el host en el que también se recuperan los datos. De este modo, no es necesaria la compleja creación de checks en Python y, por tanto, existe una elección completamente libre del lenguaje de codificación para los scripts.
2. Escribir un simple local check
2.1. Crear el script
Un local check puede escribirse en cualquier lenguaje de programación compatible con el host de destino. El script debe construirse de modo que cada check produzca una línea de estado formada por cuatro partes. He aquí un ejemplo:
0 "My service" myvalue=73 My output text which may contain spacesLas cuatro partes están separadas por espacios en blanco y tienen los siguientes significados:
| Valor de ejemplo | Significado | Descripción |
|---|---|---|
|
Estado |
El estado del servicio se indica con un número: |
|
Nombre del servicio |
El nombre del servicio tal y como se muestra en Checkmk, en la salida del check entre comillas dobles. |
|
Valor y métrica |
Valores métricos de los datos. Encontrarás más información sobre su construcción en el capítulo sobre métricas. Alternativamente, se puede codificar un signo menos si el check no produce ninguna métrica. |
|
Detalle del estado |
Detalles del estado tal y como se mostrarán en Checkmk. Esta parte también puede contener espacios en blanco. |
Siempre debe haber exactamente un espacio (ASCII 0x20) entre las cuatro partes de esta salida. Dentro de los detalles del estado, se pueden utilizar espacios en cualquier orden.
|
Las desviaciones de la especificación que acabamos de describir pueden funcionar, pero no deben. Las futuras versiones de Checkmk pueden imponer este formato de salida e ignorar los checks locales que se desvíen. |
Si no estás seguro de una posible salida, puedes simplemente probarla escribiendo un pequeño script con el comando echo. Inserta la salida que quieras probar en el comando echo. Nuestro ejemplo utiliza comillas dobles en el exterior, ya que las variables del interior (variables del entorno y las establecidas en el script) se evalúan. Como resultado, debes encerrar las comillas para el nombre del servicio con \ para que estos caracteres no sean interpretados por el shell como el final y el principio de una cadena (y, por tanto, eliminados de la salida):
#!/bin/bash
echo "0 \"My 1st service\" - This static service is always OK"Para hosts Windows, un script de este tipo tendrá un aspecto muy similar al siguiente
@echo off
echo 0 "My 1st service" - This static service is always OKAmbos scripts producen el mismo resultado en la salida:
0 "My 1st service" - This static service is always OKPara Checkmk sólo es relevante este resultado, no cómo lo has creado.
Por cierto, puedes escribir cualquier número de salidas en un script. Cada línea de salida tendrá su propio servicio creado en Checkmk. Por lo tanto, no se permiten caracteres de nueva línea en la salida, a menos que estén enmascarados, por ejemplo para una salida de varias líneas en Checkmk.
Cómo se puede comprobar si el script local será invocado correctamente por el agente se puede ver en el Análisis de errores.
|
Si se utiliza el núcleo de Nagios (siempre en Checkmk Raw), no se permiten los siguientes caracteres especiales en el nombre del servicio: |
2.2. Distribuir el script
Una vez escrito el script, puedes distribuirlo a los host adecuados. La ruta utilizada dependerá del sistema operativo. Encontrarás una lista de nombres de rutas en Archivos y directorios más abajo.
No olvides hacer ejecutable el script en sistemas tipo Unix. La ruta mostrada en este ejemplo es para Linux:
root@linux# chmod +x /usr/lib/check_mk_agent/local/mylocalcheckSi utilizas la Agent bakery, el script se puede distribuir con un procedimiento basado en reglas. Encontrarás más información sobre la creación de reglas en el capítulo Distribución a través de la Agent bakery.
2.3. Añadir el servicio a la monitorización
En cada invocación del agente Checkmk también se ejecutará el local check contenido en el script y se añadirá a la salida del agente. El descubrimiento de servicios también funciona automáticamente como con otros servicios:
Una vez añadido el servicio a la monitorización y activados los cambios, se habrá completado la implementación del servicio autocreado con la ayuda de un local check. Si surgiera algún problema durante el descubrimiento de servicios, el Análisis de errores puede ser de ayuda.
3. Funciones ampliadas
3.1. Métricas
Con un script local también se pueden establecer métricas. Para habilitarlas, el valor del check debe devolver siempre P. Entonces el estado será calculado por Checkmk.
La sintaxis general de estos datos es la siguiente
metricname=value;warn;crit;min;maxdonde value es el valor actual, warn y crit fijan los umbrales (superiores), y min y max fijan el rango de valores; por ejemplo, así:
count=73;80;90;0;100Los valores se separan con un punto y coma. Todos los valores, excepto value, son opcionales. Si un valor no es obligatorio, el campo permanece vacío o se omite al final, como en lo que sigue para warn, crit y max:
count=42;;;0Nota: En las ediciones comerciales sí se pueden establecer los valores de min y max, pero sólo por motivos de compatibilidad. Limitar el gráfico asociado a un determinado rango de valores no tiene ningún efecto en las ediciones comerciales.
3.2. Nombre métrico
Debes tener especial cuidado al elegir el identificador de esta métrica -llamada metricname en el ejemplo de aquí-. Recomendamos anteponer los identificadores para evitar solapamientos con métricas ya presentes en Checkmk.
Así, por ejemplo, en lugar de llamar simplemente "actual" a una métrica que representa el número de solicitudes actualmente en espera en una cola que estás monitorizando, te recomendamos un identificador más claro con un prefijo, como : mycompany_current_requests.
Si eligieras aquí un identificador que ya existe en Checkmk, la representación de tus métricas en gráficos se sobrescribiría con las definiciones que ya existen.
Por supuesto, también puedes reutilizar intencionadamente una métrica existente en Checkmk. Así, para una métrica de corriente eléctrica podrías utilizar simplemente el identificadorcurrent en tu local check. En caso de duda, sin embargo, tendrás que buscar tú mismo la definición de esta métrica en ~/lib/python3/cmk/gui/plugins/metric.
OMD[mysite]:~$ grep -r -A 4 'metric_info\["current"\]' ./lib/python3/cmk/gui/plugins/metrics/3.3. Múltiples métricas
También puedes hacer que salgan varias métricas, separadas por el carácter "pipa" |, por ejemplo así:
count1=42|count2=23¡Atención! En host Windows tienes que anteponer un signo de intercalación (^) a la tubería en el script, para que no se interprete.
@echo off
echo 0 "My 2nd service" count1=42^|count2=23 A service with 2 graphsUna salida completa con dos métricas tendrá este aspecto:
root@linux# /usr/lib/check_mk_agent/local/mylocalcheck
0 "My 2nd service" count1=42|count2=23 A service with 2 graphsCuando hayas incluido también el nuevo servicio en la monitorización, verás el texto del detalle del estado en el campo Summary de la lista de servicios. Tras hacer clic en el servicio, aparece la página con los detalles del servicio. Las métricas se muestran en el campo Details y debajo verás los gráficos del servicio generados automáticamente por Checkmk:
3.4. Calcular el estado dinámicamente
En los capítulos anteriores, aprendiste a establecer valores umbrales para las métricas y a mostrarlos en los gráficos. El siguiente paso obvio es utilizar estos umbrales para un cálculo dinámico del estado del servicio. Checkmk proporciona exactamente estas opciones para ampliar un local check.
Si pasas la letra P en lugar de un número en el primer campo de la salida que determina el estado, el estado del servicio se calculará en función del umbral proporcionado.
La salida tendrá entonces este aspecto
root@linux# /usr/lib/check_mk_agent/local/mylocalcheck
P "My 1st dynamic service" count=40;30;50 Result is computed from two threshold values
P "My 2nd dynamic service" - Result is computed with no values... y la visualización en una vista de servicio así:
La visualización difiere en dos puntos de la que vimos antes:
Para los servicios en estado WARN o CRIT, la Summary del servicio muestra toda la información importante sobre la métrica (nombre, valor, umbrales). Esto significa que siempre puedes ver cómo se ha calculado este estado a partir de un valor. Para los demás estados, la información sobre la métrica sólo se muestra en el campo Details.
Si no se ha superado ninguna métrica, el estado del servicio siempre será OK.
3.5. Umbrales superior e inferior
Algunos parámetros no sólo tienen un umbral superior, sino también un umbral inferior. Un ejemplo es la humedad. Para estos casos, el local check tiene la opción de pasar dos valores de umbral cada uno para los estados WARN y CRIT. Están separados por dos puntos y representan el valor de umbral inferior y superior respectivamente.
En la sintaxis general, tiene este aspecto:
metricname=value;warn_lower:warn_upper;crit_lower:crit_upper... y en el ejemplo así:
root@linux# /usr/lib/check_mk_agent/local/mylocalcheck
P "My 3rd service" humidity=37;40:60;30:70 A service with lower and upper thresholds... y en la visualización de una vista de servicio así:
Si sólo te interesan los umbrales inferiores, omite los campos de umbral superior:
root@linux# /usr/lib/check_mk_agent/local/mylocalcheck
P "My 4th dynamic service" count_lower=37;40:;30: A service with lower thresholds onlyCon esta salida, especificas que el servicio se convierta en WARN si el valor es inferior a 40 y en CRIT si es inferior a 30: así, con el valor especificado de 37, el servicio obtendrá el estado WARN.
3.6. Salidas multilínea
También está disponible la opción de distribuir una salida en varias líneas. Como Checkmk se ejecuta en Linux, puedes trabajar con la secuencia de escape '\n' para forzar un salto de línea. Incluso si, debido al lenguaje de script, es necesario escapar la propia barra invertida, Checkmk la interpretará correctamente:
root@linux# /usr/lib/check_mk_agent/local/mylocalcheck
P "My service" humidity=37;40:60;30:70 My service output\nA line with details\nAnother line with detailsEn los detalles del servicio, estas líneas adicionales serán visibles en Summary:
3.7. Ejecución asíncrona y almacenamiento en caché de la salida
La salida de los chequeos locales, al igual que la de los plugins del agente, puede almacenarse en caché. Esto puede ser necesario si un script tiene un tiempo de proceso más largo. Entonces, dicho script se ejecuta de forma asíncrona y sólo en un intervalo de tiempo definido, y la última salida se almacena en caché. Si se vuelve a consultar al agente antes de que expire el tiempo, éste utiliza este caché para el local check y lo devuelve en la salida del agente.
Nota: El almacenamiento en caché sólo está disponible para AIX, FreeBSD, Linux, OpenWrt y Windows.
Configurar Linux
En Linux o en otro sistema operativo tipo Unix, cualquier plugin puede ejecutarse de forma asíncrona. Para un local check, la configuración necesaria es muy similar a la de un plugin. Para ello, crea un subdirectorio llamado el número de segundos que quieres que se almacene en caché la salida y coloca tu script en ese subdirectorio.
En el siguiente ejemplo, el local check se ejecutará sólo cada 10 minutos (600 segundos):
root@linux# /usr/lib/check_mk_agent/local/600/mylocalcheck
2 "My cached service" count=4 Some output of a long running scriptLos datos almacenados en caché se escriben en un directorio de caché.
Para un servicio que proporciona datos en caché, la información específica de la caché se añade a la vista de servicio:
Configuración de Windows
En Windows, la configuración también es análoga a la de un Plugin. En lugar de utilizar un subdirectorio especial como en Linux & Co, las opciones se establecen en un archivo de configuración:
local:
enabled: yes
execution:
- pattern : $CUSTOM_LOCAL_PATH$\mylocalcheck.bat
async : yes
run : yes
cache_age : 600Como puedes ver arriba, en Windows puedes configurar por separado la ejecución asíncrona (con async) y el intervalo de tiempo (con cache_age).
Alternativamente, en Windows también puedes hacer la configuración en el Agent bakery.
4. Distribución a través de la Agent bakery
Si ya utilizas la Agent bakery, también puedes distribuir los scripts con los checks locales a varios host de esta forma.
Para ello, crea primero el directorio custom en el servidor Checkmk como usuario del site debajo de ~/local/share/check_mk/agents/ y en él un árbol de subdirectorios para cada paquete de checks locales:
OMD[mysite]:~$ cd ~/local/share/check_mk/agents
OMD[mysite]:~$ ~/local/share/check_mk/agents$ mkdir -p custom/mycustompackage/lib/local/El directorio del paquete en el ejemplo anterior es mycustompackage. Debajo de él, el directorio lib marca el script como Plugin o como local check. A continuación, el directorio local asigna el archivo explícitamente. Coloca el script con el local check en este directorio.
Importante: En Linux, puedes configurar la ejecución asíncrona de forma análoga a la descrita en el capítulo anterior, creando ahora un directorio en custom/mycustompackage/lib/local/ con el número de segundos del intervalo de ejecución y colocando allí el script. En Windows, puedes utilizar los conjuntos de reglas Set execution mode for plugins and local checks y Set cache age for plugins and local checks. Puedes encontrar estos y otros conjuntos de reglas para los checks locales en Windows en la Agent bakery, en Agent rules > Windows Agent.
En el entorno de configuración de Checkmk, el directorio de paquetes mycustompackage aparecerá como una nueva opción: abre Setup > Agents > Windows, Linux, Solaris, AIX, crea una nueva regla con Agents > Agent rules > Generic options > Deploy custom files with agent y selecciona el paquete recién creado:
A continuación, Checkmk integrará de forma autónoma el local check correctamente en el paquete de instalación para el sistema operativo correspondiente. Una vez activados los cambios y horneado el agente, la configuración estará completa. Ahora sólo hay que distribuir los agentes.
5. Análisis de errores
5.1. Comprobación del script
Si tienes problemas con un script escrito por ti mismo, debes comprobar las siguientes fuentes potenciales de error:
¿Está el script en su directorio correcto?
¿Es ejecutable el script y los permisos de acceso son correctos? Esto es especialmente relevante si no estás ejecutando el agente o el script bajo root o la cuenta LocalSystem.
-
¿Se ajusta la salida a la sintaxis indicada? La salida del local check debe ajustarse a la sintaxis descrita en los capítulos Creación del script y Funciones ampliadas. De lo contrario, no se puede garantizar una ejecución sin errores.
Pueden surgir problemas y errores, en particular, cuando un local check está destinado a realizar una tarea que requiere un check plugin completo, por ejemplo, cuando la salida del propio local check contiene un título de la sección o la definición de un nombre del host, como los que se utilizan al transportar datos piggyback.
 |
En Linux, cuando se llama al script del agente o al plugin directamente en un shell, pueden estar disponibles variables del entorno diferentes que cuando se llama mediante el Controlador de agentes del agente Checkmk. En Windows, el Controlador de agentes también se ejecuta con la cuenta LocalSystem, pero la llamada en el terminal se realiza con un usuario normal o administrador. Además del entorno diferente, esto puede significar que falten permisos. Para poder analizar la salida del script del agente de la forma más parecida posible a las condiciones en las que se llama al agente Checkmk, debes utilizar el Controlador de agentes en modo volcado si es posible. |
5.2. Comprobar la salida del agente en el host de destino
Si el propio script es correcto, se puede ejecutar el agente en el host. En los sistemas operativos tipo Unix, como Linux, BSD, etc., está disponible el comando que se indica a continuación. Con la opción -A se puede especificar el número de líneas adicionales que se mostrarán tras un acierto. Este número se puede personalizar para adaptarlo al número de líneas de salida esperadas:
root@linux# cmk-agent-ctl dump | grep -v grep | grep -A2 "<<<local"
<<<local:sep(0)>>>
P "My service" humidity=37;40:60;30:70 My service output\nA line with details\nAnother line with details
cached(1618580356,600) 2 "My cached service" count=4 Some output of a long running scriptEn la última línea, puedes reconocer un servicio en caché por la información precedente cache con la hora Unix actual y el intervalo de ejecución en segundos.
En Windows, puedes conseguir un resultado muy similar con PowerShell y el "Cmdlet" Select-String que con el comando grep en Linux. En el siguiente comando, los dos dígitos que aparecen tras el parámetro Context determinan cuántas líneas deben salir antes y después del golpe:
PS C:\Program Files (x86)\checkmk\service> ./cmk-agent-ctl.exe dump | Select-String -Pattern "<<<local" -Context 0,3
> <<<local:sep(0)>>>
0 "My 1st service" - This static service is always OK
cached(1618580520,600) 1 "My cached service on Windows" count=4 Some output of a long running script |
Dependiendo del entorno, del lenguaje de programación utilizado, de la versión de Windows y de algunas otras condiciones, en Windows te encuentras a menudo con el juego de caracteres UTF-16. Además, es frecuente encontrar allí la combinación de Retorno de carro y Salto de línea para los saltos de línea. Sin embargo, Checkmk, como aplicación Linux, espera UTF-8 y Saltos de línea simples sin ningún tipo de peros. Nuestro artículo sobre el directorio de spool incluye un capítulo en el que se explica la resolución de problemas relacionados con el juego de caracteres. |
5.3. Probar la salida del agente en el servidor Checkmk
Como último paso, también se puede probar el proceso de la salida del script en el servidor Checkmk con el comando cmk - una vez para el descubrimiento de servicios:
OMD[mysite]:~$ cmk -IIv --detect-plugins=local mycmkserver
Discovering services and host labels on: mycmkserver
mycmkserver:
...
+ EXECUTING DISCOVERY PLUGINS (1)
2 local
SUCCESS - Found 2 services, no host labels... y también el proceso de la salida del servicio con un comando similar:
OMD[mysite]:~$ cmk -nv --detect-plugins=local mycmkserver
Checkmk version 2.0.0p2
+ FETCHING DATA
...
+ PARSE FETCHER RESULTS
Received no piggyback data
My cached service Some output of a long running script(!!), Cache generated 6 minutes 52 seconds ago, Cache interval: 10 minutes 0 seconds, Elapsed cache lifespan: 68.71%
My service My service output\, humidity: 37.00 (warn/crit below 40.00/30.00)(!)Para ambos comandos hemos acortado la salida por líneas no relevantes para este tema.
Si hay errores en un local check, Checkmk los identificará en la salida del servicio. Esto se aplica también a las métricas erróneas, a la información falsa o incompleta en la salida del script, o a un estado inválido. Estos mensajes de error deberían ayudar a identificar rápidamente los errores en un script.
6. Archivos y directorios
6.1. Directorio de script en el host de destino
| Nombre de la ruta | Sistema operativo |
|---|---|
|
AIX |
|
FreeBSD |
|
HP-UX, Linux, OpenBSD, OpenWrt y Solaris |
|
Windows |
6.2. Directorio de caché en el host de destino
Los datos en caché de las distintas secciones, incluida la sección local, se almacenan aquí y se añaden de nuevo al agente con cada ejecución, siempre que los datos sean válidos.
| Nombre de la ruta | Sistema operativo |
|---|---|
|
AIX |
|
FreeBSD |
|
Linux, OpenWrt y Solaris |