Monitorización de Windows

Instalas el agente de Windows instalando el paquete MSI.

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

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

A partir de Checkmk Cloud, puedes utilizar además el Agent bakery para proporcionar paquetes de agentes con una configuración para el autoregistro, que facilite la creación automática de hosts. En este caso, el registro del agente se realiza automáticamente una vez instalado el paquete de agente, y ya no será necesario el registro manual, como se describe en el capítulo siguiente.

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

Durante una 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 necesitas 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 y para configurar el comportamiento del agente.

Nota: Por defecto, todo el directorio C:\ProgramData está oculto en Windows.

El agente lee sucesivamente tres archivos de configuración:

Si una opción se ha configurado en varios archivos, el último archivo leído determina el contenido de esta opción. Por lo tanto, para el trabajo manual con el agente, sólo es relevante el último archivo de configuración check_mk.user.yaml, porque se lee en último lugar y, por lo tanto, tiene la última palabra. Si no se utiliza la Agent bakery, éste es, de hecho, el único archivo en el que se pueden hacer ajustes personalizados en la configuración del agente.

Como ya habrás reconocido 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 la salida cifrada del agente pueda ser descifrada por el servidor Checkmk y mostrada 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 no encriptado, para que el servidor Checkmk no quede aislado de los 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 o anterior.

Aparecerá así en la monitorización:

El site Checkmk reconoce en la salida del agente que el Controlador de agentes está presente y, por tanto, que la encriptación TLS es posible, pero aún no está activada. El servicio Check_MK Agent cambia al estado WARN y permanece así hasta que lo registres. Tras el registro, sólo se utilizará el modo pull encriptado para la comunicación. El modo Legacy Pull está desactivado y permanecerá así. Sin embargo, se puede volver a activar por comando si es necesario.

La situación será diferente si utilizas un agente heredado en un sistema Windows muy antiguo. Sin el Controlador de agentes no es posible el registro. Por 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, porque no está disponible para un agente heredado. Como tampoco hay encriptación TLS sin el Controlador de agentes, tendrás que utilizar otros métodos de encriptación si es necesario. En este caso recomendamos utilizar la encriptación integrada (simétrica) utilizando 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 la instalación del agente (también como actualización de un agente de la versión 2.0.0 y anteriores), sólo es posible la comunicación no encriptada en el modo Legacy Pull. Sólo se puede activar una transmisión de datos exclusivamente encriptada cuando se haya establecido una relación de confianza.

Una excepción son los paquetes preconfigurados para el autoregistro y descargados a través del Agent bakery. Estos paquetes realizan el registro 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 tanto, el establecimiento de la relación de confianza mutua se realiza bajo un usuario Checkmk con acceso a la API-REST. Para ello, una buena opción es el usuario de automatización agent_registration, que sólo tiene permiso para registrar agentes y se crea automáticamente con cada instalación de Checkmk. Puedes aleatorizar la contraseña de automatización correspondiente(secreto de automatización) con el icono . La función de aleatorización genera una nueva contraseña. Primero debes guardar el usuario antes de utilizar esta nueva contraseña.

Nota: Como no hay Controlador de agentes y, por tanto, no hay encriptación del registro ni TLS, en sistemas Windows muy antiguos tendrás que utilizar métodos de encriptación alternativos si es necesario. En este caso, te recomendamos que utilices la encriptación integrada (simétrica) 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 que pueda ser registrado.

A partir de Checkmk Cloud 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 utilizando el Controlador de agentes cmk-agent-ctl, que proporciona una interfaz de comandos para configurar las conexiones. Puedes mostrar la ayuda de comandos con cmk-agent-ctl help, también para subcomandos específicos disponibles, por ejemplo con cmk-agent-ctl help register.

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 funcionar durante el registro.

Ahora ve al host que se va a registrar. Aquí tienes que hacer 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 site. El nombre del host también puede ser la dirección IP, el nombre del site (aquí mysite) corresponde al que ves en la ruta URL de la interfaz web. Las opciones se completan con el nombre y la contraseña que utiliza el usuario de automatización. Si omites la opción --password, la contraseña se solicitará de forma interactiva.

Precaución, trampa para incautos: Si administras principalmente máquinas Unix, estará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 en su lugar comillas dobles(comillas, 0x22).

Si los valores especificados eran correctos, se te pedirá que confirmes la identidad del site Checkmk al que quieres conectarte. Para mayor claridad, aquí hemos abreviado el certificado del servidor a confirmar:

Confirma con Y para completar el proceso.

Si no aparece ningún mensaje de error, se habrá establecido la conexión encriptada. Todos los datos se transmitirán ahora de forma comprimida 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 será de confianza automáticamente. Ten en cuenta que debes tomar otras medidas para verificar la integridad del certificado. Esto se puede realizar (manualmente o mediante script) inspeccionando el archivo /var/lib/cmk-agent/registered_connections.json.

A partir de Checkmk Cloud, Checkmk ofrece la posibilidad de crear hosts automáticamente en el momento del registro. 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 llevar a cabo 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 /var/lib/cmk-agent/pre_configured_connections.json en el paquete del agente y que realiza el registro automáticamente durante la instalación. Por tanto, la llamada a la línea de comandos 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 subcomando register-new modificado, 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 almacenado en la variable del entorno %COMPUTERNAME%. La confirmación posterior del certificado es la misma que la mostrada en la última sección.

Si el host se crea en modo pull, push o no se crea en absoluto, lo define 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 se necesita 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: Sólo puede haber una relación de confianza entre host y 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 desde mynewhost al site se desconectará y no se suministrarán más datos del agente al host para su monitorización.

Para facilitar el registro de múltiples 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 puede transferirse al host de destino e importarse allí. De nuevo, como antes, el host registrado en el trabajo debe estar ya configurado en el site.

En primer lugar, en cualquier host de la Configuración, el registro se realiza por proxy. Aquí, por supuesto, resulta útil el servidor Checkmk, ya que suele ser el primer host que se configura. Como en el ejemplo anterior, puedes pasar la contraseña por opción o que te la pida interactivamente 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 para el que nos registramos 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 descubiertos en la monitorización activando los cambios.

Si la prueba de conexión falla, consulta el capítulo siguiente para obtener información sobre pruebas y solució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) a especificar es el emitido por el comando cmk-agent-ctl status:

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

Después, 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 la consulta.

Si prefieres utilizar 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:

A partir de Checkmk Cloud, puedes cambiar 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 un downgrade a CheckmkEnterprise, en el que sólo es posible el modo pull.

En primer lugar, 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 asumirán el estado DESCONOCIDO, ya que no se reciben 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 push. Un check posterior mediante 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, llama al programa del agente con la opción showconfig. Con esta opción no sólo obtendrás la configuración tal y como la utiliza actualmente el agente, sino que, además, se mostrarán siempre las variables del entorno, así como los archivos de configuración en uso.

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

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

Si el registro de un host falla incluso antes de que se presente el certificado, el conocimiento de 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 utilizando 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 se salte la comprobación del certificado. Este comportamiento refleja el comportamiento del Controlador de agentes en este paso. La respuesta es de sólo unos bytes, y contiene el número de puerto del Receptor del agente. Para el primer site suele ser sólo 8000, para el segundo 8001 y así sucesivamente. Los problemas más comunes en relación con esta solicitud son:

Si el comando curl falla, podrías cambiar la configuración de enrutamiento o del cortafuegos para permitir 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 ser 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 para el registro. De este modo, se omite la primera solicitud a la API-REST y la comunicación se realiza directamente con el Receptor del agente, sin rodeos:

El puerto 8000 también debe ser accesible desde el host. En caso de que no lo sea, obtendrás este mensaje de error:

Equivalente al puerto 443 (respectivamente 80) mencionado anteriormente, ahora puedes ajustar la configuración de enrutamiento o cortafuegos para que el host que se va a registrar pueda alcanzar el servidor Checkmk en el puerto del Receptor del agente (8000 u 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 tendrá éxito.

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

Como el programa del agente debe llamarse bajo la cuenta LocalSystem para entregar exactamente los datos que llegan a la monitorización, nunca debes iniciarlo en un intérprete de comandos. 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, a continuación, da salida al resultado.

Como la salida puede ser un poco más larga, aquí es muy útil el localizador "más", del que puedes salir con la tecla Q:

Esto te permite comprobar que los datos del programa del agente han llegado al Controlador de agentes. Esta salida todavía no demuestra que el agente también sea accesible a través de la red.

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

La salida 16 indica si la conexión se ha establecido correctamente y que ya puede tener lugar el handshake TLS. Como aquí todo lo demás está encriptado TLS, no es posible realizar un check más detallado.

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

Para obtener más diagnósticos que ejecutar 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 Checkmk. Obtendrás el resultado en la caja Agent:.

Si no obtienes ninguna información o sólo un mensaje de error de timeout durante la prueba de conexión, como en el ejemplo anterior, debes comprobar el 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 para que se pueda acceder al menos al puerto 8000 (para facilitar el registro, adicionalmente a los puertos 80 ó 443).

En las versiones actuales de Windows puedes encontrar el Windows Defender Firewall with Advanced Security a través de la Configuración de Windows (Settings > Windows Security) o iniciarlo llamando a wf.msc desde la línea de comandos:

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

Se abrirá un asistente para crear una nueva regla de cortafuegos. Establece las cinco opciones de la siguiente manera:

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

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

En la carpeta ~/var/agent-receiver/received-outputs/ de tu site Checkmk, para cada host registrado encontrarás un soft link 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 utilizado en la monitorización.

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

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 un host se ha configurado para el autoregistro con el conjunto de reglas Agent controller auto-registration y la opción Keep existing connections está configurada como no, siempre que se reinicie el servicio cmk-agent-ctl-daemon (por ejemplo, cuando se reinicia un host), se eliminarán todas las demás conexiones, excepto la conexión configurada para el autoregistro. Esto afecta, por ejemplo, a hosts en los que las conexiones a varios sites se configuraron antes de instalar el paquete de agente horneado, o las conexiones se añadieron manualmente después de instalar el paquete de agente.

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

Cuando se registra 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. Puesto que el agente de monitorización se instala en cada servidor monitorizado, 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. Estosignifica que es imposible que un atacante inyecte comandos o componentes de script a través del puerto de monitorización 6556.

Para un atacante, sin embargo, incluso una lista de procesos puede ser una primera aproximación para sacar conclusiones sobre objetivos que merezcan la pena. Por tanto, la encriptación del transporte entre el agente y el servidor Checkmk con Seguridad de la Capa de Transporte (TLS) es obligatoria a partir de la versión 2.1.0 de Checkmk. Aquí, el servidor Checkmk hace un "ping" al host monitorizado, que establece la conexión TLS con el servidor Checkmk y transmite la salida del agente a través de él. Como sólo 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 asegurar 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 renovar el certificado a tiempo, antes de que caduque. Sólo los agentes que hayan estado inactivos durante un periodo de tiempo prolongado, es decir, sin un Controlador de agentes en funcionamiento, pueden perder su registro al caducar y deben registrarse de nuevo. La vida útil del certificado puede especificarse mediante la configuración global Agent Certificates > Lifetime of certificates.

Nota: Como en los sistemas Windows muy antiguos no hay Controlador de agentes y, por tanto, no hay registro ni encriptación TLS, tendrás que elegir otras formas de encriptación si es necesario. En este caso, recomendamos utilizar la encriptación integrada (simétrica) mediante la regla Symmetric encryption (Linux, Windows).

La restricción de acceso a direcciones IP concretas también puede configurarse a través del cortafuegos. Sin embargo, el propio agente también ofrece la posibilidad de ignorar simplemente las peticiones procedentes de direcciones IP ajenas. Sólo 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 sólo 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 sólo 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 esté activa la encriptación integrada (simétrica), que realiza el propio programa del agente. Si la encriptación TLS y la encriptación integrada están activas al mismo tiempo, entonces 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 encriptación y desencriptación.

Por esta razón, debes desactivar el cifrado integrado inmediatamente después de cambiar a TLS.

En el primer paso, desactiva la encriptación 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 por no:

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

La desactivación de la encriptación con el Agent bakery procede así: con el primer paso, la modificación de la regla Symmetric encryption (Linux, Windows), casi has terminado. Sólo tienes que hornear y distribuir nuevos agentes. El archivo de configuración C:\ProgramData\checkmk\agent\check_mk.user.yml se modificará automáticamente por ti y se incluirá en los paquetes de agentes. Sólo queda el tercer paso, es decir, la modificación de la regla Enforce agent data encryption.

Ten en cuenta que, tras la actualización automática del agente, sólo los host registrados podrán proporcionar datos de monitorización.

El programa del agente check_mk_agent.exe contiene todo un conjunto de secciones que proporcionan datos de monitorización para varios check plugins que, a continuación, son encontrados 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 son llamados por el agente y lo amplían con secciones adicionales con datos de monitorización adicionales. El proyecto Checkmk proporciona una serie de 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 codificados en el agente? Para cada uno de los Plugins existe una de las siguientes razones:

Todos los plugins incluidos para Windows se encuentran en el host monitorizado, en el directorio de instalación del agente, en C:\Program Files (x86)\checkmk\service\plugins. Se almacenan allí para que estén disponibles directamente. Como alternativa, los plugins para Windows también se encuentran en el servidor Checkmk, en ~/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 (como se describe en el capítulo Instalación ) en la caja Plugins:

Para todos los plugins de agente que proporcionamos, existen check plugins coincidentes que pueden evaluar sus datos y generar servicios. Éstos 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.

Después, la instalación propiamente dicha es 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, que suele tener el mismo nombre que el Plugin. Los Plugins complejos (por ejemplo, mk_oracle.ps1) crean incluso todo un conjunto de secciones nuevas.

Algunos Plugin necesitan un archivo de configuración en C:\ProgramData\checkmk\agent\config para funcionar. Para otros, la configuración es opcional (por ejemplo, mssql.vbs) y permite características especiales o personalizaciones. Y otros simplemente funcionan así. Tienes varias fuentes para obtener información:

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

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

Cada Plugin puede ejecutarse en diferentes modos. Las siguientes opciones se pueden introducir en el archivo de configuración.

Una configuración para el Plugin de Veeam tiene, por ejemplo, este aspecto (el extracto está acortado y sólo contiene la parte relevante para el ejemplo):

Según la configuración ejemplar 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 funcionar durante un máximo de dos minutos (120 segundos). Si el Plugin se encuentra con este timeout, lo intentará una segunda vez para obtener un resultado.

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

Cada Plugin se configura mediante una regla de agente. Puedes encontrar los conjuntos de reglas apropiados 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 determinadas variables del entorno para encontrar su archivo de configuración, por ejemplo. Si es necesario, establécelas manualmente si se necesitan en el script o programa.

Hay dos buenas razones para seguir utilizando los plugins de Nagios en Checkmk. Si has migrado tu monitorización de una solución basada en Nagios a Checkmk, puedes seguir utilizando los antiguos check plugin para los que aún no existe un equivalente en Checkmk. En muchos casos se trata de plugins autoescritos en Perl o 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 proporciona un mecanismo sencillo para cumplir estos dos requisitos:el Ejecutor de Plugin Remoto de MK 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 plugins de 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 crea entonces automáticamente en el archivo de configuración de Agent bakery.