Monitorización de Windows

Instala el agente de Windows instalando el paquete MSI.

Antes de la instalación, debes descargar el paquete y transferirlo al host en el que se ejecutará el agente (por ejemplo, con scp o WinSCP).

Las ediciones comerciales cuentan con un módulo de software, Agent bakery, para empaquetar automáticamente agentes personalizados. Encontrarás una descripción detallada de esto en el artículo general sobre los agentes. La instalación del paquete MSI generado se realiza de la misma manera que se ha descrito anteriormente para el paquete incluido.

En Checkmk Ultimate puedes usar además Agent bakery para proporcionar a los paquetes de agentes una configuración de autoregistro, lo que facilita la creación automática de hosts. En este caso, el registro del agente se realiza automáticamente una vez instalado el paquete del agente, y ya no será necesario el registro manual, tal y como se describe en el siguiente capítulo.

Si utilizas Agent bakery, también puedes configurar las actualizaciones automáticas del agente. Estas actualizaciones se describen en su propio artículo.

Durante la instalación, el paquete MSI almacena los archivos específicos del programa en C:\Program Files (x86)\checkmk\service\ y los archivos específicos del host en C:\ProgramData\checkmk\agent\. No es necesario personalizar los archivos específicos del programa. Los archivos específicos del host se utilizan para almacenar Plugins, archivos de registro y de configuración, así como para configurar el comportamiento del agente.

Nota: De forma predeterminada, todo el directorio C:\ProgramData está oculto en Windows.

El agente lee tres archivos de configuración de forma sucesiva:

Si una opción se ha configurado en varios archivos, el último archivo leído determina el contenido de dicha opción. Por lo tanto, para trabajar manualmente con el agente, solo es relevante el último archivo de configuración check_mk.user.yaml, ya que es el último en leerse y, por lo tanto, tiene la última palabra. Si no se utiliza Agent bakery, este es, de hecho, el único archivo en el que se pueden realizar personalizaciones en la configuración del agente.

Como ya habrás podido deducir por la extensión de los archivos de configuración, se utiliza YAML como formato de archivo.

Tras instalar el agente, incluido el Controlador de agentes, el siguiente paso es el registro, que configura el cifrado TLS para que el servidor Checkmk pueda descifrar la salida cifrada del agente y mostrarla en la monitorización.

Hay una característica especial cuando el agente se ha instalado con el Controlador de agentes por primera vez. En tal caso, el agente cambiará al modo Legacy Pull sin cifrar, para que el servidor Checkmk no se quede sin datos de monitorización y pueda seguir mostrándolos. Esto se aplica tanto a una nueva instalación como a una actualización de un agente de la versión 2.0.0 y anteriores.

En la monitorización se verá así:

El sitio de Checkmk reconoce, a partir de la salida del agente, que el Controlador de agentes está presente y, por lo tanto, que el cifrado TLS es posible, pero aún no está habilitado. El servicio Check_MK Agent cambia al estado «WARN» y permanece así hasta que lo registres. Tras el registro, solo se utilizará el modo pull cifrado para la comunicación. El modo Legacy Pull se desactiva y permanecerá así. Sin embargo, se puede volver a activar mediante un comando si es necesario.

La situación será diferente si usas un agente heredado en un sistema Windows muy antiguo. Sin el Controlador de agentes, no es posible realizar el registro. Por lo tanto, para los agentes heredados, las únicas secciones relevantes del capítulo «Registro» son añadir el host a la configuración y luego a la monitorización. En el capítulo Pruebas y resolución de problemas debes omitir la prueba de llamada al Controlador de agentes, ya que esta no está disponible para un agente heredado. Dado que tampoco hay cifrado TLS sin el Controlador de agentes, tendrás que utilizar otros métodos de cifrado si es necesario. En este caso, recomendamos utilizar el cifrado integrado (simétrico) mediante la regla «Symmetric encryption (Linux, Windows)».

Nota: En el conjunto de reglas «Checkmk Agent installation auditing» encontrarás varios ajustes para comprobar el estado del agente y hacerlo visible en la monitorización. Entre otras cosas, aquí puedes especificar qué estado debe tener el servicio «Check_MK Agent» si aún no se ha realizado la configuración TLS.

Inmediatamente después de instalar el agente (también al actualizar un agente de la versión 2.0.0 o anterior), solo es posible la comunicación sin cifrar en el modo Legacy Pull. La transmisión de datos exclusivamente cifrada solo se puede activar una vez que se haya establecido una relación de confianza.

Una excepción a esto son los paquetes preconfigurados para el autoregistro y descargados a través de Agent bakery. Estos paquetes realizan el autoregistro automáticamente tras la instalación.

En todos los demás casos, debes realizar el registro manual inmediatamente después de instalar el agente. Este capítulo muestra cómo realizar el registro.

El registro y, por lo tanto, el establecimiento de la relación de confianza mutua se realiza bajo un usuario de Checkmk con acceso a la API-REST. Para ello, una buena opción es el usuario de automatización agent_registration, que solo tiene permiso para registrar agentes y se crea automáticamente con cada instalación de Checkmk. Puedes generar aleatoriamente la contraseña de automatización correspondiente (secreto de automatización) con el icono . Debes guardar el usuario antes de poder usar la nueva contraseña.

Nota: Dado que no hay un Controlador de agentes y, por lo tanto, no hay registro ni cifrado TLS, en sistemas Windows muy antiguos tendrás que usar métodos de cifrado alternativos si es necesario. En este caso, recomendamos usar el cifrado integrado (simétrico) mediante la regla Symmetric encryption (Linux, Windows).

Primero crea el nuevo host a través de Setup > Hosts > Add host. Un host debe existir en el entorno de configuración antes de poder registrarse.

En Checkmk Ultimate encontrarás la opción «Checkmk agent connection mode» en las propiedades del host, en la sección de agentes de monitorización. Aquí puedes activar el modo push para el agente Checkmk como alternativa al modo pull, que está disponible en todas las ediciones.

El registro se realiza mediante el Controlador de agentes cmk-agent-ctl, que proporciona una interfaz de comandos para configurar las conexiones. Puedes ver la ayuda de los comandos con cmk-agent-ctl help, así como para subcomandos específicos disponibles, por ejemplo, con cmk-agent-ctl help register.

El hecho de que el host esté configurado para el modo pull o el modo push no supone ninguna diferencia para los ejemplos de comandos. El Receptor del agente indica al Controlador de agentes en qué modo debe operar durante el registro.

Ahora ve al host que se va a registrar. Aquí tienes que realizar una solicitud al site de Checkmk con derechos de administrador:

El nombre del host que sigue a la opción --hostname debe ser exactamente el mismo que cuando se creó en la configuración. Las opciones --server y --site especifican el nombre del servidor Checkmk y del sitio. El nombre del servidor también puede ser la dirección IP; el nombre del sitio (aquí mysite) corresponde al que ves en la ruta de la URL de la interfaz web. Las opciones se completan con el nombre y la contraseña que usa el usuario de automatización. Si omites la opción --password, se te pedirá la contraseña de forma interactiva.

Precaución, trampa para los desprevenidos: si administras principalmente máquinas Unix, estás acostumbrado a encerrar rutas o parámetros con espacios o caracteres especiales entre comillas simples (apóstrofos, 0x27). Windows interpreta este carácter como parte de la llamada —en este caso, la contraseña— y el registro fallará. Utiliza comillas dobles (comillas, 0x22) en su lugar.

Si los valores especificados eran correctos, se te pedirá que confirmes la identidad del site de Checkmk al que quieres establecer una conexión. Para mayor claridad, hemos abreviado el certificado del servidor que hay que confirmar:

Confirma con «Y» para completar el proceso.

Si no aparece ningún mensaje de error, la conexión cifrada se habrá establecido. Ahora todos los datos se transmitirán en formato comprimido a través de esta conexión.

Si quieres desactivar la comprobación interactiva del certificado —por ejemplo, para automatizar completamente el registro—, puedes utilizar el parámetro adicional --trust-cert. En este caso, el certificado transferido se considerará automáticamente de confianza. Ten en cuenta que debes tomar otras medidas para verificar la integridad del certificado. Esto se puede realizar (manualmente o mediante un script) inspeccionando el archivo C:\ProgramData\checkmk\agent\registered_connections.json.

Checkmk Ultimate ofrece la posibilidad de crear hosts automáticamente al registrarlos. Para este autoregistro, además de un usuario con permiso para registrar hosts, necesitas al menos una carpeta configurada para albergar los hosts que se van a crear automáticamente.

Si se cumplen estas condiciones, también puedes realizar el registro, incluida la creación automática de hosts, a través de la línea de comandos.

Normalmente utilizarás el procedimiento de configuración de Agent bakery, que incluye el archivo de configuración C:\ProgramData\checkmk\agent\pre_configured_connections.json en el paquete del agente y que realiza el registro automáticamente durante la instalación. Por lo tanto, la llamada de comando que se presenta aquí se utiliza principalmente para pruebas y depuración, por ejemplo, para probar tus propias etiquetas del agente con la opción --agent-labels <KEY=VALUE>.

La mayor diferencia aquí es el comando modificado register-new, que se utiliza para solicitar el registro y la creación de un nuevo host en el site de Checkmk. El nombre del host es el que está almacenado en la variable del entorno %COMPUTERNAME%. La confirmación posterior del certificado es la misma que se muestra en la última sección.

Que el host se cree en modo pull, en modo push o no se cree en absoluto viene definido por tu configuración en el conjunto de reglas Agent registration. Tras un registro correcto, pueden pasar varios minutos antes de que el host aparezca en la monitorización.

El comando cmk-agent-ctl status muestra ahora exactamente una relación de confianza con el servidor Checkmk:

Si necesitas la información en un formato legible por máquina, añade el parámetro adicional --json para obtener la salida formateada como un objeto JSON.

Nota: Solo puede haber una relación de confianza entre el host y el site. Por ejemplo, si registras un host ya registrado mynewhost con un nombre diferente (mynewhost2) pero con la misma dirección IP, la nueva conexión sustituirá a la existente. La conexión de mynewhost al site se desconectará y ya no se proporcionarán datos del agente al host para la monitorización.

Para facilitar el registro de varios hosts, cualquier host en el que esté instalado el agente puede realizar un registro en nombre de otros hosts. El proceso de registro exporta un archivo JSON, que luego se puede transferir al host de destino e importar allí. De nuevo, como antes, el host registrado en la tarea ya debe estar configurado en el site.

En primer lugar, en cualquier host de la configuración, el registro se realiza por proxy. Aquí, por supuesto, el servidor Checkmk resulta muy útil, ya que suele ser el primer host en configurarse. Al igual que en el ejemplo anterior, puedes pasar la contraseña mediante la opción o se te pedirá de forma interactiva si omites la opción --password. En el ejemplo, redirigimos la salida JSON a un archivo:

A continuación, transferimos el archivo /tmp/mynewhost3.json al host que hemos registrado e importamos ese archivo:

Una vez completado el registro, realiza una prueba de conexión y un descubrimiento de servicios en la configuración del servidor Checkmk. A continuación, como último paso, incluye los servicios detectados en la monitorización activando los cambios.

Si la prueba de conexión falla, consulta el siguiente capítulo para obtener información sobre pruebas y resolución de problemas.

También puedes dar de baja un host.

En un host conectado al servidor Checkmk, puedes revocar la confianza. Aquí, en el siguiente comando, el Identificador Único Universal (UUID) que debes especificar es el que genera el comando `cmk-agent-ctl status`:

Para eliminar todas las conexiones del host y, además, restaurar el modo Legacy Pull, introduce el siguiente comando:

Después de eso, el agente se comportará como lo hacía tras la instalación inicial y antes del primer registro, y enviará sus datos sin cifrar.

Completa la baja en el servidor Checkmk: En la configuración, en la página «Properties of host», selecciona el elemento de menú «Host > Remove TLS registration» y confirma el mensaje.

Si prefieres usar la línea de comandos: En el servidor Checkmk, para cada conexión de un host que está en monitorización, hay un soft link con el UUID que apunta a la carpeta con la salida del agente:

En Checkmk Ultimate , puedes switchar los hosts del modo push al modo pull y viceversa. Esto puede ser necesario en casos concretos si hay cambios pendientes en la topología de la red, o si se va a realizar una actualización a Checkmk Pro —en la que solo es posible el modo pull—.

Primero, especifica el modo de acceso en la configuración, en las propiedades del host, con la opción «Checkmk agent connection mode». En el minuto siguiente, todos los servicios pasarán al estado «UNKNOWN», ya que no se están recibiendo datos de monitorización. A continuación, realiza un nuevo registro. Durante este nuevo registro, el Receptor del agente del servidor Checkmk indica al Controlador de agentes si espera datos en modo pull o modo push. Un check posterior con cmk-agent-ctl status mostrará entonces un nuevo UUID y un modo coherente con el cambio realizado en la configuración.

Para comprobar que la configuración se ha leído como se esperaba, ejecuta el programa del agente con la opción showconfig. Con esta opción, no solo obtendrás la configuración tal y como la utiliza actualmente el agente, sino que además siempre se mostrarán las variables del entorno y los archivos de configuración en uso.

Si solo te interesa una parte concreta de la configuración, puedes limitar la salida a esa parte específica. Aquí, por ejemplo, se checkea si las opciones de la sección ps se han configurado correctamente:

De esta forma obtienes una vista general rápida de cómo el programa del agente ha agrupado y utilizado los tres archivos de configuración diferentes. Los errores serán visibles de inmediato.

Si el registro de un host falla incluso antes de que se presente un certificado, conocer los métodos de comunicación puede ayudar a identificar el problema —y, por supuesto, a resolverlo.

Una vez introducido el comando «cmk-agent-ctl register», el Controlador de agentes solicita primero al servidor Checkmk el puerto del Receptor del agente mediante la API-REST. Como segundo paso, se establece una conexión con el Receptor del agente para solicitar el certificado. Puedes simular la primera solicitud en el host con un programa como curl:

El parámetro --insecure indica a curl que omita la comprobación del certificado. Este comportamiento refleja el comportamiento del Controlador de agentes en este paso. La respuesta es de solo unos pocos bytes y contiene el número de puerto del Receptor del agente. Para el primer site suele ser simplemente 8000, para el segundo 8001 y así sucesivamente.

Los problemas habituales relacionados con esta solicitud son:

Si la solicitud anterior falla, puedes cambiar la configuración de enrutamiento o del cortafuegos para habilitar el acceso.

En caso de que el host que intentas registrar utilice un proxy HTTP, curl lo utilizará, pero cmk-agent-ctl no lo hará con la configuración por defecto. Utiliza la opción adicional --detect-proxy para indicar a cmk-agent-ctl que utilice un proxy configurado a través de los ajustes del sistema.

Sin embargo, a menudo puede resultar más fácil identificar el puerto del Receptor del agente y anotarlo. Para ello, en el servidor Checkmk, iniciando sesión como usuario del site, ejecuta:

Ahora puedes especificar el puerto al introducir el comando de registro. Esto omite la primera solicitud a la API-REST. La comunicación se establece entonces directamente con el Receptor del agente sin rodeos:

El puerto 8000 también debe ser accesible desde el host. Si no lo es, aparecerá este mensaje de error:

Al igual que con el puerto 443 (o 80) mencionado anteriormente, ahora puedes ajustar la configuración de enrutamiento o del cortafuegos para que el host que se va a registrar pueda acceder al servidor Checkmk en el puerto del Receptor del agente (8000 o 8001…​)

En el caso de un registro en modo push, se aplica lo siguiente: Si el registro ha funcionado, la transferencia minuto a minuto de la salida del agente también se realizará con éxito.

Si las directivas de seguridad prohíben el acceso al Receptor del agente, sigue existiendo la posibilidad de utilizar el registro por proxy en el servidor Checkmk.

Dado que el programa del agente debe ejecutarse bajo la cuenta LocalSystem para entregar exactamente los datos que llegan a la monitorización, nunca debes iniciarlo en un shell. Si quieres examinar la salida del agente localmente, utiliza el Controlador de agentes en modo volcado (subcomando dump). Esto inicia el programa del agente con el entorno correcto y bajo el ID de usuario correcto, y luego muestra el resultado.

Dado que la salida puede ser un poco larga, el paginador «more» resulta muy útil en este caso. Puedes salir de él con la tecla «Q»:

Esto te permite verificar que los datos del programa del agente han llegado al Controlador de agentes. Esta salida aún no demuestra que también se pueda acceder al agente a través de la red.

Si en modo pull se ha comprobado que el programa del agente y sus plugins instalados se están ejecutando correctamente, puedes comprobar a continuación a través de netcat (o nc) si se puede acceder al puerto 6556 a través de la dirección IP externa del host:

El resultado de 16 indica si la conexión se ha establecido correctamente y si ahora puede tener lugar el protocolo de enlace TLS. Dado que todo lo demás aquí está cifrado con TLS, no es posible realizar una comprobación más detallada.

Si la comunicación entre el agente y el servidor Checkmk sigue sin estar cifrada (como en el modo Legacy Pull) o está y permanece sin cifrar (como en el agente heredado), obtendrás la salida completa sin cifrar del agente con este comando en lugar de 16.

Para realizar más diagnósticos en el servidor Checkmk, consulta el artículo general sobre los agentes de monitorización. En concreto, también puedes realizar una prueba de conexión utilizando la interfaz de Checkmk. Obtendrás el resultado en la caja «Agent:».

Si no obtienes ninguna información o solo un mensaje de error de timeout durante la prueba de conexión, como en el ejemplo anterior, debes check el estado de «Inbound Rules» del cortafuegos de Windows en el host.

El agente ya crea una regla en el cortafuegos de Windows durante su instalación, para que se pueda acceder al Controlador de agentes desde el exterior a través del puerto 6556. Cuando se utiliza el modo push, normalmente no es necesario cambiar su configuración. Si utilizas una configuración de cortafuegos muy estricta, las reglas de salida para las conexiones al servidor de monitorización deben configurarse de modo que al menos el puerto 8000 (para facilitar el registro, además el 80 o el 443) sea accesible.

En las versiones actuales de Windows, puedes encontrar el Controlador de Agentes (Windows Defender Firewall with Advanced Security) en la configuración de Windows (Settings > Windows Security) o iniciarlo ejecutando wf.msc desde la línea de comandos:

Si no encuentras esa entrada en la configuración del Cortafuegos de Windows, puedes añadirla en esta misma ubicación. Para ello, haz clic en «New Rule» en el menú «Action».

Esto abre un asistente para crear una nueva regla de firewall. Configura las cinco opciones de la siguiente manera:

Como alternativa, puedes automatizar este paso y configurar la regla directamente en la línea de comandos. Modifica el siguiente comando con tu ruta de instalación personalizada si es necesario:

Nota: El comando se ha dividido en cuatro líneas para facilitar la lectura.

En la carpeta «~/var/agent-receiver/received-outputs/» de tu sitio Checkmk, encontrarás un soft link para cada host registrado que utiliza el UUID del host como nombre. Para los hosts en modo push, este soft link apunta a la carpeta con la salida del agente; para los hosts en modo pull, apunta a un archivo inexistente con el nombre del host tal y como se utiliza en la monitorización.

En función de la antigüedad de la salida del agente almacenada en la caché, puedes determinar si la transmisión regular se ha realizado con éxito o si se está viendo interrumpida por problemas esporádicos de red, por ejemplo.

Además, puedes echar un vistazo al archivo de registro C:\ProgramData\checkmk\agent\log\check_mk en el host (las rutas pueden estar configuradas de forma diferente). Líneas como las siguientes indican problemas de conexión:

Si se ha configurado un host para el autoregistro con el conjunto de reglas Agent controller auto-registration y la opción Keep existing connections está establecida en no, cada vez que se reinicie el servicio cmk-agent-ctl-daemon (por ejemplo, al reiniciar un host), se eliminarán todas las demás conexiones, excepto la conexión configurada para el autoregistro. Esto afecta, por ejemplo, a los hosts en los que se establecieron conexiones a varios sitios antes de instalar el paquete del agente precompilado, o en los que se añadieron conexiones manualmente después de instalar el paquete del agente.

Puedes anular temporalmente este comportamiento configurando la variable keep_existing_connections como true en el archivo C:\ProgramData\checkmk\agent\pre_configured_connections.json del host. Puedes lograr un cambio permanente tras una actualización del paquete del agente configurando Keep existing connections como yes en el conjunto de reglas anterior.

Al registrar automáticamente un host, suelen pasar unos dos minutos antes de que el host aparezca en la monitorización.

La seguridad es un criterio importante para cualquier software, y la monitorización no es una excepción. Dado que el agente de monitorización está instalado en todos los servidores monitorizados, un problema de seguridad aquí tendría consecuencias especialmente graves.

Por eso se hizo hincapié en la seguridad en el diseño de Checkmk y ha sido un principio absoluto desde los primeros días de Checkmk: el agente no lee datos de la red. Y punto. Esto significa que es imposible que un atacante inyecte comandos o componentes de scripts a través del puerto de monitorización 6556.

Sin embargo, para un atacante, incluso una lista de procesos puede ser un primer indicio para sacar conclusiones sobre objetivos que merecen la pena. Por lo tanto, el cifrado de transporte entre el agente y el servidor Checkmk con Seguridad de la Capa de Transporte (TLS) es obligatorio. Aquí, el servidor Checkmk «hace ping» al host supervisado, que a continuación establece la conexión TLS con el servidor Checkmk y transmite a través de ella la salida del agente. Dado que solo los servidores Checkmk con los que existe una relación de confianza pueden iniciar esta transferencia de datos, no hay riesgo de que los datos caigan en manos equivocadas.

Para proteger la conexión TLS, Checkmk utiliza un certificado autofirmado que se sustituye automáticamente poco antes de que caduque su validez. El Controlador de agentes se encarga de realizar la renovación del certificado a tiempo antes de que caduque. Solo los agentes que hayan estado inactivos durante un periodo prolongado, es decir, sin un Controlador de agentes en ejecución, pueden perder su registro al caducar y deben volver a registrarse. La duración del certificado se puede especificar mediante la configuración global «Agent Certificates > Lifetime of certificates».

Nota: Dado que en los sistemas Windows muy antiguos no hay Controlador de agentes y, por lo tanto, no hay registro ni cifrado TLS, tendrás que elegir otras formas de cifrado si es necesario. En este caso, recomendamos utilizar el cifrado integrado (simétrico) mediante la regla Symmetric encryption (Linux, Windows).

La restricción del acceso a direcciones IP específicas también se puede configurar a través del cortafuegos. Sin embargo, el propio agente también ofrece la posibilidad de ignorar simplemente las solicitudes procedentes de direcciones IP externas. Solo tienes que añadir la siguiente restricción al archivo de configuración en las opciones globales. Ten en cuenta que puede haber otros parámetros configurados en el archivo de configuración antes o después de esto y que esto es solo un fragmento:

Como puedes ver en el ejemplo, puedes permitir cualquier número de subredes. Por ejemplo, con /32 especificas una subred de tamaño 1, de modo que solo se permite esta dirección, mientras que con 192.168.42.0/24 permites todas las direcciones entre 192.168.42.0 y 192.168.42.255.

En Agent bakery, puedes configurar las direcciones IP permitidas utilizando el siguiente conjunto de reglas: Setup > Agents > Windows, Linux, Solaris, AIX > Agent rules > Allowed agent access via IP address (Linux, Windows) .

Especialmente al actualizar el agente, puede ocurrir que el cifrado integrado (simétrico) esté activo, el cual es realizado por el propio programa del agente. Si el cifrado TLS y el cifrado integrado están activos al mismo tiempo, la entropía de los datos transmitidos es tan alta que la compresión, que está activa a partir de la versión 2.1.0, no guardará ningún dato transmitido, y sobrecargará las CPU tanto del host como del servidor Checkmk con procesos adicionales de cifrado y descifrado.

Por este motivo, debes desactivar el cifrado integrado inmediatamente después de switchar a TLS.

En el primer paso, desactiva el cifrado en la regla existente en Setup > Agents > Access to agents > Checkmk agent > Symmetric encryption (Linux, Windows).

En el segundo paso, en el host del agente, en el archivo de configuración C:\ProgramData\checkmk\agent\check_mk.user.yml, cambia el valor del parámetro encrypted a no:

En el tercer y último paso, utiliza la regla «Enforce agent data encryption» para especificar que el servidor Checkmk solo acepte datos cifrados mediante TLS. Para ello, selecciona el valor «Accept TLS encrypted connections only» en la regla.

Desactivar el cifrado con Agent bakery se hace así: Con el primer paso, cambiar la regla «Symmetric encryption (Linux, Windows)», ya casi has terminado. Solo tienes que compilar y distribuir los nuevos agentes. El archivo de configuración «C:\ProgramData\checkmk\agent\check_mk.user.yml» se modificará automáticamente y se incluirá en los paquetes de los agentes. Solo queda el tercer paso, es decir, modificar la regla «Enforce agent data encryption».

Tras la próxima actualización automática del agente, el cifrado del programa del agente será desactivado, pero el cifrado estará garantizado por el Controlador de agentes. Ten en cuenta que, tras la actualización automática del agente, solo los hosts registrados podrán proporcionar datos de monitorización.

El programa del agente check_mk_agent.exe contiene un conjunto completo de secciones que proporcionan datos de monitorización para varios check plugins, que luego son detectados automáticamente por el descubrimiento de servicios. Esto incluye toda la monitorización importante del sistema operativo.

Además, existe la posibilidad de ampliar el agente con plugins de agente. Se trata de pequeños scripts o programas que el agente ejecuta y que lo amplían con secciones adicionales que aportan más datos de monitorización. El proyecto Checkmk ofrece varios plugins de este tipo que, si se instalan y configuran correctamente, proporcionan automáticamente nuevos servicios en el descubrimiento de servicios.

¿Por qué estos Plugins no están simplemente integrados en el agente? Para cada uno de los Plugins hay una de las siguientes razones:

Todos los plugins incluidos para Windows se encuentran en el host supervisado, en el directorio de instalación del agente, dentro de la carpeta «C:\Program Files (x86)\checkmk\service\plugins». Se guardan ahí para que estén directamente disponibles. Como alternativa, los plugins para Windows también se encuentran en el servidor Checkmk, en la carpeta «~/share/check_mk/agents/windows/plugins».

También están disponibles en la página de descarga del agente, en el Menú de configuración (tal y como se describe en el capítulo Instalación), en la caja Plugins:

Para todos los plugins de agente que ofrecemos, hay check plugins correspondientes que pueden evaluar sus datos y generar servicios. Estos ya están instalados, de modo que los servicios recién encontrados se reconocen inmediatamente y se pueden configurar.

Nota: Antes de instalar un Plugin en el host, echa un vistazo al archivo correspondiente. A menudo encontrarás allí información importante sobre el uso correcto del Plugin.

La instalación en sí es muy sencilla: Copia el archivo en C:\ProgramData\checkmk\agent\plugins.

Una vez que el Plugin esté en el directorio correcto, el agente lo llamará automáticamente y se creará una nueva sección en la salida del agente. Esta suele tener el mismo nombre que el Plugin. Los Plugins complejos (por ejemplo, mk_oracle.ps1) incluso crean todo un conjunto de nuevas secciones.

Algunos Plugins necesitan un archivo de configuración en C:\ProgramData\checkmk\agent\config para funcionar. Para otros, la configuración es opcional (p. ej., mssql.vbs) y permite funciones especiales o personalizaciones. Otros simplemente funcionan así. Tienes varias fuentes para obtener información:

Para lenguajes especiales (de scripting), puede que sea necesario habilitarlos primero en la configuración del agente. Por ejemplo, los scripts de Python no se ejecutarán a menos que se habiliten explícitamente. Puedes hacerlo ampliando las extensiones de archivo en el archivo de configuración check_mk.user.yml, en la sección global, tal y como se muestra en el siguiente extracto:

Importante: El uso de estos Plugins requiere que los archivos también se puedan ejecutar en una línea de comandos normal sin rutas especiales. En el caso de Python, debe estar instalado correctamente y la ruta al intérprete debe estar presente en las variables del entorno. Las instrucciones sobre cómo configurar Python correctamente se pueden encontrar directamente en las páginas de la Python Software Foundation.

Cada Plugin se puede ejecutar en diferentes modos. Las siguientes opciones están disponibles para introducir en el archivo de configuración.

Una configuración para el Plugin de Veeam tendría, por ejemplo, este aspecto (el extracto está abreviado y solo contiene la parte relevante para el ejemplo):

Según la configuración de ejemplo anterior, el Plugin del directorio de datos C:\ProgramData\checkmk\agent\plugins se ejecuta de forma asíncrona cada cinco minutos (300 segundos) y puede ejecutarse durante un máximo de dos minutos (120 segundos). Si el Plugin alcanza este timeout, intentará obtener un resultado por segunda vez.

En las ediciones comerciales, los Plugins incluidos se pueden configurar a través de Agent bakery. Esto se encarga tanto de la instalación del Plugin en sí como de la creación correcta del archivo de configuración, en caso de que sea necesario.

Cada plugin de agente se configura mediante una regla de agente. Puedes encontrar los conjuntos de reglas adecuados en Setup > Agents > Windows, Linux, Solaris, AIX > Agent rules > Agent Plugins:

Dado que los plugins de agente son programas ejecutables, puedes ejecutarlos manualmente con fines de prueba y diagnóstico. Sin embargo, hay plugins que necesitan que el agente establezca ciertas variables del entorno para encontrar su archivo de configuración, por ejemplo. Si es necesario, configúralas manualmente si se necesitan en el script o programa.

Hay dos buenas razones para seguir usando los plugins de Nagios en Checkmk. Si has migrado tu monitorización de una solución basada en Nagios a Checkmk, puedes seguir usando check plugins antiguos para los que aún no hay un equivalente en Checkmk. En muchos casos, se trata de plugins escritos por ti mismo en Perl o en shell.

La segunda razón es la verdadera monitorización de extremo a extremo. Supongamos que tienes tu servidor Checkmk, un servidor web y un servidor de base de datos distribuidos en un gran centro de datos. En tal caso, los tiempos de respuesta del servidor de base de datos medidos desde el servidor Checkmk no son muy significativos. Es mucho más importante conocer estos valores para la conexión entre el servidor web y el servidor de base de datos.

El agente Checkmk ofrece un mecanismo sencillo para cumplir estos dos requisitos: el Remote Plugin Executor de Checkmk, o MRPE para abreviar. El nombre es deliberadamente una analogía con el NRPE de Nagios, que realiza allí la misma tarea.

El MRPE está integrado en el agente y se controla mediante varios archivos de configuración.

Como alternativa a la configuración directa en un host en el archivo de configuración específico del usuario, también puedes definir tus complementos MRPE directamente en el menú Setup. Para ello, utiliza el conjunto de reglas «Setup > Agents > Windows, Linux, Solaris, AIX > Agent > Agent rules > Execute MRPE checks». La entrada necesaria se creará automáticamente en el archivo de configuración de Agent bakery.