 |
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-ins propios?
Checkmk ya monitoriza muchos tipos de datos relevantes utilizando un gran número de sus propios check plugins estándar. Sin embargo, cada entorno de TI es único, por lo que a menudo pueden surgir requisitos muy especializados. Con los local check tiene la posibilidad de ampliar el agente en el host de destino para crear sus propios servicios de forma rápida y sencilla.
Estos local check plugins 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 esta forma no es necesaria la compleja creación de checks en Python y existe así una elección completamente libre del lenguaje de codificación para los scripts.
2. Escribir un simple local check
2.1. Creación del script
Un local check puede escribirse en cualquier lenguaje de programación soportado por el host de destino. El script debe construirse de forma que cada check produzca una línea de estado que conste de 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 el siguiente significado:
| Valor de ejemplo | Significado | Descripción |
|---|---|---|
|
Estado |
El estado de 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á más información sobre la 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 entre las cuatro partes de esta salida. Dentro de los detalles de estado se pueden utilizar espacios a voluntad.
Si no está seguro de una posible salida, puede probarla escribiendo un pequeño script con el comando echo. Inserte la salida que desea probar en el comando echo. Asegúrese de enmascarar las comillas del nombre del servicio con \ para que el comando echo no interprete estos caracteres:
#!/bin/bash
echo "0 \"My 1st service\" - This static service is always OK"Para hosts Windows, dicho script tendrá un aspecto muy similar al siguiente:
@echo off
echo 0 "My 1st service" - This static service is always OKAmbos scripts dan 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 ha creado.
Por cierto, puede 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.
En el Análisis de errores se explica cómo comprobar si el agente invocará correctamente el script local.
2.2. Distribución del script
Una vez escrito el script, puede distribuirse a los hosts apropiados. La ruta utilizada dependerá del sistema operativo. Puede encontrar una lista de nombres de rutas en Archivos y directorios más abajo.
No olvide hacer el script ejecutable en sistemas tipo de Unix. La ruta mostrada en este ejemplo es para Linux:
root@linux# chmod +x /usr/lib/check_mk_agent/local/mylocalcheckSi utiliza Agent bakery, el script puede distribuirse con un procedimiento basado en reglas. Encontrará más información sobre la creación de reglas en el capítulo Distribución a través de Agent bakery.
2.3. Añadir el servicio a la monitorización
En cada invocación del agente Checkmk el local check contenido en el script también será ejecutado y anexado 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étrica
Con un script local también se pueden establecer métricas. Para habilitarlas, el valor del check debe devolver siempre P. A continuación, Checkmk calculará el estado.
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 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 los siguientes casos para warn, crit y max:
count=42;;;0Nota: En las ediciones comerciales, los valores de min y max sí pueden establecerse, pero sólo por razones de compatibilidad. La limitación del gráfico asociado a un determinado rango de valores no tiene ningún efecto en las ediciones comerciales.
3.2. Nombre de la métrica
Debe tener especial cuidado a la hora de 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 en espera en una cola que está monitorizando, recomendamos un identificador más claro con un prefijo, como : mycompany_current_requests.
Si eligiera aquí un identificador que ya existe en Checkmk, la representación de sus métricas en gráficos se sobrescribiría con las definiciones que ya existen.
Por supuesto, también puede reutilizar intencionadamente una métrica existente en Checkmk. Así, para una métrica de corriente eléctrica podría utilizar simplemente el identificadorcurrent en su local check. En caso de duda, sin embargo, tendrá que buscar la definición de esta métrica en ~/lib/python3/cmk/gui/plugins/metric por sí mismo.
OMD[mysite]:~$ grep -r -A 4 'metric_info\["current"\]' ./lib/python3/cmk/gui/plugins/metrics/3.3. Múltiples métricas
También puede tener varias métricas de salida, separadas por el carácter 'pipa' |, por ejemplo, así:
count1=42|count2=23Atención: En hosts Windows debe 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 graphsDespués de incluir el nuevo servicio en la monitorización, verá el texto para el detalle del estado en el campo Summary en la lista de servicios. Después de pulsar sobre el servicio, se muestra la página con los detalles del servicio. Las métricas se muestran en el campo Details y debajo verá los gráficos del servicio generados automáticamente por Checkmk:
3.4. Calcular el estado dinámicamente
En los capítulos anteriores, aprendió 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 pasa 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.
Una 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 anteriormente:
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 se puede ver cómo se ha calculado este estado a partir de un valor. Para el resto de 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 será siempre 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, se ve así:
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 le interesan los umbrales inferiores, omita 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, se especifica que el servicio debe convertirse en WARN si el valor es inferior a 40 y en CRIT si es inferior a 30: así, en 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, puede 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 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. Dicho script se ejecuta entonces de forma asíncrona y sólo en un intervalo de tiempo definido y la última salida se almacena en caché. Si el agente es consultado de nuevo antes de que expire el tiempo, 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.
Configuración de Linux
En Linux u otro sistema operativo de tipo de 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, cree un subdirectorio llamado el número de segundos que desea que se almacene en caché la salida y coloque su 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 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 puede ver arriba, en Windows puede configurar la ejecución asíncrona (con async) y el intervalo de tiempo (con cache_age) por separado.
Alternativamente, en Windows también puede hacer la configuración en el Agent bakery.
4. Distribución a través de la Agent bakery
Si ya está utilizando la Agent bakery, también puede distribuir los script con local check a varios host de esta forma.
Para ello, cree primero el directorio custom en el servidor Checkmk como usuario del site bajo ~/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, el directorio lib marca el script como Plugin o como local check. El directorio local posterior asigna entonces el archivo explícitamente. Coloque el script con el local check en este directorio.
Importante: En Linux, puede 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, puede utilizar los conjuntos de reglas Set execution mode for plugins and local checks y Set cache age for plugins and local checks. Estos y otros conjuntos de reglas para los locales check bajo Windows se pueden encontrar en el Agent bakery bajo Agent rules > Windows Agent.
En el entorno de configuración de Checkmk, el directorio de paquetes mycustompackage se mostrará como una nueva opción: abra Setup > Agents > Windows, Linux, Solaris, AIX, cree una nueva regla con Agents > Agent rules > Generic options > Deploy custom files with agent y seleccione el paquete recién creado:
Checkmk integrará entonces 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 falta distribuir los agentes.
5. Análisis de errores
5.1. Prueba del script
Si tienes problemas con un script escrito por ti mismo, deberías chequear las siguientes fuentes potenciales de error:
¿Se encuentra el script en el directorio correcto?
¿Es ejecutable el script y los permisos de acceso son correctos? Esto es especialmente relevante si está ejecutando el agente o script y no es el usuario root/Sistema.
-
¿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.
Los problemas y errores pueden surgir 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 el utilizado cuando se transportan datos piggyback.
5.2. Comprobación de la salida del agente en el host de destino
Si el script en sí es correcto, se puede ejecutar el agente en el host. Con sistemas operativos de tipo Unix como Linux, BSD, etc., se dispone del comando que se muestra 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, se puede reconocer un servicio caché por la información precedente cache con la hora Unix actual y el intervalo de ejecución en segundos.
En Windows, puede 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 detrás del 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 script5.3. 5.3. Comprobación de la salida del agente en el servidor Checkmk
Como último paso, el proceso de la salida del script también puede probarse 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 métricas erróneas, a 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 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 secciones individuales, 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 |
