Creación de check plugins basados en el agente

Desde la versión de Checkmk 2.0.0, existe una API de Check de nuevo desarrollo para programar los plugins de check. En la versión de Checkmk 2.3.0, la API de Check V2 es la versión actual. En este artículo, te mostraremos cómo utilizar la API de Check versión 2 para la programación de plugins. Encontrarás información sobre la migración a la API de Check versión 2 al final de este artículo, en el capítulo Migración.

Puedes acceder a la documentación de la API de Check en cualquier momento a través de la interfaz de usuario de Checkmk: Help > Developer resources > Plugin API references. En la nueva ventana del navegador, selecciona Agent based ("Check API") > Version 2 en la barra de navegación de la izquierda:

Aquí no sólo encontrarás la documentación de la API de Check en todas las versiones compatibles, sino también la documentación de todas las demás API relevantes para la creación de plugins de check. En este artículo, no sólo utilizamos la API de Check, sino también la API de Conjuntos de reglas V1 al crear un conjunto de reglas y la API de gráficos V1 al crear definiciones métricas.

Si estás interesado en programar plugins de check, necesitarás lo siguiente:

El primer paso antes de escribir cualquier programa Plugin es ¡investigar! Esto significa que hay que averiguar cómo obtener la información que necesitas para la monitorización.

Para el ejemplo elegido, utilizamos el hecho de que el servidor Checkmk es también el host. Esto significa que, inicialmente, basta con recuperar los datos de estado a través de Livestatus, es decir, los datos organizados en tablas que Checkmk guarda sobre los host y servicios monitorizados en la memoria volátil.

Entra como usuario del site y consulta la información sobre los grupos del host con el siguiente comando:

La primera línea de la salida contiene los nombres de las columnas de la tabla hostgroups consultada. El punto y coma actúa como separador. Las líneas siguientes contienen el contenido de todas las columnas, también separadas por punto y coma.

La salida ya es relativamente confusa en este pequeño ejemplo y contiene información que no es relevante para nuestro ejemplo. En general, deberías dejar la interpretación de los datos a Checkmk. Sin embargo, el filtrado previo en el host puede reducir el volumen de datos que hay que transferir si en realidad no se necesitan todos. Así que, en este caso, restringe la consulta a las columnas relevantes (Columns), a los nombres de los grupos del host (name) y a los host de esos grupos (members):

La interfaz Livestatus espera recibir todos los comandos y cabeceras en su propia línea separada. Los saltos de línea necesarios se indican con \n.

En este ejemplo, actualmente hay tres grupos del host: dos grupos para las ubicaciones y uno para el grupo check_mk. Éste contiene un host llamado localhost.

El grupo del host check_mk es una característica especial dentro de los grupos del host. No lo has creado tú, y no puedes añadir activamente un host a este grupo. Entonces, ¿de dónde viene este grupo del host? Como, por definición, todo host en Checkmk debe pertenecer a un grupo, Checkmk asigna por defecto al grupo "especial" check_mk todo host que no asignes específicamente a un grupo. En cuanto hayas asignado un host a uno de tus propios grupos de host, Checkmk lo eliminará del grupo check_mk. Tampoco hay forma de reasignar un host al grupo del host check_mk.

Exactamente estas propiedades del grupo check_mk se utilizan ahora para nuestro ejemplo: Puesto que cada host debe asignarse a una ubicación, el grupo del host check_mk debe estar vacío. Si no está vacío, hay que actuar, es decir, los hosts que contiene deben asignarse a los grupos del host y, por tanto, a sus ubicaciones correspondientes.

Hasta ahora, como usuario del site, has utilizado el comando lq para visualizar la información, lo que resulta útil para conocer los datos.

Sin embargo, para recuperar estos datos del servidor Checkmk, el nuevo comando debe formar parte del agente Checkmk en el host monitorizado. En teoría, ahora podrías editar directamente el agente Checkmk en el archivo /usr/bin/check_mk_agent e incluir esta parte. Sin embargo, este método tendría el inconveniente de que tu nuevo comando volvería a desaparecer cuando se actualizara el software del agente, porque este archivo se sobrescribiría durante la actualización.

Por lo tanto, es mejor crear un plugin de agente. Todo lo que necesitas para ello es un archivo ejecutable que contenga el comando y que se encuentre en el directorio /usr/lib/check_mk_agent/plugins/.

Y una cosa más es importante: los datos no pueden salir sin más. Seguirás necesitando una cabecera de sección. Se trata de una línea con un formato especial que contiene el nombre del nuevo plugin de agente. Esta cabecera de sección permite que Checkmk reconozca posteriormente dónde empiezan los datos del nuevo plugin de agente y dónde acaban los del plugin anterior. Lo más fácil es que el plugin de agente, la cabecera de sección y el check plugin tengan el mismo nombre, aunque no sea obligatorio.

Así que, en primer lugar, necesitarás un nombre significativo para tu nuevo check plugin. Este nombre sólo puede contener letras minúsculas (sólo de la a a la z, sin diéresis ni acentos), guiones bajos y dígitos, y debe ser único. Evita conflictos de nombres con los check plugins existentes. Si tienes curiosidad por saber qué nombres ya existen, en un site de Checkmk, en la línea de comandos, puedes listarlos con cmk -L:

La salida aquí sólo muestra las primeras líneas de la larguísima lista. Mediante el uso de prefijos, la asignación de muchos check plugins ya puede reconocerse fácilmente aquí. Por tanto, también se recomienda el uso de prefijos para tus propios check plugins. Por cierto, la segunda columna muestra cómo obtiene sus datos el respectivo check plugin.

Un nombre adecuado para el nuevo check plugin de nuestro ejemplo es myhostgroups.

Ahora tienes toda la información que necesitas para crear el script del plugin de agente. Crea un nuevo archivo myhostgroups como usuario de root en el directorio /usr/lib/check_mk_agent/plugins/:

¿Qué significa esto en detalle?

La primera línea contiene el "shebang" (abreviatura de sharp y bang, este último es una abreviatura del signo de exclamación), mediante el cual Linux reconoce que debe ejecutar el script con el shell especificado.

Para mantener la adaptabilidad del script, a continuación se introducen dos variables

Utiliza el comando echo para dar salida al título de la sección. Como las columnas de la tabla están separadas por un punto y coma, utiliza el añadido sep(59) para especificar que se utilice el punto y coma como separador de los datos en la salida del agente. El 59 representa el código de caracteres ASCII 59, el punto y coma. Sin este añadido, se utilizaría por defecto el carácter espacio (carácter ASCII 32) como separador.

Para poder utilizar el comando lq, que está a tu disposición como usuario del site, en un script que sea ejecutado por el usuario root, ponle como prefijo su.

Un punto más es importante una vez que hayas creado el archivo: haz que el archivo sea ejecutable:

Puedes probar el plugin de agente directamente a mano introduciendo la ruta completa como comando:

Los grupos del host que no contienen ningún host no se listan aquí.

Probar y solucionar problemas son las tareas más importantes a la hora de crear un plugin de agente que funcione. Lo mejor es proceder en tres pasos:

Probar el agente localmente es muy sencillo. Como root, llama al comando check_mk_agent:

La nueva sección debe aparecer en algún lugar de la larguísima salida. Los Plugins de agente son emitidos por el agente al final del proceso.

Puedes desplazarte por la salida añadiendo less (pulsa la barra espaciadora para desplazarte, / para buscar y q para salir):

O puedes buscar en la salida las líneas interesantes. Por ejemplo, grep con -A tiene una opción para dar salida a unas cuantas líneas más después de cada acierto, lo que te permite buscar y dar salida a la sección cómodamente:

La tercera y última prueba se realiza directamente desde el sitio Checkmk. Incluye el host en la monitorización (por ejemplo, como localhost), inicia sesión como usuario del site y recupera los datos del agente con cmk -d:

Esto debería producir el mismo resultado que el comando anterior.

Si esto funciona, tu agente está listo. ¿Y qué has hecho para ello? Has creado un breve script bajo la ruta /usr/lib/check_mk_agent/plugins/myhostgroups y lo has hecho ejecutable.

Todo lo que sigue ahora sólo tiene lugar en el servidor Checkmk: allí escribes el check plugin.

Para tus propios plugins de check, encontrarás el directorio base ya preparado en la jerarquía local del directorio del site. Se trata de ~/local/lib/python3/cmk_addons/plugins/. El directorio pertenece al usuario del site y, por tanto, puedes escribir en él.

En este directorio, los plugins se organizan en familias de plugins, cuyos nombres de directorio pueden definirse libremente. Por ejemplo, todos los plugins relativos a los dispositivos Cisco se almacenan en la carpeta cisco, del mismo modo que todos los plugins relativos a tus grupos del host se almacenan en la carpeta myhostgroups. Esta convención permite que todos los plugins pertenecientes a la misma familia compartan código, y es utilizada exactamente del mismo modo por los plugins que se entregan con Checkmk.

En este subdirectorio <plug-in_family>, se crean otros subdirectorios con nombres predefinidos según sea necesario para las distintas APIs, por ejemplo agent_based para la API Check de los plugins de agente. A su vez, más adelante introduciremos otros subdirectorios para la API Rulesets y la API Graphing.

Crea los dos subdirectorios para el nuevo plugin de check plugin basado en agentes y, a continuación, pásate a ellos para trabajar:

Puedes editar tu check plugin con cualquier editor de texto instalado en el sistema Linux.

Crea aquí el archivo myhostgroups.py para el check plugin. La convención es que el nombre del archivo refleje el nombre de la sección del agente. Es obligatorio que el archivo termine en .py, porque a partir de la versión de Checkmk 2.0.0 los check plugins son siempre módulos reales de Python.

Un marco básico ejecutable(Descargar en GitHub), que ampliarás paso a paso a continuación, tiene el siguiente aspecto:

En primer lugar, tienes que importar las funciones y clases necesarias para los plugins de check de los módulos de Python. Para nuestro ejemplo, sólo importaremos lo que sea necesario o pueda ser útil en el resto de este artículo. Aquí se utiliza cmk.agent_based.v2 para especificar que se importan los módulos de la API Check V2:

La función parse tiene la tarea de "analizar" los datos "en bruto" del agente, es decir, analizarlos y dividirlos, y poner estos datos en una forma lógicamente estructurada que sea fácil de procesar para todos los pasos posteriores.

Como se muestra en la sección sobre la comprobación del agente, la sección suministrada por el plugin de agente tiene la siguiente estructura:

Checkmk ya divide las líneas de la sección suministrada por el plugin de agente en una lista de líneas basadas en el separador del título de la sección (en el ejemplo ;), estas líneas son a su vez listas de palabras. Por tanto, en lugar de los datos en bruto del plugin de agente, Checkmk dispone de la siguiente estructura de datos:

En la lista interior, el primer elemento contiene el nombre del grupo del host y el segundo los nombres de los host pertenecientes al grupo.

Por tanto, siempre tendrías que especificar el número de corchetes y el número de "secuencia" del contenido o contenidos deseados dentro de cada corchete. Con mayores volúmenes de datos, esto se vuelve cada vez más complejo y cada vez resulta más difícil mantener una visión de conjunto.

En este punto, una función de análisis sintáctico ofrece claras ventajas gracias a la estructura que crea. Facilita la lectura del código, los accesos son más eficaces y es mucho más fácil mantener una visión de conjunto. Transforma la estructura de datos suministrada por Checkmk de forma que puedas dirigirte a cada uno de los valores individuales por su nombre (o clave) a voluntad, y no depender de buscar repetidamente en la matriz para encontrar lo que buscas:

La convención es que la función de análisis sintáctico lleve el nombre de la sección del agente y empiece por parse_. Recibe string_table como único argumento. Ten en cuenta que aquí no puedes elegir libremente el argumento: debe llamarse exactamente así.

Con def especificas en Python que se va a definir una función a continuación.parsed = {} crea el diccionario con la estructura de datos mejorada. En nuestro ejemplo, recorreremos cada línea, elemento por elemento. El grupo del host seguido de los miembros del grupo del host se toma de cada línea y se ensambla en una entrada para el diccionario.

A continuación, se devuelve el diccionario con return parsed.

Para que todo este procedimiento tenga efecto, debes crear la nueva sección agente con la nueva función de análisis sintáctico. Sólo así será reconocida y tenida en cuenta por Checkmk. Para ello, crea la sección agente como una instancia de la clase AgentSection:

Aquí es importante que el nombre de la sección coincida exactamente con el título de la sección en la salida del agente. A partir de este momento, todo plugin de check que utilice la sección myhostgroups recibirá el valor de retorno de la función parse. Por regla general, será el plugin de check del mismo nombre. Pero también pueden suscribirse a esta sección otros plugins de check, como mostraremos en la ampliación del plugin de check.

Por cierto: Si quieres saberlo con exactitud, puedes echar un vistazo a la documentación de la API de check en este punto. Allí encontrarás una descripción detallada de esta clase -y también de las clases, funciones y objetos que se utilizarán más adelante en este artículo.

Para que Checkmk reconozca que hay un nuevo check plugin, hay que crearlo. Esto se hace creando una instancia de la clase CheckPlugin.

Siempre debes especificar al menos cuatro cosas

El nombre de la instancia debe empezar por check_plugin_. Entonces tiene el siguiente aspecto:

Es mejor que no lo pruebes todavía, ya que primero tienes que escribir las funciones discover_myhostgroups y check_myhostgroups. Éstas deben aparecer en el código fuente antes de crear la sección de agente y el plugin de check, como se ha descrito anteriormente.

Una característica especial de Checkmk es el descubrimiento automático de los servicios que hay que monitorizar. Para que esto funcione, cada check plugin debe definir una función que utilice la salida del agente para reconocer si hay que crear un servicio de este tipo o qué servicios de este tipo para el host en cuestión.

La función de descubrimiento siempre se llama cuando se lleva a cabo un descubrimiento de servicios para un host. A continuación, decide si deben crearse servicios o cuáles. En el caso estándar, recibe exactamente un argumento con el nombre section. Éste contiene los datos de la sección del agente en un formato preparado por la función de análisis sintáctico.

Por tanto, aplica la siguiente lógica simple:si existe la sección de agente myhostgroups, crea también un servicio adecuado, que aparecerá automáticamente en todos los host en los que se distribuya el plugin de agente.

Para los plugins de check que sólo crean un servicio por host, no se necesita más información:

La función de descubrimiento debe devolver un objeto del tipo service por cada servicio que se cree con yield (no con return). En Python, yield tiene la misma función que return: ambas devuelven un valor a la función que llama. La diferencia decisiva es que yield recuerda hasta dónde ha llegado la función en el proceso de datos. La siguiente llamada continúa después de la última sentencia yield, y no vuelve a empezar desde el principio. Esto significa que no sólo se lee el primer resultado (como ocurriría con return), sino todos los resultados en secuencia (esta ventaja será relevante más adelante en nuestro ejemplo con el descubrimiento de servicios).

Ahora puedes pasar a la función check propiamente dicha, que utiliza la salida del agente actual para decidir qué estado debe asumir el servicio y puede emitir más información.

El objetivo de la función de comprobación es establecer un check que sirva para verificar si se ha asignado un grupo del host a algún host. Para ello, comprueba si el grupo del host check_mk contiene host. Si es así, el servicio debe recibir el estado CRIT. Si no, todo está OK y también el estado del servicio.

Aquí tienes la implementación:

Y ahora la explicación: La función check_myhostgroups() primero obtiene el valor perteneciente a la clave check_mk en la variable attr. A continuación, la variable hosts se vincula al valor members si existe. Si no existe members, hosts permanece vacía.

A continuación, se realiza una consulta if para la evaluación propiamente dicha:

Una vez creada la función check, el Plugin check está listo.

El check pluginy el plugin de agenteestán disponibles en GitHub.

La prueba y la activación se realizan en la línea de comandos con el comando cmk.

Primero prueba el descubrimiento de servicios con la opción -I. Añadiendo la opción v (para verbosidad), se solicita una salida detallada. --detect-plugins restringe la ejecución del comando a este check plugin y, a través de localhost, a este host:

Como estaba previsto, el descubrimiento de servicios reconoce un nuevo servicio en el myhostgroups check plugin.

Ahora puedes probar el check contenido en el check plugin:

Al ejecutar el check, se determinará el estado del servicio encontrado anteriormente.

Si todo ha ido como esperabas, puedes activar los cambios. Si no, encontrarás información útil en el capítulo sobre solución de problemas.

Por último, activa los cambios reiniciando el núcleo de monitorización:

En la monitorización Checkmk, ahora encontrarás el nuevo servicio Host group check_mk en el host localhost:

¡Enhorabuena por haber creado con éxito tu primer plugin de check!

Ahora hay que ampliar paso a paso el primer check plugin, que se ha completado recientemente. Hasta ahora, el plugin de agente sólo ha proporcionado información sobre los nombres y los miembros de los grupos del host. Para poder evaluar el estado de los host y de los servicios que se ejecutan en ellos, por ejemplo, se necesitan más datos.

En el capítulo anterior has construido un check muy sencillo que crea un servicio en un host. Sin embargo, también es muy habitual que haya varios servicios a partir de un único check en un host.

El ejemplo más común de esto es un servicio para un sistema de archivos en un host. El check plugin con el nombre df crea un servicio por cada sistema de archivos en el host. Para distinguir estos servicios, el punto de montaje del sistema de archivos (por ejemplo /var) o la letra de la unidad (por ejemplo C:) se incorpora al nombre del servicio. Esto da lugar a un nombre de servicio como Filesystem /var o Filesystem C:. La palabra /var o C: se denomina aquí item. Por lo tanto, también estamos hablando de un check con items.

Si quieres construir un check con items, debes implementar las siguientes funciones:

Para comprobarlo en la práctica, crearás un servicio distinto para cada grupo del host existente.

Puesto que el plugin de comprobación myhostgroups creado en el capítulo anterior para comprobar el grupo estándar check_mk debe seguir funcionando, este plugin de comprobación permanece tal cual. Para la ampliación, crea el nuevo plugin de comprobación myhostgroups_advanced en el archivo existente myhostgroups.py.- en el primer paso, como anteriormente, creando una instancia de la clase CheckPlugin.

Aquí puedes encontrar el código antiguo y el nuevo resaltado:

Para que el nuevo plugin de check pueda distinguirse del antiguo, se le da un nombre único con myhostgroups_advanced. El parámetro sections determina las secciones de la salida del agente a las que se suscribe el plugin de check. Aquí, myhostgroups se utiliza para especificar que el nuevo plugin de check utiliza los mismos datos que el antiguo: la sección del plugin de agente preparada por la función parse. El nombre del servicio contiene ahora el marcador de posición %s. El nombre del item es insertado posteriormente en este punto por Checkmk. En las dos últimas líneas se definen los nombres de la nueva función de descubrimiento y de la nueva función de comprobación, ambas aún por escribir.

En primer lugar, la función de descubrimiento, que ahora tiene la tarea de determinar los items que se van a monitorizar, se introduce además de la ya existente:

Como en el caso anterior, la función de descubrimiento recibe el argumento section. Los grupos de host individuales se ejecutan en un bucle. Todos los grupos de host son de interés aquí, con la excepción de check_mk, ya que de este grupo de host especial ya se ha ocupado el check plugin existente myhostgroups. Siempre que se encuentra un item, se devuelve con yield, que crea un objeto del tipo Service, que a su vez recibe el nombre del grupo del host como item.

Si el host se monitoriza posteriormente, la función check se llama por separado para cada servicio, y por tanto para cada item. Esto te lleva a la definición de la función check para el nuevo plugin de comprobación myhostgroups_advanced. La función check recibe el argumento item además de la sección. La primera línea de la función tiene entonces este aspecto

El algoritmo de la función check es sencillo: si el grupo del host existe, el servicio se pone en OK y se enumeran el número y los nombres de los host del grupo. La función completa para esto:

El resultado del check se entrega devolviendo un objeto de la clase Result a través de yield. Para ello se necesitan los parámetros state y summary. Aquí, state define el estado del servicio (en el ejemplo OK) y summary el texto que se muestra en la Summary del servicio. Esto es puramente informativo y Checkmk no lo evalúa más. Encontrarás más información al respecto en la siguiente sección.

Hasta aquí todo bien, pero ¿qué ocurre si no encuentras el item que buscas? Esto puede ocurrir si en el pasado ya se creó un servicio para un grupo del host, pero este grupo del host ha desaparecido, bien porque el grupo del host sigue existiendo en Checkmk pero ya no contiene ningún host, bien porque se ha eliminado por completo. En ambos casos, este grupo del host ya no estará presente en la salida del agente.

La buena noticia es que Checkmk se ocupa de esto: si no se encuentra un item buscado, Checkmk genera automáticamente el resultado UNKNOWN - Item not found in monitoring data para el servicio. Esto es intencionado y algo bueno: si no se encuentra un item buscado, puedes simplemente ejecutar Python fuera de la función y dejar que Checkmk haga su trabajo.

Checkmk sólo sabe que el item que antes estaba allí ahora no está. Checkmk no sabe la razón de ello, pero tú sí. Por tanto, es conveniente no guardarse ese conocimiento e interceptar esta condición en la función check y mostrar un mensaje de ayuda.

¿Qué ha cambiado? Ahora se trata primero la condición de error. Por tanto, comprueba en la rama if si el item realmente no existe, establece el estado a CRIT y sal de la función con return. En todos los demás casos, devuelve OK como antes.

Esto significa que has adoptado la situación de grupos del host que desaparecen en la función check. En lugar de UNKNOWN, el servicio asociado será ahora CRIT y contendrá información sobre la causa del estado crítico.

Esto completa el nuevo check plugin como una extensión del antiguo. En GitHub puedes encontrar de nuevo el plugin de agenteextendido y el archivo extendido para los check plugins. Este último contiene el simple check plugin myhostgroups del capítulo anterior, la función de análisis sintáctico avanzado y los componentes del nuevo check plugin myhostgroups_advanced con la creación del check plugin, la función de descubrimiento y la función de comprobación. Ten en cuenta que las funciones deben definirse siempre antes de crear los check plugins o las secciones de agente, para que no se produzcan errores por nombres de función no definidos.

Como el nuevo myhostgroups_advanced check plugin proporciona nuevos servicios, debes realizar un descubrimiento de servicios para este check plugin y activar los cambios para ver estos servicios en la monitorización:

Procede como se describe en el capítulo del check plugin simple. No ejecutes los dos primeros comandos para myhostgroups, en su lugar ejecútalos para el nuevo check plugin myhostgroups_advanced.

En la monitorización de Checkmk, cada servicio tiene un estado-OK, WARN, etc.-, así como una línea de texto. Este texto se encuentra en la columna Summary -como se puede ver en la captura de pantalla anterior- y, por tanto, tiene la función de proporcionar un breve resumen del estado del servicio. El concepto es que este texto no supere una longitud de 60 caracteres, lo que garantiza una visualización concisa de la tabla sin molestos saltos de línea.

También está el campo Details, en el que se muestran todos los detalles sobre el estado del servicio, que también incluye toda la información resumida. Al hacer clic en el servicio, se abre la página del servicio, en la que se pueden ver los dos campos Summary y Details junto con muchos otros.

Al llamar a yield Result(...), puedes determinar qué información es tan importante que deba mostrarse en el resumen, y para cuál es suficiente que aparezca en los detalles.

En nuestro ejemplo, siempre has utilizado una llamada del siguiente tipo

Esto significa que el texto definido como summary siempre aparece en el Summary- y también en el Details. Por lo tanto, sólo debes utilizarlo para la información importante. Si un grupo del host contiene muchos host, la lista resumen puede llegar a ser muy larga - más de los 60 caracteres recomendados. Si una información es de importancia secundaria, puedes utilizar details para especificar que su texto sólo aparezca en los detalles:

Por tanto, en el ejemplo anterior, la lista de host sólo se muestra en Details. En Summary sólo se muestra el número de host del grupo:

Además de summary y details, existe un tercer parámetro. Con notice puedes especificar que el texto de un servicio en OK sólo se muestre en los detalles, pero también en el resumen de todos los demás estados. De este modo, en el resumen queda inmediatamente claro por qué el servicio no está OK. El parámetro notice no es especialmente útil si los textos están permanentemente vinculados a los estados, como en nuestro ejemplo hasta ahora.

En resumen, esto significa

Para evitar que el número de servicios de un host aumente excesivamente, a menudo se combinan varios resultados parciales en un solo servicio. Por ejemplo, el servicio Memory de Linux no sólo comprueba la carga de RAM y swap, sino también la memoria compartida, las tablas de páginas y todo tipo de cosas.

La API de comprobación proporciona una interfaz muy cómoda para ello. Una función de comprobación puede generar simplemente un resultado con yield tantas veces como sea necesario. El estado general del servicio se basa entonces en el peor resultado parcial en el orden OK → WARN → UNKNOWN → CRIT.

En el ejemplo, utiliza esta opción para definir dos resultados adicionales para cada servicio de los grupos del host, además del resultado existente. Éstos evalúan el porcentaje de host en estado UP y los servicios en estado OK. Utilizas las columnas adicionales de la tabla de grupos del host definidas previamente en la salida del agente y la función de análisis sintáctico.

Ahora expande la función check por etapas de arriba a abajo:

La rama if permanece sin cambios, es decir, los nuevos resultados parciales sólo se aplican a los grupos del host que también existen. A continuación, define cinco variables para las columnas de la tabla de grupos del host que contiene la sección. Por un lado, esto aumenta la legibilidad y, por otro, puedes convertir las cadenas leídas en números con int() para las cuatro columnas que aún deben utilizarse para el cálculo.

El único resultado existente permanece (casi) inalterado:

Sólo el acceso en la "cadena F" de Python a la expresión que devuelve el valor es ahora más fácil que antes, puesto que el attr ya está en las definiciones de las variables.

Pasemos ahora al núcleo real de la ampliación, la definición de un resultado que implemente la siguiente expresión: "El servicio del grupo del host es WARN cuando el 90 % de los host están UP, y CRIT cuando el 80 % de los host están UP" La convención aquí es que el check pase a WARN o CRIT en cuanto se alcance el umbral, y no sólo cuando se supere. La API Check proporciona la función auxiliar check_levels para comparar un valor determinado con los valores umbrales.

En la primera línea, el porcentaje se calcula a partir del número total y del número de host en estado UP y se almacena en la variable hosts_up_perc. La barra simple (/) ejecuta una división en coma flotante, lo que garantiza que el resultado es un valor flotante. Esto es útil porque algunas de las funciones que se utilizan más adelante esperan un valor flotante como entrada.

En la segunda línea, el resultado de la función check_levels se devuelve como un objeto del tipo Result, que puedes encontrar en la documentación de la API. Esta función se alimenta con el porcentaje que se acaba de calcular como valor (hosts_up_perc), los dos valores umbrales inferiores (levels_lower), una label que precede a la salida (label) y, por último, con notice_only=True.

El último parámetro hace uso del parámetro notice ya introducido en la sección anterior para el objeto Result(). Con notice_only=True especificas que el texto del servicio sólo se muestre en Summary si el estado no es OK. Sin embargo, los resultados parciales que conduzcan a un WARN o CRIT siempre serán visibles en el resumen -independientemente del valor de notice_only.

Por último, define el tercer resultado del mismo modo que el segundo, que evalúa el porcentaje de servicios en estado OK:

Esto completa la función check.

El servicio para un grupo del host evalúa ahora tres resultados y muestra el peor estado de ellos en la monitorización, como en el ejemplo siguiente:

No siempre, pero a menudo, los checks tratan con números, y estos números son muy a menudo valores medidos o calculados. En nuestro ejemplo, el número de host en el grupo del host (num_hosts) y el número de host en estado UP (num_hosts_up) son los valores medidos. El porcentaje de host en estado UP (hosts_up_perc) es un valor calculado a partir de estos valores. Si este valor puede mostrarse en un intervalo de tiempo, también se denomina métrica.

Con su sistema de gráficos integrado, Checkmk dispone de un componente para almacenar, evaluar y mostrar dichos valores, que es totalmente independiente del cálculo de los estados OK, WARN y CRIT.

En este ejemplo, definirás los dos valores calculados, hosts_up_perc y services_ok_perc, como métricas. Las métricas serán visibles inmediatamente en la interfaz gráfica de usuario de Checkmk sin que tengas que hacer nada. Se genera automáticamente un gráfico para cada métrica.

Las métricas las determina la función check y las devuelve como resultado adicional. La forma más sencilla es añadir la información de las métricas a la función check_levels() en la llamada.

Como recordatorio, aquí siguen las líneas con la llamada a la función check_levels() de la sección anterior:

Los dos nuevos argumentos para la métrica son metric_name y boundaries:

Para que todo sea sencillo y tenga sentido, para el nombre de la métrica utiliza el nombre de la variable en la que se almacena el porcentaje como valor.

Puedes utilizar boundaries para proporcionar al sistema de gráficos información sobre el rango de valores posibles. Esto se refiere al valor más pequeño y al más grande posibles. En el caso de un porcentaje, los límites de 0.0 y 100.0 no son demasiado difíciles de determinar. Se permiten tanto números de coma flotante como números enteros (que se convierten internamente en números de coma flotante), pero no cadenas. Si sólo se define un límite del rango de valores, simplemente introduce None para el otro, por ejemplo boundaries = (0.0, None).

Con esta ampliación, la función check_levels ahora también devuelve un objeto del tipo Metric a través de yield además del Result.

Ahora puedes definir la métrica services_ok_perc del mismo modo. Las últimas líneas de la función check tendrán entonces el siguiente aspecto:

Con la función de check ampliada, ambos gráficos son visibles en la monitorización. En la lista de servicios, el icono muestra ahora que hay gráficos para el servicio. Si señalas el icono con el ratón, los gráficos se mostrarán como una vista previa.

En los detalles del servicio encontrarás una Vista general de todos los gráficos, con sus leyendas y demás.

Pero, ¿qué haces si el valor de la métrica deseada no se ha definido con la función check_levels()? Por supuesto, puedes definir una métrica independientemente de una llamada a la función. Para ello se utiliza el objeto Metric(), que también puedes crear directamente mediante su constructor. La definición alternativa de una métrica para el valor hosts_up_perc tiene este aspecto:

Los argumentos de Metric() son muy similares a los de la llamada a la función mostrada anteriormente: son obligatorios los dos primeros argumentos para el nombre de la métrica y el valor. Además, hay dos argumentos opcionales: levels para los valores umbrales WARN y CRIT y boundaries para el intervalo de valores.

Ahora utiliza la opción de definir no sólo los dos valores calculados, sino todos los valores medidos como métricas utilizando Metric()-en nuestro ejemplo, los cuatro valores medidos de la tabla del grupo del host. Limítate a las dos especificaciones obligatorias de nombre del host y valor de la métrica. Las cuatro nuevas líneas completan la ampliación de la función de comprobación de métricas:

Esto aumenta el número de gráficos por servicio, pero también te da la opción de combinar varias métricas en un solo gráfico, por ejemplo. Mostramos éstas y otras opciones en la sección Personalizar la visualización de las métricas, más abajo.

En el archivo de ejemplo enGitHubpuedes encontrar de nuevo toda la función check.

Para crear un nuevo conjunto de reglas, crea primero un nuevo subdirectorio en el directorio de la familia de plugins ~/local/lib/python3/cmk_addons/plugins/myhostgroups/. El nombre rulesets está predefinido para este subdirectorio:

A continuación, crea en este directorio un archivo para la definición del conjunto de reglas. El nombre del archivo debe basarse en el del plugin check y, como todos los archivos de los plugins, debe tener la extensión py. Para nuestro ejemplo, es adecuado el nombre de archivo ruleset_myhostgroups.py.

Veamos paso a paso la estructura de este archivo. Primero hay algunos comandos de importación:

En primer lugar, se importan las clases de los textos.

La segunda línea hace una selección de las especificaciones de formulario, es decir, los elementos básicos para la GUI que se utilizan en el conjunto de reglas, por ejemplo, la selección binaria (BooleanChoice), la selección múltiple (Dictionary, DictElement), la definición de valores umbrales (SimpleLevel, LevelDirection, DefaultValue) y la introducción de números de coma flotante (Float). Aquí sólo solicitas los elementos lógicos del formulario y dejas el diseño de la GUI a Checkmk.

La última línea importa las especificaciones de la regla, que determinan el ámbito de aplicación de la regla en Checkmk, es decir, aquí se definen los parámetros de check, la asignación a host y items y el almacenamiento bajo un tema. Como tu check plugin myhostgroups_advanced genera varios servicios, importa aquí HostAndItemCondition. Si tu check no genera ningún servicio, es decir, no tiene ningún item, importa en su lugar HostCondition.

Ahora vienen las definiciones reales del formulario para introducir los parámetros de check. El usuario debe poder definir por separado los dos valores umbrales de WARN y CRIT tanto para el número de host en estado UP como para el número de servicios en estado OK:

Para ello, crea una función que genere el diccionario. Puedes elegir libremente el nombre de la función; sólo es obligatorio al crear la regla siguiente. El nombre debe empezar por un guión bajo para que la función no sea visible más allá del límite del módulo.

El formulario return Dictionary() es obligatorio. Dentro de él, utiliza elements={} para crear los elementos del diccionario, en el ejemplo hosts_up_lower y services_ok_lower. El formulario de parámetros SimpleLevels se utiliza para introducir valores umbrales fijos. En el formulario, define primero los números title y de coma flotante para los valores a introducir (form_spec_template). Utiliza LevelDirection.LOWER para especificar que el estado cambiará si los valores caen por debajo de este nivel.

Por último, puedes utilizar prefill_fixed_levels para proporcionar a los usuarios del conjunto de reglas valores en lugar de campos de entrada vacíos. Ten en cuenta que estos valores mostrados en la GUI no son los valores por defecto que se establecen más abajo en la creación del check plugin mediante check_default_parameters. Si quieres mostrar los mismos valores por defecto en la GUI que también se aplican a la función de comprobación, debes mantener la coherencia de los valores en ambos lugares.

Por último, crea el nuevo conjunto de reglas utilizando los items importados y autodefinidos. Esto se hace creando una nueva instancia de la clase CheckParameters. El nombre de esta instancia debe empezar por rule_spec_:

Se aplican las siguientes explicaciones:

Una vez que hayas creado el archivo para el conjunto de reglas, debes probar si todo funciona hasta ahora, aún sin conexión con el check plugin. Para ello, primero debes reiniciar el Apache del site para que se pueda leer el nuevo archivo. Esto se realiza con el comando:

El conjunto de reglas debería encontrarse entonces en Setup en la página mencionada anteriormente. También puedes encontrar el conjunto de reglas utilizando la función de búsqueda del menú de configuración - pero sólo después de reiniciar Redis:

El conjunto de reglas que acabas de definir tendrá este aspecto en la GUI:

En la caja Conditions, encontrarás el campo de entrada Host group name definido a través de HostAndItemCondition para restringir la regla para grupos del host.

Crea una regla y prueba con distintos valores, como se muestra en la captura de pantalla anterior. Si funciona sin errores, ya puedes utilizar los parámetros de check en la función de verificación.

El conjunto de reglas recién creado está ahora conectado con el check plugin completado provisionalmente en el capítulo anterior. Para que la regla surta efecto, debes permitir que el check plugin acepte parámetros de check e indicarle qué regla debe utilizar. Para ello, añade dos nuevas líneas al archivo del check plugin al crear el myhostgroups_advanced check plugin:

Con la entrada check_default_parameters, puedes definir los valores por defecto que se aplican mientras no se haya creado ninguna regla. Al convertir el Plugin de check para parámetros de check, esta línea debe estar presente. En el caso más sencillo, pasa un diccionario vacío {}.

En segundo lugar, introduce check_ruleset_name, es decir, el nombre del conjunto de reglas. De este modo, Checkmk sabrá a partir de qué conjunto de reglas deben determinarse los parámetros.

Ahora Checkmk intentará pasar parámetros a la función check. Para que esto funcione, debes ampliar la función check para que espere el argumento params, que se inserta entre item y section:

Si estás construyendo un check sin item, se omite item y se pone params al principio.

Es muy recomendable que el contenido de la variable params salga con un print como primera prueba:

Cuando se ejecute el plugin de check, las líneas impresas (una por cada servicio) con los valores definidos por una regla tendrán entonces un aspecto parecido al siguiente:

Ahora personaliza aún más tu función check para que los parámetros pasados puedan tener efecto. Obtén de los parámetros los dos elementos del diccionario definidos en la regla con el nombre allí seleccionado:

Más abajo en la función check, los valores umbrales codificados previamente "fixed", (90.0, 80.0) se sustituyen por las variables hosts_up_lower y services_ok_lower:

Si se ha configurado una regla, ahora puedes monitorizar los grupos del host del ejemplo con los valores umbrales establecidos a través de la GUI. Sin embargo, si no se ha definido ninguna regla, esta función de check se bloqueará, ya que no se habrán rellenado los parámetros por defecto del check plugin, y el plugin generará un KeyError en ausencia de una regla.

Sin embargo, este problema puede solucionarse si los valores por defecto se definen al crear el plugin de check:

Siempre debes pasar valores por defecto de esta forma (y no interceptar el caso de que falten parámetros en el check plugin), ya que estos valores por defecto también se pueden mostrar en la interfaz Setup. Por ejemplo, en el descubrimiento de servicios de un host, en la página Services of host, en el menú Display, está el interruptor Show check parameters.

Los procedimientos para crear conjuntos de reglas y definiciones métricas son muy similares. Primero crea un nuevo subdirectorio con el nombre por defecto graphing en el directorio de tu familia de Plugin ~/local/lib/python3/cmk_addons/plugins/myhostgroups/.

A continuación, crea un archivo gráfico en este directorio, por ejemplo graphing_myhostgroups.py.

Primero hay de nuevo algunos comandos de importación:

Para nuestro ejemplo, ahora defines tu propia métrica para el porcentaje de servicios en estado OK. Esto se hace creando una instancia de la clase Metric. El nombre de esta instancia debe empezar por metric_

He aquí la explicación:

Esta definición en el archivo gráfico garantiza ahora que el título, la unidad y el color de la métrica se muestren adecuadamente.

De forma similar a la creación de un archivo de conjunto de reglas, el archivo de gráficos debe leerse primero para que el cambio sea visible en la GUI, lo que se consigue reiniciando el Apache del site:

El gráfico métrico tendrá entonces este aspecto en la GUI de Checkmk:

Si quieres combinar varias métricas en un gráfico (lo que suele ser muy útil), necesitarás una definición de gráfico que puedes añadir al archivo de gráficos creado en la sección anterior.

En nuestro ejemplo, las dos métricas num_services y num_services_ok deben mostrarse en un único gráfico. Las definiciones métricas para ello se crean del mismo modo que en la sección anterior para services_ok_perc y tienen el siguiente aspecto:

Ahora añade un gráfico que dibuje estas dos métricas como líneas. Esto se hace mediante una instancia de la clase Graph, cuyo nombre debe empezar de nuevo con un prefijo predefinido (graph_):

El parámetro minimal_range describe el rango mínimo cubierto por el eje vertical del gráfico, independientemente de los valores reales de la métrica. El eje vertical se ampliará si los valores superan el rango mínimo, pero nunca será menor.

El resultado es el gráfico combinado de la GUI de Checkmk:

¿Te gustaría mostrar un Perf-O-Metro para una métrica en la fila de la lista de servicios? Podría tener este aspecto, por ejemplo:

Para crear ese Perf-O-Meter, necesitarás otra instancia, esta vez de la clase Perfometer, cuyo nombre empieza por el prefijo perfometer_:

Los Perf-O-Metros son un poco más complicados que los gráficos, ya que no tienen leyenda. Por tanto, es difícil mostrar un rango de valores, sobre todo cuando se muestran valores absolutos. Es más fácil mostrar un porcentaje, como en el ejemplo anterior:

En la documentación de la API de gráficos se pueden encontrar opciones aún más sofisticadas para implementar métricas en Perf-O-Meters, por ejemplo, con las clases Bidirectional y Stacked, que permiten visualizar varios Perf-O-Meters en uno.

En GitHub puedes encontrar el archivo de gráficos de este capítulo, que contiene, entre otras cosas, las definiciones métricas de los cuatro valores medidos y de los dos valores calculados.

Las especificaciones absolutas de tiempo (marcas de tiempo) se formatean con render.date() o render.datetime(). La información siempre se da como hora Unix, es decir, en segundos desde el 1 de enero de 1970, 00:00:00 UTC - el comienzo de la época Unix. Éste es también el formato utilizado por la función de Python time.time().

La ventaja de esta representación es que es muy fácil de calcular, por ejemplo el cálculo de un intervalo de tiempo, cuando se conocen las horas de inicio y fin. La fórmula es entonces simplemente duration = end - start. Estos cálculos funcionan independientemente de la zona horaria, los cambios de horario de verano o los años bisiestos.

render.date() sólo da salida a la fecha, render.datetime() añade la hora. La salida es según la zona horaria actual en la que se encuentre el servidor Checkmk que está ejecutando el check. Ejemplos:

No te sorprendas de que render.datetime(0) no muestre 00:00 como hora, sino 01:00. Esto se debe a que estamos escribiendo este Manual de usuario en la zona horaria de Alemania, que está una hora por delante de la hora UTC estándar (al menos durante el horario estándar, porque el 1 de enero no hay horario de verano).

Para los intervalos de tiempo (o lapsos de tiempo) también existe la función render.timespan(). A ésta se le da una duración en segundos y la emite de forma legible para el ser humano. Para lapsos de tiempo mayores, se omiten los segundos o los minutos. Si tienes un intervalo de tiempo en un objeto TimeDelta, utiliza la función total_seconds() para leer el número de segundos como un número en coma flotante.

Una frecuencia es efectivamente el recíproco del tiempo. La unidad canónica es Hz, que significa lo mismo que 1 / seg (el recíproco de un segundo). Un ejemplo de su uso es la frecuencia de reloj de una CPU:

Siempre que se trate de memoria de trabajo, archivos, discos duros, sistemas de archivos y similares, la unidad canónica es el byte. Como los ordenadores suelen organizar estas cosas en potencias de dos, por ejemplo en unidades de 512, 1024 o 65.536 bytes, se estableció desde el principio que un kilobyte no es 1000, y por tanto mil veces la unidad, sino 1024 (2 a la potencia de 10) bytes. Esto es ciertamente ilógico, pero muy práctico porque suele dar como resultado números redondos. El legendario Commodore C64 tenía 64 kilobytes de memoria y no 65.536.

Por desgracia, en algún momento a los fabricantes de discos duros se les ocurrió especificar los tamaños de sus discos en unidades de 1000. Como la diferencia entre 1000 y 1024 es del 2,4 % para cada tamaño, y éstas se multiplican, un disco de tamaño 1 GB (1024 por 1024 por 1024) se convierte de repente en 1,07 GB. Eso se vende mejor.

Esta molesta confusión sigue existiendo hoy en día y sigue produciendo errores. Para paliarla, la Comisión Electrotécnica Internacional (CEI) ha definido nuevos prefijos basados en el sistema binario. Así, hoy un kilobyte es oficialmente 1000 bytes y un kibibyte 1024 bytes (2 a la potencia de 10). Además, hay que decir mebibyte, gibibyte y tebibyte. Las abreviaturas son entonces KiB, MiB, GiB y TiB.

Checkmk se ajusta a esta norma y te ayuda con una serie de funciones de representación personalizadas para garantizar que siempre produzcas la salida correcta. Por ejemplo, está la función render.disksize(), especial para discos duros y sistemas de archivos, que produce su salida en potencias de 1000.

Cuando se trata del tamaño de los archivos, a menudo es habitual especificar el tamaño exacto en bytes sin redondear. Esto tiene la ventaja de que puedes ver muy rápidamente si un archivo ha cambiado aunque sea mínimamente o que dos archivos son (probablemente) iguales. Para ello se utiliza la función render.filesize():

Si quieres dar salida a un valor que no sea el tamaño de un disco duro o de un archivo, utiliza simplemente la función genérica render.bytes(). Con ella obtendrás la salida en las "clásicas" 1024 potencias de la notación oficial:

Los que trabajan en red tienen sus propios términos y formas de expresar las cosas. Y como siempre, Checkmk hace todo lo posible por adoptar la forma convencional de comunicarse en cada ámbito. Por eso hay tres funciones de representación diferentes para las tasas de datos y las velocidades. Lo que todas tienen en común es que las tasas se pasan en bytes por segundo, ¡aunque la salida real sea en bits!

render.nicspeed() representa la velocidad máxima de una tarjeta de red o de un puerto del switch. Como no son valores medidos, no es necesario redondear. Aunque ningún puerto puede enviar bits individuales, los datos están en bits por razones históricas.

Importante: No obstante, ¡también debes pasar aquí los bytes por segundo!

render.networkbandwidth() está pensada para una velocidad de transmisión medida realmente en la red. El valor de entrada es de nuevo bytes por segundo:

Cuando no se trata de una red y las velocidades de transmisión de datos siguen siendo de salida, los bytes vuelven a ser habituales. El caso más destacado es el de las velocidades de entrada/salida de los discos duros. Para ello se utiliza la función render.iobandwidth(), que en Checkmk funciona con potencias de 1000:

La función render.percent() representa un porcentaje -redondeado a dos decimales-. Es una excepción a las demás funciones, ya que no pasa el valor natural real -es decir, el cociente- sino el porcentaje real. Por ejemplo, si algo está medio lleno, no tienes que pasar 0.5 sino 50.

Como a veces puede ser interesante saber si un valor es casi cero o exactamente cero, los valores se marcan añadiendo un carácter "<", para los valores que son mayores que cero pero menores que 0,01 por ciento.

En conclusión, aquí tienes un resumen de todas las funciones de renderizado:

Si se produce una excepción en la monitorización o durante el descubrimiento de servicios en la Setup, la Summary contiene referencias al informe de fallos que se acaba de crear. Por ejemplo, tendrá el siguiente aspecto:

Si haces clic en el icono, aparecerá una página con detalles en la que podrás

El rastrear te ayuda como desarrollador a decidir si hay un error en el programa (por ejemplo, la llamada a una función inexistente) o datos del agente que no se han podido procesar como se esperaba. En el primer caso querrás corregir el error, en el segundo a menudo tiene sentido no hacer nada.

Por supuesto, enviar el informe sólo es útil para los plugins de check que forman parte oficialmente de Checkmk. Si pones tus propios plugins a disposición de terceros, puedes pedir a tus usuarios que te envíen los datos.

Si ejecutas tu check plugin utilizando la línea de comandos, no recibirás ninguna indicación del ID de ningún informe de fallos generado. Sólo verás el mensaje de error resumido:

Si añades la opción --debug como parámetro de llamada adicional, recibirás el rastreo del intérprete de Python:

Si el error no vuelve a producirse la próxima vez que llames a --debug, por ejemplo porque hay disponible una nueva salida del agente, también puedes ver los últimos informes de fallos en el sistema de archivos:

Hay dos archivos en cada una de estas carpetas:

En los ejemplos mostrados anteriormente, utilizamos la función print() para dar salida al contenido de las variables o a la estructura de los objetos para ti como desarrollador. Estas funciones para la salida de depuración deben eliminarse del Plugin de check plugin terminado.

Como alternativa a la eliminación, también puedes hacer que la salida de depuración sólo se muestre cuando se llame al check plugin desde la consola en modo de depuración. Para ello, importa el objeto de depuración de la caja de herramientas Checkmk y, si es necesario, la ayuda de formato pprint(). Ahora puedes producir la salida de depuración en función del valor del objeto de depuración:

Ten en cuenta que cualquier salida de depuración restante debe utilizarse con moderación y limitarse a pistas que ayuden a los usuarios posteriores con la depuración. Los errores de usuario obvios y previsibles (por ejemplo, que el contenido de la sección de agente indique que el plugin de agente se ha configurado incorrectamente) deben responderse con el estado UNKNOWN e incluir notas explicativas en el resumen.

La cuestión es cómo debes reaccionar si la salida del agente no tiene la forma que realmente esperas, ya sea del agente Checkmk o recibida a través de SNMP. Supongamos que siempre esperas tres palabras por línea, ¿qué debes hacer si sólo obtienes dos?

Bueno, si se trata de un comportamiento permitido y conocido por el agente, entonces, por supuesto, tienes que interceptarlo y trabajar con una distinción de casos. Sin embargo, si en realidad no está permitido, entonces lo mejor es actuar como si la línea constara siempre de tres palabras, por ejemplo, con la siguiente función de análisis sintáctico:

Si hay una línea que no consta exactamente de tres palabras, se genera una excepción y recibes el informe de fallos tan útil que acabamos de mencionar.

Si accedes a claves de un diccionario que se espera que falten ocasionalmente, puede tener sentido, por supuesto, reaccionar en consecuencia. Esto se puede hacer estableciendo el servicio en CRIT o DESCONOCIDO y poniendo una nota en el resumen sobre la salida del agente que no se puede evaluar. En cualquier caso, es mejor utilizar la función get() del diccionario para esto que capturar la excepción KeyError. Esto se debe a que get() devuelve un objeto de tipo None o un sustituto opcional que se debe pasar como segundo parámetro si la clave no está disponible:

¿Qué ocurre si el agente emite datos correctos, pero falta el item que hay que comprobar? Así, por ejemplo:

Si el item que buscas no está incluido, se ejecuta el bucle y Python simplemente lo abandona al final de la función sin devolver un resultado a través de yield. ¡Y ése es exactamente el enfoque correcto! Porque Checkmk reconoce que falta el item a monitorizar y genera el estado correcto y un texto estándar adecuado con UNKNOWN.

Si quieres simular determinadas salidas del agente, los archivos del directorio spool son muy útiles. Puedes utilizarlos para probar casos límite que, de otro modo, serían difíciles de recrear. O puedes utilizar directamente la salida del agente que provocó un informe de fallos para probar cambios en un plugin de checkin.

En primer lugar, desactiva tu plugin de agente habitual, por ejemplo, revocando su autorización de ejecución. A continuación, crea un archivo en el directorio /var/lib/check_mk_agent/spool/ que contenga la sección del agente (o las secciones esperadas del agente) que espera tu plugin de check plugin, incluida la cabecera de la sección, y que termine con Newline. La próxima vez que se llame al agente, se transferirá el contenido del archivo spool en lugar de la salida del plugin de agente.

Con algunos check plugins que utilizan items, es muy posible que en servidores grandes se generen varios cientos de servicios. Si no se utiliza una función de análisis separada, esto significa que hay que recorrer toda la lista de cientos de líneas para cada uno de los cientos de items. Por tanto, el tiempo necesario para buscar aumenta por el cuadrado del número de items listados, lo que significa decenas de miles de comparaciones para cientos de servicios. Si, por el contrario, la lista anidada se transfiere a un diccionario, el tiempo necesario para buscar un elemento sólo aumenta linealmente con el tamaño del diccionario.

En la wiki de Python encontrarás una vista general de los costes de búsqueda en distintos tipos de datos, incluyendo una explicación y la notación O. El uso de la función parse reduce la complejidad de la búsqueda de O(n) a O(1).

Como las versiones anteriores de este artículo no hacían uso de la función parse, debes identificar tales plugins de check y reescribirlos para que utilicen una función parse.