Desarrollo de extensiones para Checkmk

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

Los plugins de comprobación basados en agentes evalúan los datos suministrados 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 puede realizarse en cualquier lenguaje de programación. Es muy común la salida como un archivo JSON o en formato CSV. Sin embargo, también verás muchos plugins de agente que sólo llaman a comandos sin procesar del sistema Linux.

A continuación, la evaluación tiene lugar en el servidor Checkmk mediante 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 umbrales inferiores y superiores. Además, se pueden crear varios servicios y verificar el estado de un servicio mediante varias comprobaciones. También es posible determinar tendencias e incluir valores más antiguos. Los check plugins nativos admiten la creación automática de etiquetas y el inventario de HW/SW.

Una extensión de los plugins de monitorización basados en agentes son los agentes especiales. En este caso, no hay un plugin de agente que recoja los datos en bruto, sino un programa que se ejecuta en el servidor Checkmk y 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 a monitorizar proporciona datos relevantes para la monitorización como JSON o XML a través de una API-REST. Para ver ejemplos del uso de agentes especiales proporcionados con 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 propiamente dicha, utiliza la API-REST en la fuente externa. La evaluación en el servidor Checkmk se realiza como se describe en la sección anterior sobre los plugins de check nativos.

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

Como el protocolo SNMP es intrínsecamente muy ineficiente, te recomendamos que sólo utilices SNMP si no es posible otro acceso a los datos de monitorización. Por ejemplo, si un dispositivo también proporciona los mismos datos a través de una API-REST, debes crear un agente especial para ello.

Los plugins de check 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 Windows o Linux para comprobar dichos servicios desde un host - si el host/servicios no son accesibles desde el servidor Checkmk.

La programación es posible en cualquier lenguaje.

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

Checkmk proporciona otro mecanismo 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 spool, el agente Checkmk transfiere el contenido de este archivo 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 un check local o de un check plugin directamente al finalizar. Esto ahorra rodeos mediante la evaluación de archivos de registro.

Cuando desarrolles tus propios check plugin, los archivos spool te ayudarán a simular determinadas salidas de tu plugin de agente.

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

Para las máquinas virtuales, el mecanismo piggyback se utiliza para agrupar los datos recogidos 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 reenviarlas, tienes la opción de empaquetar una extensión con sus archivos asociados en paquetes de extensión Checkmk (MKP). También debes utilizar este formato de paquete si quieres ofrecer estas extensiones en el Checkmk Exchange.

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

Si utilizas el Agent bakery para la distribución de paquetes de agentes, el Bakery API te proporciona una interfaz de programación con la que los ajustes realizados en Checkmk pueden transferirse fácilmente a otros host que estén siendo monitorizados.