 |
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é molestarse en crear tus propias comprobaciones?
Gracias a la gran cantidad de check plugins que vienen de serie, Checkmk ya puede supervisar una gran cantidad de datos relevantes. Sin embargo, cada entorno TI es único, por lo que a menudo surgen requisitos muy específicos. Con las local checks, puedes crear tus propios servicios de forma rápida y sencilla realizando pequeñas ampliaciones al agente en el host de destino.
Estos plugins locales se diferencian de otras comprobaciones en un aspecto importante: Su estado se determina directamente en el host en el que se recogen los datos.
Esto elimina la necesidad de crear checks con Python y te da total libertad para elegir el lenguaje de scripting. Los local checks también ofrecen una gran libertad a los administradores de servidores. Los administradores de monitorización solo tienen que decidir si incluir nuevas comprobaciones locales como servicios.
 |
Puedes combinar el mecanismo que ofrecen las local checks con todos los métodos que admite Checkmk para transportar datos del agente: programas de origen de datos, agentes especiales, datos piggyback y archivos spool. Los datos de todas las fuentes se agrupan, pero se producirán conflictos si el nombre del servicio se asigna (sin querer) dos veces; por este motivo, asegúrate de que los nombres de cada servicio sean únicos. |
2. Cómo escribir un local check sencillo
2.1. Crear el script
Una local check se puede escribir en cualquier lenguaje de programación compatible con el host de destino. El script debe estar estructurado de manera que cada check genere una línea de estado compuesta por cuatro partes. Aquí tienes un ejemplo:
0 "My service" myvalue=73 My output text which may contain spacesLas cuatro partes están separadas por espacios 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 aparece en Checkmk, en la salida de la check entre comillas dobles. |
|
Valor y métricas |
Valores de métricas para los datos. Encontrarás más información sobre la estructura en el capítulo sobre métricas. También se puede introducir un signo menos si la check no genera métricas. |
|
Detalles del estado |
Detalles del estado tal y como se mostrarán en Checkmk en el campo «Summary». Esta parte también puede contener espacios en blanco. |
|
Hasta Checkmk 2.4.0 p4, siempre debe haber exactamente un espacio ( |
Si no estás seguro de un posible resultado, puedes probarlo simplemente escribiendo un pequeño script con el comando echo.
Inserta el resultado que quieres probar en el comando echo.
Nuestro ejemplo utiliza comillas dobles en el exterior, ya que las variables del interior (variables del entorno y las definidas en el script) se evalúan.
Por lo tanto, debes encerrar las comillas del nombre del servicio entre \ para que el shell no interprete estos caracteres como el inicio y el final de una cadena (y, por lo tanto, los elimine de la salida):
En hosts Windows, un script así tendrá un aspecto muy similar a este:
@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 solo es relevante esta salida, no cómo la has creado.
Por cierto, puedes escribir tantas salidas como quieras 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 puedes ver cómo se puede checkear si el agente invocará correctamente el script local.
|
Si se utiliza el núcleo de Nagios (siempre en Checkmk Community), no se permiten los siguientes caracteres especiales en el nombre del servicio
:
|
2.2. Distribución del script
Una vez escrito el script, se puede distribuir a los hosts correspondientes. La ruta utilizada dependerá del sistema operativo. Encontrarás una lista de nombres de rutas en «Archivos y directorios» más abajo.
No te olvides de hacer que el script sea ejecutable en sistemas tipo Unix. La ruta que se muestra en este ejemplo es para Linux (paquete del agente con la configuración predeterminada):
Si utilizas Agent bakery, el script se puede distribuir mediante 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 Agent bakery».
2.3. Añadir el servicio a la monitorización
Cada vez que se ejecute el 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, al igual que con otros servicios:
Una vez que el servicio se haya añadido a la monitorización y se hayan activado los cambios, la implementación del servicio creado por ti mismo con la ayuda de una local check habrá finalizado. Si surge algún problema durante el descubrimiento de servicios, el análisis de errores puede ser de ayuda.
3. Métricas
3.1. Definición de métricas
También puedes definir métricas en una local check. La sintaxis más breve posible para los datos de métricas es:
metricname=valuedonde value es el valor actual.
La sintaxis completa para los datos métricos es:
metricname=value;warn;crit;min;maxAquí, warn y crit definen los valores umbral (superiores).
Para que estos valores umbral se muestren en el gráfico, debe activarse el cálculo dinámico (estado P).
El estado se calcula entonces utilizando Checkmk.
Los últimos parámetros especificados para min y max fijan el rango de valores.
Un ejemplo completo podría tener este aspecto:
count=73;80;90;0;100Los valores se separan con punto y coma.
Si no se necesita un valor, el campo se deja vacío o se omite al final, como en los siguientes casos para warn, crit y max:
count=42;;;0 |
En las ediciones comerciales
se pueden definir los valores para |
3.2. Nombres y unidades utilizados por las métricas
Las definiciones de métricas para local checks no difieren de las definiciones de métricas para otros tipos de checks. En definitiva, tienes tres opciones para asignar unidades y nombres fáciles de entender a las métricas:
Accedes a definiciones de métricas existentes que «se ajustan» al propósito requerido.
Creas tus propias métricas de forma ad hoc y única; esto suele ser suficiente para los contadores puros.
Crear tus propias métricas y guardar una definición de métrica: esto te ofrece la mayor flexibilidad.
Uso de definiciones de métricas existentes
La forma más fácil de obtener unidades adecuadas, una leyenda ajustada automáticamente y, a menudo, un Perf-O-Meter es utilizar definiciones de métricas existentes.
En este artículo, algunos ejemplos utilizan los identificadores humidity o temperature.
Existen definiciones de métricas predefinidas para ambos (humedad y temperatura), que proporcionan a las métricas las unidades correctas.
En ambos casos, la definición de la métrica proporciona un Perf-O-Meter y las leyendas de los gráficos muestran entonces grados Celsius y humedad relativa en porcentaje.
Las definiciones de métricas más importantes se pueden encontrar en ~/lib/python3/cmk/plugins/collection/graphing (GitHub), otras en ~/lib/python3/cmk/plugins/*/graphing (GitHub) y las unidades utilizadas en ~/lib/python3/cmk/gui/plugins/metrics/unit.py (GitHub).
A menudo merece la pena buscar definiciones de métricas con concordancia exacta, ya que Checkmk también ofrece gráficos combinados para métricas relacionadas.
Definición de métricas ad hoc
En los primeros ejemplos mostrados en este artículo para las métricas, usamos nombres como myvalue, count o metricname.
Sin una definición de métrica adecuada, a estos se les asigna una letra mayúscula inicial en la leyenda del gráfico y los guiones bajos se sustituyen por espacios.
Así, outgoing_queue_size se convierte en el fácilmente legible Outgoing queue size.
Dado que un contador puro no requiere una unidad, el identificador seleccionado de forma sensata ya cumple su propósito aquí sin necesidad de una definición métrica adicional.
Si realmente se requieren unidades, es posible que tengas que incluirlas en el nombre.
El problema surge si el intento de definir una métrica ad hoc tiene inadvertidamente el efecto explicado en la sección anterior y asigna una definición de métrica ya existente.
La confusión puede ser máxima especialmente cuando hay coincidencia entre las unidades; por ejemplo, una métrica proporcionada utiliza una escala porcentual con números de coma flotante entre 0 y 100 %, pero el rango de valores de tu local check proporciona un número sin límite como número de coma fija.
O tienes una cola de solicitudes actuales (Current requests queue), a la que simplemente quieres llamar «current»: el resultado sería la asignación de la definición de métrica para la intensidad de corriente.
Por lo tanto, «current_requests_queue» sería una opción mucho mejor en este caso.
Puedes estar completamente seguro con un prefijo adicional, por ejemplo: «mycompany_current_requests_queue».
Escribir tus propias definiciones de métricas
Si tienes requisitos especiales, por ejemplo, si necesitas gráficos con una leyenda y un Perf-O-Meter, necesitarás tus propias definiciones de métricas. Lee el capítulo sobre métricas en el artículo sobre la programación de check plugins basados en agentes
3.3. Múltiples métricas
También puedes generar múltiples métricas.
En las definiciones, estas se separan con el carácter «barra vertical» (|), por ejemplo, así:
count1=42|count2=23En hosts Windows, debes anteponer a estas barras verticales en el script un acento circunflejo (^) para que estas barras también aparezcan en la salida:
@echo off
echo 0 "My 2nd service" count1=42^|count2=23 A service with 2 graphsUna salida completa con dos métricas tendrá entonces un aspecto similar a este:
Una vez que también hayas añadido el nuevo servicio a la monitorización, en la lista de servicios verás el texto con los detalles del estado en el campo «Summary». Al hacer clic en el servicio, se mostrará la página con sus detalles. Las métricas se muestran en el campo «Details», y debajo verás los gráficos del servicio que Checkmk genera automáticamente:
|
Este ejemplo utiliza una evaluación en el host ( |
3.4. Cálculo dinámico del estado
En las secciones anteriores, has aprendido a proporcionar valores para las métricas y a utilizarlos para generar gráficos. El siguiente paso lógico es ahora utilizar los valores de umbral pasados adicionalmente para un cálculo dinámico del estado del servicio. Esto es exactamente lo que permite Checkmk para que la preparación de los datos recibidos sea coherente con muchos de los estados generados a través de los Plugins.
Si en el primer campo de la salida, que determina el estado, pasas la letra P en lugar de un número, el estado del servicio se calculará basándose en los valores umbral que se hayan pasado.
Además del valor real, los valores umbral transferidos se muestran entonces también como una línea amarilla y roja en el gráfico.
|
Este cálculo dinámico no significa que se puedan modificar los valores umbral a través de las reglas de monitorización definidas en Checkmk. Para el cálculo real siempre se utilizan los valores umbral proporcionados en la local check. |
El resultado sería entonces el siguiente:
… y la visualización en una vista de servicio como esta:
Esta visualización difiere de la anterior en dos aspectos:
Para los servicios en estado «WARN» o «CRIT», la vista «Summary» del servicio muestra toda la información importante de las métricas (nombre, valor, umbrales). Esto significa que siempre puedes ver cómo se calculó este estado a partir de un valor. Para todos los demás estados, la información de las métricas solo se muestra en el campo «Details».
Si no se transfieren métricas, el estado del servicio siempre será «OK».
Alternar entre la evaluación de estado dinámica y estática
Puede ser útil alternar entre la evaluación dinámica y estática del estado en el script que realiza la local check.
Como ejemplo, tomemos un script de copia de seguridad que escribe un archivo spool en el formato de una local check.
La evaluación del estado según la duración de la copia de seguridad debería ser dinámica, por lo que el script debería escribir un «P»:
P "Backup stuff" duration=2342;1800;3600 Successfully created the backup. Good luck restoring.Sin embargo, si la copia de seguridad falla al poco tiempo, el estado viene determinado por el valor de retorno del script de copia de seguridad y no por los valores umbral. En este caso, el script debe establecer el estado de forma estática con un número:
2 "Backup stuff" duration=123;1800;3600 Backup failed. Nuff said.En este caso, simplemente tiene sentido que no se muestren valores umbral en el gráfico, ya que no se trata de la duración requerida hasta la copia de seguridad (fallida), sino del hecho de que la copia de seguridad no se realizó correctamente.
3.5. Valores umbrais superiores e inferiores
Algunos parámetros no solo tienen umbrales superiores, sino también inferiores. Un ejemplo de esto es el registro de humedad. Para estos casos, la local check ofrece la opción de pasar dos valores umbral para cada uno de los estados «WARN» y «CRIT». Estos se separan con dos puntos y representan los valores umbral inferior y superior, respectivamente.
En la sintaxis general queda así:
metricname=value;warn_lower:warn_upper;crit_lower:crit_upper… en el ejemplo como este:
… y en la visualización de una vista de tabla de servicio así:
Si solo te interesan los valores de umbral inferior, omite los campos de los valores de umbral superior:
Con esta salida, especificas que el servicio debe pasar a estar «WARN» si el valor es inferior a 40 y «CRIT» si es inferior a 30: por lo tanto, el servicio recibirá el estado «WARN» si el valor especificado es 37.
|
El sistema de métricas y gráficos de Checkmk se limita a los umbrales superiores por motivos de simplicidad. Esto significa que, aunque la determinación del estado de un servicio funciona como se espera, la información mostrada en el componente de métricas y gráficos ignora los umbrales inferiores. Por este motivo, elementos como las líneas amarillas y rojas en los gráficos, los Perf-O-Meters y los «Service performance data» no aparecen en la GUI de Checkmk cuando solo se utilizan umbrales inferiores. |
3.6. Salidas de varias líneas
También está disponible la opción de distribuir una salida en varias líneas.
Como Checkmk se ejecuta en Linux, puedes utilizar la secuencia de escape '\n' para forzar un salto de línea.
Aunque debido al lenguaje de scripting sea necesario escapar la barra invertida, Checkmk la interpretará correctamente:
En los detalles del servicio, estas líneas adicionales serán visibles bajo el Summary:
4. Ejecución asíncrona
Los resultados de las comprobaciones locales, al igual que los de los plugins de agente, se pueden almacenar en caché. Esto puede ser necesario si un script tarda más tiempo en procesarse. En ese caso, el script se ejecuta de forma asíncrona y solo en un intervalo de tiempo definido, y se almacena en caché el último resultado. Si se vuelve a consultar al agente antes de que expire el tiempo, este utiliza esta caché para la local check y la devuelve en la salida del agente.
|
La caché solo está disponible para AIX, FreeBSD, Linux, OpenWrt y Windows. En otras plataformas, usa cronjobs en combinación con el directorio spool. |
4.1. Configuración de Linux
En Linux u otro sistema operativo tipo Unix, cualquier Plugin se puede ejecutar de forma asíncrona. Para una local check, la configuración necesaria es muy similar a la de un Plugin. Para ello, crea un subdirectorio con el nombre del número de segundos que quieres que se almacene la salida en la caché y coloca tu script en ese subdirectorio.
En el siguiente ejemplo, el local check se ejecutará solo cada 10 minutos (600 segundos):
Los datos almacenados en caché se escriben en un directorio de caché.
Para un servicio que proporciona datos almacenados en la caché, la información específica de la caché se añade a la vista del servicio:
4.2. Configuración en Windows
En Windows, la configuración también es similar a la de un plugin de agente. En lugar de usar un subdirectorio especial como en Linux y similares, las opciones se configuran en un archivo de configuración:
Como puedes ver arriba, en Windows puedes configurar la ejecución asíncrona (con async) y el intervalo de tiempo (con cache_age) por separado.
Como alternativa, en Windows también puedes realizar la configuración en Agent bakery.
5. Distribución a través de Agent bakery
Si ya estás usando Agent bakery en las ediciones comerciales, también puedes distribuir los scripts con local checks a varios hosts de esta manera.
Para ello, primero crea el directorio custom en el servidor Checkmk como usuario del site en ~/local/share/check_mk/agents/ y, dentro de él, un árbol de subdirectorios para cada paquete de local checks:
El directorio del paquete en el ejemplo anterior es mycustompackage.
Debajo de ese, el directorio lib marca el script como un Plugin o como una local check.
El directorio local que viene a continuación asigna el archivo de forma explícita.
Coloca el script con la local check en este directorio.
|
En Linux, puedes configurar la ejecución asíncrona de forma análoga a lo descrito en el capítulo anterior creando ahora un directorio bajo |
En el entorno de configuración de Checkmk, aparecerá el directorio de paquetes mycustompackage como una nueva opción:
Abre Setup > Agents > Windows, Linux, Solaris, AIX, crea una nueva regla con Agents > Agent rules > Generic agent options > Deploy custom files with agent y selecciona el paquete recién creado:
Checkmk integrará entonces de forma autónoma la local check correctamente en el paquete de instalación para el sistema operativo correspondiente. Una vez que se hayan activado los cambios y se haya actualizado el agente, la configuración estará completa. Ahora solo queda distribuir los agentes.
6. Análisis de errores
6.1. Probar el script
Si tienes problemas con un script que has escrito tú mismo, deberías check las siguientes posibles causas de error:
¿Está el script en el directorio correcto?
¿Es el script ejecutable y son correctos los permisos de acceso? Esto es especialmente relevante si no estás ejecutando el agente o el script con la cuenta root o LocalSystem.
-
¿La salida cumple con la sintaxis indicada? La salida del local check debe ajustarse a la sintaxis descrita en los capítulos Creación del script y Métricas. De lo contrario, no se puede garantizar una ejecución sin errores.
Pueden surgir problemas y errores, en particular, cuando una local check está destinada a realizar una tarea que requiere un check plugin completo, por ejemplo, cuando la salida de la propia local check contiene un título de la sección o la definición de un nombre del host tal y como se utiliza al transportar datos piggyback.
|
En Linux, cuando el script del agente o el plugin de agente se ejecutan directamente en un shell, pueden estar disponibles variables del entorno diferentes a las que hay cuando los ejecuta el Controlador de agentes de Checkmk. En Windows, el Controlador de agentes también se ejecuta bajo la cuenta LocalSystem, pero la llamada en el terminal se realiza bajo un usuario normal o un 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 invoca el agente Checkmk, debes usar el Controlador de agentes en modo de volcado si es posible. |
6.2. Probar la salida del agente en el host de destino
Si el script en sí es correcto, el agente se puede ejecutar en el host.
En sistemas operativos tipo Unix, como Linux, BSD, etc., está disponible el comando siguiente.
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 que se ajuste al número de líneas de salida esperadas:
En la última línea, puedes reconocer un servicio almacenado en caché por la información de «cached» que lo precede, con la hora Unix actual y el intervalo de ejecución en segundos.
En Windows, puedes conseguir un resultado muy similar con PowerShell y la Cmdlet Select-String, igual que con el comando grep en Linux. En el siguiente comando, los dos dígitos que siguen al parámetro Context determinan cuántas líneas se mostrarán antes y después del resultado:
|
Dependiendo del entorno, el lenguaje de programación utilizado, la versión de Windows y algunas otras condiciones, a menudo te enfrentas al juego de caracteres UTF-16 en Windows. Además, allí se encuentra con frecuencia la combinación de retorno de carro y salto de línea para los saltos de línea. Sin embargo, Checkmk, como aplicación de Linux, espera UTF-8 y simples saltos de línea sin peros. Nuestro artículo sobre el directorio spool incluye un capítulo que explica cómo solucionar problemas relacionados con el juego de caracteres. |
6.3. Probar la salida del agente en el servidor Checkmk
Como último paso, el procesamiento de la salida del script también se puede probar en el servidor Checkmk con el comando «cmk» —una vez para el descubrimiento de servicios:
… y también el proceso de la salida del servicio con un comando similar:
En ambos comandos hemos acortado la salida omitiendo las líneas que no son relevantes para este tema.
Como alternativa, puedes abrir la lista de servicios del host en la monitorización, ir a la sección «Check_MK» y a su columna «Icons». Allí puedes seleccionar la opción de menú «Download agent output» para obtener un archivo de texto con la salida completa del agente.
Si hay errores en una 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 ayudarte a identificar rápidamente los errores en un script.
7. Archivos y directorios
Todas las rutas especificadas hacen referencia a paquetes de instalación que se han empaquetado con configuraciones estándar. Si has instalado un script del agente sin empaquetar o has adaptado los directorios de instalación mediante una regla de Bakery, busca las rutas en el propio script o adapta las rutas a tu propia configuración.
7.1. Directorio de scripts en el host de destino
Almacenas las local checks en estos directorios. Las local checks pueden ser cualquier archivo ejecutable.
| Ruta | Sistema operativo |
|---|---|
|
AIX, Linux y Solaris |
|
Windows |
7.2. Directorio caché en el host de destino
Los datos almacenados en la caché de secciones individuales, incluida la sección «local», se guardan aquí y se vuelven a adjuntar al agente con cada ejecución, siempre y cuando los datos sean válidos.
| Ruta | Sistema operativo |
|---|---|
|
AIX, Linux y Solaris |