Desarrollo de extensiones para Checkmk

Probablemente, la forma más sencilla de ampliar Checkmk es mediante el uso de local checks. Un programa ejecutado por el script del agente del host supervisado muestra el nombre, el estado y otra información necesaria en una sola línea. Para las local checks, Checkmk admite el descubrimiento automático de servicios. Se puede programar en cualquier lenguaje de programación sin necesidad de aprender una API.

Los check plugins basados en agentes evalúan los datos proporcionados por el agente Checkmk. Un plugin de agente recopila datos sin procesar y los prefiltra, pero no realiza un análisis de los datos recopilados. Esta recopilación de datos se puede realizar en cualquier lenguaje de programación. Es muy habitual que la salida sea un archivo JSON o en formato CSV. Sin embargo, también verás muchos plugins de agente que solo ejecutan comandos sin procesar del sistema Linux.

La evaluación se lleva a cabo entonces en el servidor Checkmk utilizando un check plugin escrito en Python, que hace uso de las API de Checkmk. De este modo, se puede determinar un estado de forma muy flexible. Es posible utilizar valores de umbral mínimo y máximo. Además, se pueden crear múltiples servicios y el estado de un servicio se puede verificar mediante múltiples comprobaciones. También es posible determinar tendencias e incluir valores anteriores. Los check plugins nativos admiten la creación automática de etiquetas y el inventario de HW/SW.

Los agentes especiales son una extensión de los check plugins basados en agentes. En este caso, ningún plugin de agente recopila los datos sin procesar, sino que es un programa que se ejecuta en el servidor Checkmk el que recupera los datos de otra fuente y los convierte al formato de agente de Checkmk. Los agentes especiales se utilizan, por ejemplo, cuando un dispositivo que se va a supervisar proporciona datos relevantes para la monitorización en formato JSON o XML a través de una API-REST. Para ver ejemplos del uso de los agentes especiales que incluye Checkmk, consulta AWS, Azure o VMware.

Al programar, accedes a dos API: para la configuración de puertos o similares, Checkmk proporciona una API que te permite especificar dichos ajustes en la configuración. Para la consulta de datos en sí, utiliza la API-REST de la fuente externa. La evaluación en el servidor Checkmk se lleva a cabo tal y como se describe en la sección anterior sobre check plugins nativos.

Una variante de los check plugins basados en agentes son los check plugins para SNMP. La diferencia aquí es que no se solicita ni se evalúa ninguna sección de agente, sino que el agente SNMP solicita explícitamente ciertos OID de SNMP.

Dado que el protocolo SNMP es intrínsecamente muy ineficiente, recomendamos utilizar SNMP solo si no es posible acceder a los datos de monitorización de otra forma. Por ejemplo, si un dispositivo también proporciona los mismos datos a través de una API-REST, deberías crear un agente especial para ello.

Los check plugins de Nagios se pueden encontrar en dos lugares en Checkmk: Como comprobaciones activas, para comprobar la accesibilidad de ciertos servicios desde el servidor Checkmk, y como una extensión MRPE de los agentes de Windows o Linux para comprobar dichos servicios desde un host —si no se puede acceder al host o a los servicios desde el servidor Checkmk.

Se puede programar en cualquier lenguaje.

Debido a una serie de desventajas, como la engorrosa resolución de problemas, solo recomendamos la reimplementación si se requiere una compatibilidad total con Nagios. En todos los demás casos, utiliza check plugins nativos o, para consultas sencillas, utiliza local checks. Puedes encontrar documentación detallada sobre los formatos de salida en Monitoring-Plugins.org.

Checkmk ofrece otro mecanismo más para generar datos del agente: Haz que un programa escriba directamente un archivo de texto en el formato del agente Checkmk. Almacenado en el directorio de spool, el agente Checkmk transfiere el contenido de este archivo junto con el resto de la salida del agente.

Con el directorio spool puedes, por ejemplo, hacer que los scripts de copia de seguridad escriban el estado y las estadísticas de una local check o de un check plugin directamente al finalizar. Esto evita tener que pasar por la evaluación de los archivos de registro.

Al desarrollar tus propios check plugins, los archivos spool ayudan a simular salidas concretas de tu plugin de agente.

El mecanismo piggyback se utiliza cuando un host tiene información sobre otro. A continuación, se asigna una sección de agente con un formato especial al host correspondiente al evaluar la salida del agente.

En el caso de las máquinas virtuales, el mecanismo piggyback se utiliza para agrupar los datos recopilados por el software de virtualización con los datos de la monitorización dentro de la máquina virtual.

Si has programado tus propias extensiones y quieres versionarlas y luego compartirlas, tienes la opción de empaquetar una extensión con sus archivos asociados en paquetes de extensión de Checkmk (MKPs). También debes usar este formato de paquete si quieres ofrecer estas extensiones en Checkmk Exchange.

En muchos casos, querrás proporcionar a los plugins de agente una configuración adicional. O quizá quieras ejecutar pequeños scriptlets de instalación específicos en función de los ajustes realizados en la configuración de Checkmk.

Si utilizas Agent bakery para la distribución de paquetes de agentes, la Bakery API te proporciona una interfaz de programación con la que los ajustes realizados en Checkmk se pueden transferir fácilmente a otros hosts que se están supervisando.