Supervisión de Linux

Instala el agente de Linux instalando el paquete RPM o DEB. Que necesites RPM o DEB depende de la distribución de Linux en la que quieras instalar el paquete:

Antes de la instalación, tendrás que descargar el paquete y transferirlo al host (por ejemplo, con scp o WinSCP) donde quieras que se ejecute el agente.

Una vez que hayas descargado el paquete RPM o DEB y, si es necesario, lo hayas copiado al host que se va a monitorizar usando scp, WinSCP u otros medios, la instalación se realiza con un solo comando.

El paquete RPM se instala como usuario root con el comando rpm -U:

Por cierto, la opción -U significa «actualizar», pero también puede realizar una instalación inicial correctamente. Esto también significa que puedes usar este comando para actualizar un agente existente a la versión actual, y también usar el mismo comando para futuras actualizaciones del paquete del agente.

La instalación del paquete DEB —y una actualización— se realiza como usuario root con el comando dpkg -i:

Aquí se instaló el paquete por primera vez en un host que antes no tenía ningún agente. Se ha creado el usuario cmk-agent y se ha configurado systemd. Abordaremos en un momento la advertencia provisional sobre insecure mode, es decir, el modo pull heredado.

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 de los paquetes empaquetados se realiza de la misma manera que se ha descrito anteriormente para los paquetes incluidos.

En Checkmk Ultimate puedes usar además Agent Bakery para proporcionar a los paquetes de agentes una configuración de registro automático, lo que facilita la creación automática de hosts. En este caso, el registro del agente se realiza automáticamente tras instalar el paquete del agente y ya no es 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.

Si se ha podido configurar el Agent Controller con unsystemde durante la instalación, el siguiente paso es el registro, que configura el cifrado TLS para que el servidor de 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 Agent Controller por primera vez. En ese caso, el agente cambia al modo pull heredado sin cifrar para que el servidor de Checkmk no se quede sin acceso a 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 y anteriores.

Recibirás un aviso de que se ha activado el modo pull heredado en la salida de comandos durante la instalación del agente. En la monitorización se verá así:

El sitio de Checkmk reconoce por la salida del agente que el Agent Controller está presente y, por lo tanto, 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 utiliza el modo pull cifrado para la comunicación. El modo pull heredado se desactiva y permanecerá así. Sin embargo, se puede volver a activar mediante un comando si es necesario.

El caso es diferente si el Agent Controller no se pudo registrar como daemon en systemd durante la instalación. Sin el Agent Controller, el registro no es posible y la única vía de comunicación sigue siendo el modo heredado.

En el siguiente capítulo, podrás determinar si puedes continuar con el registro probando el controlador de agentes y el entorno del sistema.

Nota: En el conjunto de reglas de Checkmk Agent installation auditing encontrarás varios ajustes para comprobar el estado del agente y hacerlo visible en la supervisió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 de 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 pull heredado. 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 registro automático y descargados a través de 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 lo tanto, el establecimiento de la relación de confianza mutua se realiza como 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.

El agente con el controlador de agentes requiere una distribución de Linux con systemd, más concretamente systemd en la versión 219 o posterior.

Es muy probable que tu host cumpla este requisito, ya que desde 2015 la mayoría de las distribuciones de Linux han adoptado systemd como su sistema de inicio, sustituyendo a otros sistemas de inicio como SysVinit, por ejemplo, SUSE Linux Enterprise Server a partir de la versión 12, openSUSE a partir de la versión 12.1, Red Hat Enterprise Linux a partir de la versión 7, Fedora a partir de la versión 15, Debian a partir de la versión 8 y Ubuntu a partir de la versión 15.04. Por desgracia, comparar solo el número de versión no ofrece certeza, ya que systemd puede faltar incluso en un sistema Linux actual si «solo» se ha actualizado a lo largo de los años.

Además de la versión de systemd, hay que cumplir algunos requisitos previos más, que se explicarán en este capítulo.

Atención: El modo push y el registro automático dependen necesariamente del Agent Controller y, por lo tanto, no se pueden utilizar en el modo legacy, algo a lo que nos referimos varias veces en este capítulo.

Por lo tanto, comprueba primero en el host en el que se va a instalar el agente si systemd está en ejecución y en qué versión:

El resultado del comando anterior muestra que está instalada la versión correcta de systemd. Si systemd no está en ejecución, o se está ejecutando en una versión demasiado antigua, no se puede utilizar el controlador de agente. Completa la configuración tal y como se describe en el artículo Supervisión de Linux en modo heredado.

Ahora comprueba si se puede iniciar el controlador de agentes:

El número de versión debería aparecer en la salida, por ejemplo:

En casos excepcionales, puede aparecer el siguiente mensaje de error:

El motivo es que tu Linux utiliza una arquitectura de ordenador diferente a x86_64, por ejemplo, la antigua x86 de 32 bits o ARM. En este caso, no se puede utilizar el controlador del agente.

Completa la configuración tal y como se describe en el artículo Supervisión de Linux en modo heredado.

El siguiente paso es averiguar qué programa está esperando solicitudes en el puerto 6556:

Aquí está: cmk-agent-ctl. Por lo tanto, se han cumplido los requisitos para una comunicación cifrada. Sin embargo, si dentro de los paréntesis aparecen systemd, xinetd o inetd, no se cumplen los requisitos previos para utilizar el Agent Controller. En tal caso, completa también la configuración tal y como se describe en el artículo «Monitorizar Linux en modo heredado».

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 de Checkmk como alternativa al modo pull, que está disponible en todas las ediciones.

El registro se realiza mediante el Agent Controller 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, y también 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 Agent Receiver indica al Agent Controller en qué modo debe operar durante el registro.

Ahora ve al host que se va a registrar. Aquí, con privilegios de root, envía una solicitud al sitio de Checkmk:

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 utiliza el usuario de automatización. Si omites la opción --password, se te pedirá la contraseña de forma interactiva.

Si los valores especificados son correctos, se te pedirá que confirmes la identidad del sitio Checkmk al que quieres conectarte. 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, se habrá establecido la conexión cifrada. 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 /var/lib/cmk-agent/registered_connections.json.

Checkmk Ultimate ofrece la posibilidad de crear hosts automáticamente al registrarse. Para el registro automático, además de un usuario con permiso para registrar hosts, necesitas al menos una carpeta configurada para albergar los hosts que se crearán 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 /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 lo tanto, la llamada de línea de comandos que se presenta aquí sirve principalmente para realizar pruebas y depuración, por ejemplo, para probar tus propias etiquetas de agente con la opción --agent-labels <KEY=VALUE>.

La mayor diferencia aquí es el subcomando modificado register-new, que se utiliza para solicitar el registro y la creación de un nuevo host en el sitio de Checkmk. El nombre del host es el que está almacenado en la variable de entorno $HOSTNAME. 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 sitio. 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 sitio se desconectará y ya no se enviarán datos del agente al host para su 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 sitio.

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:

Este proceso también se puede realizar en un solo paso utilizando una cadena de comandos en la que la salida de cmk-agent-ctl proxy-register se pasa como entrada a ssh hostname cmk-agent-ctl import:

Una vez completado el registro, realiza una prueba de conexión y una detección 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 pull heredado, introduce el siguiente comando:

A partir de ahí, el agente se comporta como lo hacía tras la instalación inicial y antes del primer registro, y envía sus datos sin cifrar.

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

Si prefieres la línea de comandos: En el servidor Checkmk, para cada conexión de un host que se está supervisando, hay un enlace simbólico con el UUID que apunta a la carpeta con la salida del agente:

En Checkmk Ultimate , puedes cambiar 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 Agent Receiver del servidor Checkmk indica al Agent Controller si espera datos en modo pull o push. Una comprobación posterior con cmk-agent-ctl status mostrará entonces un nuevo UUID y un modo coherente con el cambio realizado en la configuración.

El script del agente es un sencillo script de shell que obtiene datos de tu sistema y los muestra como texto sin formato. Puedes llamar a este script directamente desde la línea de comandos. Dado que la salida puede ser un poco larga, la opción less para desplazarse por la salida resulta muy útil aquí. Puedes salir de ella con la tecla Q:

Esto te permite comprobar si el script del agente, tus complementos y las comprobaciones locales están instalados correctamente.

Por cierto, no es necesario tener privilegios de administrador (root) para llamar al agente. Sin embargo, la salida carecerá entonces de cierta información que requiere privilegios de administrador para obtenerla (por ejemplo, información de rutas múltiples y las salidas de ethtool).

Para evitar que cualquier salida de error de complementos o comandos inactivos «contamine» los datos necesarios, el script del agente suele suprimir el canal de error estándar (STDERR). Si estás buscando un problema específico, puedes volver a habilitar el STDERR llamando al script del agente en un modo de depuración especial.

Antes, debes comprobar si el script del agente y el controlador del agente en modo volcado ofrecen una salida idéntica y, si es necesario, asegurarte de que el entorno sea idéntico. Esto se puede hacer configurando variables en una comprobación de complemento/local o en el shell. Puedes crear un volcado del entorno añadiendo la línea

a un archivo de complemento y, a continuación, comprobando el contenido del archivo tras la ejecución por parte del controlador del agente.

La información de depuración adicional se muestra entonces utilizando la opción «-d». También se mostrarán todos los comandos de shell ejecutados por el script. Para poder trabajar con «less» aquí, debes combinar la salida estándar (STDOUT) y el canal de error con «2>&1»:

Si el registro de un host falla incluso antes de que se presente un certificado, conocer las vías de comunicación puede ayudar a identificar el problema —y, por supuesto, a resolverlo.

Tras introducir el comando «cmk-agent-ctl register», el controlador del agente 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 sitio suele ser simplemente 8000, para el segundo 8001 y así sucesivamente.

Los problemas habituales relacionados con esta solicitud son:

Si falla la solicitud anterior, 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 predeterminada. 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 averiguar el puerto del Agent Receiver y anotarlo. Para ello, en el servidor Checkmk, inicia sesión como usuario del sitio:

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 de 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 políticas de seguridad de tu entorno no permiten el acceso al receptor del agente, sigue existiendo la posibilidad de utilizar el registro por proxy en el servidor Checkmk.

El controlador de agentes proporciona su propio subcomando «dump», que muestra la salida completa del agente tal y como llega a la supervisión:

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

En algunos casos, la salida tendrá este aspecto:

Esto ocurriría cuando el socket del agente no se está ejecutando en segundo plano, por ejemplo, inmediatamente después de una actualización. Reinicia este proceso en segundo plano:

Si cmk-agent-ctl dump vuelve a fallar, comprueba si hay algún programa escuchando en el puerto 6556 y cuál es:

Si la salida está vacía o hay un comando distinto de cmk-agent-ctl entre paréntesis, no se cumplen los requisitos del sistema para usar el Agent Controller. En este caso, completa la configuración tal y como se describe en el artículo Supervisar Linux en modo heredado.

Si en modo pull se ha comprobado que el script del agente y sus complementos instalados se ejecutan 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 que la conexión se ha establecido correctamente y que 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 falla una prueba de conexión remota, suele deberse a la configuración del cortafuegos. En este caso, configura iptables o nftables para permitir el acceso al puerto TCP 6556 desde el servidor Checkmk.

Si la comunicación entre el agente y el servidor Checkmk sigue sin estar cifrada (como en el modo pull heredado), o está y seguirá sin estar cifrada (como en el modo heredado), este comando te mostrará la salida completa sin cifrar del agente en lugar del 16.

Nota: Para más diagnósticos que se pueden ejecutar en el servidor Checkmk, consulta el artículo general sobre agentes de monitorización.

En la carpeta «~/var/agent-receiver/received-outputs/» de tu sitio Checkmk, encontrarás para cada host registrado un enlace simbólico que utiliza el UUID del host como nombre. Para los hosts en modo push, este enlace simbólico 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 caché, puedes determinar si la transmisión regular se ha realizado correctamente o si se está viendo interrumpida por problemas esporádicos de red, por ejemplo.

Además, puedes ver el estado de las últimas transmisiones y los intentos de transmisión en el host con el comando `systemctl status cmk-agent-ctl-daemon`. Líneas como las siguientes indican problemas de conexión:

Si se ha configurado un host para el registro automático 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 configuración de registro automático. 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 estableciendo la variable keep_existing_connections en 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 estableciendo Keep existing connections en 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 supervisión.

Si posteriormente se añade una conexión en modo pull a otro sitio a un host que inicialmente estaba configurado para el modo push, pasarán hasta cinco minutos antes de que se abra el puerto 6556. Puedes abrir el puerto inmediatamente reiniciando el servicio cmk-agent-ctl-daemon.

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 merezcan la pena. Por lo tanto, el cifrado de transporte entre el agente y el servidor de Checkmk con Seguridad de la Capa de Transporte (TLS) es obligatorio a partir de la versión 2.1.0 de Checkmk. Aquí, el servidor de Checkmk «hace ping» al host supervisado, que a continuación establece la conexión TLS con el servidor de Checkmk y transmite la salida del agente a través de ella. Dado que solo los servidores de 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 Agent Controller se encarga de renovar el certificado a tiempo antes de que caduque. Solo los agentes que hayan estado inactivos durante un periodo prolongado, es decir, sin un Agent Controller 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.

Dado que solo los servidores Checkmk autorizados pueden recuperar datos y los servidores no autorizados fallan tras unos pocos bytes de handshake, el riesgo de un ataque de denegación de servicio (DoS) es muy bajo. Por este motivo, actualmente no se prevé ninguna restricción de acceso adicional. Por supuesto, puedes bloquear el puerto 6556 contra el acceso no autorizado mediante iptables. Cualquier regla que pueda existir y que se haya transferido a los clientes a través de Agent Bakery para restringir el acceso a determinadas direcciones IP es ignorada por el controlador de agentes.

Especialmente al actualizar el agente, puede ocurrir que el cifrado integrado (simétrico) esté activo, el cual es realizado por el propio script 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 cambiar a TLS.

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

En el segundo paso, cambia el nombre del archivo de configuración de /etc/check_mk/encryption.cfg en el host del agente.

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 empaquetar y distribuir los nuevos agentes. El archivo de configuración «/etc/check_mk/encryption.cfg» 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, se desactivará el cifrado del script del agente, 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 script del agente /usr/bin/check_mk_agent contiene un conjunto completo de secciones que proporcionan datos de monitorización para varios complementos de comprobación, que luego son detectados automáticamente por el servicio de descubrimiento. Esto incluye toda la monitorización importante del sistema operativo.

Además, existe la posibilidad de ampliar el agente con complementos. Se trata de pequeños scripts o programas que el agente invoca y que lo amplían con secciones adicionales que contienen datos de monitorización extra. El proyecto Checkmk ofrece toda una serie de complementos de este tipo que, si están correctamente instalados y configurados, proporcionan automáticamente nuevos servicios a través del descubrimiento de servicios.

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

Todos los complementos incluidos con Linux y Unix se pueden encontrar en la página de descargas de los agentes, en el menú Configuración (tal y como se describe en el capítulo de instalación), en el cuadro Plugins:

Para todos los complementos de agente que ofrecemos, hay complementos de comprobación correspondientes que pueden evaluar los datos del agente y crear servicios. Estos ya están instalados, de modo que los servicios recién encontrados se pueden detectar y configurar de inmediato.

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

La instalación en sí es muy sencilla: Copia el archivo en /usr/lib/check_mk_agent/plugins. Asegúrate de que sea ejecutable. Si no lo es, utiliza un chmod 755; de lo contrario, el agente no ejecutará el complemento. Ten en cuenta que, especialmente si no transfieres los archivos a través de scp sino que los descargas vía HTTP desde la página de descargas, se perderá el permiso de ejecución.

Una vez que el complemento sea ejecutable y esté ubicado en el directorio correcto, el agente lo invocará automáticamente y se creará una nueva sección en la salida del agente. Esta sección suele tener el mismo nombre que el complemento. Los complementos complejos, como mk_oracle por ejemplo, incluso crean toda una serie de nuevas secciones.

Algunos complementos requerirán un archivo de configuración en /etc/check_mk/ para funcionar. Para otros, la configuración es opcional y permite activar funciones especiales o personalizaciones. Otros, sin embargo, funcionarán tal cual. Hay varias fuentes de información sobre un complemento:

Los complementos de agente suelen ejecutarse en secuencia. Como alternativa, puedes hacer que los complementos se ejecuten de forma asíncrona. Esto es muy útil si los complementos tienen un tiempo de ejecución prolongado y los datos de estado que se recopilan no necesitan regenerarse cada minuto de todos modos.

La ejecución asíncrona no se configura mediante un archivo, sino que se crea un subdirectorio dentro de /usr/lib/check_mk_agent/plugins cuyo nombre es un número: un número de segundos. Los complementos de este directorio no solo se ejecutan de forma asíncrona, sino que al mismo tiempo se especifica un tiempo de espera mínimo, en segundos, antes de que el complemento se vuelva a ejecutar. Si se vuelve a consultar al agente antes de que expire ese tiempo, este utiliza los datos almacenados en caché de la última vez que se ejecutó el complemento. Esto te permite configurar un intervalo más largo para el complemento que el habitual de un minuto.

El siguiente ejemplo muestra cómo cambiar el complemento «my_foo_plugin» de ejecución sincrónica a ejecución asincrónica con un intervalo de 5 minutos (o 300 segundos):

Nota: Algunos complementos implementan automáticamente la ejecución asíncrona. Esto incluye «mk_oracle». Instala estos complementos directamente en /usr/lib/check_mk_agent/plugins.

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

Cada complemento 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 complementos del agente son programas ejecutables, también puedes ejecutarlos manualmente con fines de prueba y diagnóstico. Sin embargo, hay complementos que necesitan que el agente establezca ciertas variables de entorno para encontrar su archivo de configuración, por ejemplo. Establece estas variables manualmente antes de la ejecución:

Algunos complementos también utilizan opciones de llamada especiales para la depuración. Solo tienes que echar un vistazo al archivo del complemento.

Hay dos buenas razones para seguir usando los complementos de Nagios en Checkmk. Si has migrado tu monitorización de una solución basada en Nagios a Checkmk, puedes seguir usando complementos de comprobación antiguos para los que aún no hay un equivalente en Checkmk. En muchos casos, se trata de complementos 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 de 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 configura mediante un sencillo archivo de texto, que debes crear como /etc/check_mk/mrpe.cfg. Allí especificas una llamada de plugin por línea, junto con el nombre que quieres que Checkmk utilice para el servicio que crea automáticamente para él. Aquí tienes un ejemplo:

Nota: Los complementos de Nagios no deben colocarse en el directorio /usr/lib/check_mk_agent/plugins. Este directorio está reservado para los complementos del agente. Aparte de este directorio, puedes elegir el que quieras, siempre y cuando el agente pueda encontrar y ejecutar los complementos allí.

Si ahora ejecutas el agente localmente, encontrarás una nueva sección para cada plugin llamada «<<mrpe>>», que contiene el nombre, el código de salida y la salida del plugin. Puedes comprobarlo con este práctico comando de «grep»:

Los códigos «0» y «1» de la salida representan los códigos de salida de los complementos y siguen el esquema convencional: 0 = OK, 1 = WARN, 2 = CRIT y 3 = UNKNOWN.

El resto lo hará ahora automáticamente Checkmk. Una vez que lances una detección de servicios para el host, los dos nuevos servicios aparecerán como disponibles. Quedará así:

Por cierto, debido a la sintaxis del archivo, el nombre no puede contener espacios. Sin embargo, puedes sustituir un espacio por %20 utilizando la misma sintaxis que en las URL (el código ASCII 32 para el espacio es el hexadecimal 20):

Ten en cuenta que todos los complementos que incluyas en mrpe.cfg se ejecutarán de forma sincrónica y en orden. Por este motivo, los complementos no deben tener un tiempo de ejecución demasiado largo. Si un complemento tarda demasiado, la ejecución de todos los demás se retrasará. Esto puede provocar que la ejecución completa del script del agente agote el tiempo de espera e impida que el host se supervise de forma fiable.

Si realmente necesitas complementos que tarden más en ejecutarse, deberías cambiarlos a ejecución asíncrona, como los complementos normales del agente, y así evitar este tipo de problemas. Esto se consigue especificando un tiempo en segundos durante el cual un resultado calculado debe seguir siendo válido. Para configurar un tiempo de espera de cinco minutos, establece la expresión «(interval=300)» después del nombre del servicio en «mrpe.cfg»:

Esta función tiene varias ventajas:

Así que esto te permite ejecutar pruebas que necesitan un poco más de tiempo de cálculo, así como a intervalos más largos, sin tener que configurar nada en el servidor de Checkmk.

Los usuarios de las ediciones comerciales también pueden configurar MRPE con Agent Bakery. De esto se encarga el conjunto de reglas «Setup > Agents > Windows, Linux Solaris, AIX > Agent Rules > Generic Options > Execute MRPE checks». Allí puedes configurar lo mismo que se ha descrito anteriormente. El archivo «mrpe.cfg» se generará automáticamente mediante Agent Bakery.

Los discos duros modernos casi siempre cuentan con S.M.A.R.T. (Self-Monitoring, Analysis and Reporting Technology). Este sistema registra continuamente datos sobre el estado del HDD o SSD, y Checkmk puede recuperar estos valores con el complemento smart y evaluar los más importantes. Para que el complemento funcione tras la instalación, deben cumplirse los siguientes requisitos:

Si se cumplen estos requisitos y el complemento está instalado, los datos se recuperan automáticamente y se añaden a la salida del agente. En Checkmk también puedes activar directamente los nuevos servicios:

Como se ve en la captura de pantalla, si cmd_timeout ocurre ocasionalmente, cambia el complemento a ejecución asíncrona a intervalos de unos minutos.

IPMI (Intelligent Platform Management Interface) es una interfaz para la gestión de hardware que también permite supervisar el hardware. Checkmk utiliza freeipmi para este fin, con el fin de acceder al hardware directamente y sin necesidad de red. freeipmi se instala desde las fuentes de paquetes y queda listo para su uso inmediato, de modo que los datos se transmitirán la próxima vez que se ejecute Checkmk.

Si freeipmi no está disponible o hay otras razones para no instalarlo, también se puede usar ipmitool. ipmitool suele estar ya presente en el sistema y solo hay que proporcionarle un controlador de dispositivo IPMI, como el que ofrece el paquete openipmi. De nuevo, no tienes que hacer nada más tras la instalación, y Checkmk recopilará los datos automáticamente.

Para el diagnóstico de errores, también puedes ejecutar las herramientas manualmente en un shell del host. Una vez que hayas instalado el paquete freeipmi, puedes comprobar sus funciones con esto:

Si se ha instalado ipmitool, puedes comprobar la salida de sus datos con el siguiente comando:

Muchos grandes fabricantes de servidores también ofrecen sus propias herramientas para recopilar la información del hardware y ponerla a disposición a través de SNMP. Para recuperar estos datos y proporcionárselos a Checkmk, deben cumplirse los siguientes requisitos previos:

Los nuevos servicios de monitorización de hardware compatibles con esto se detectan automáticamente y no se necesitan más complementos.

Se puede configurar una placa de gestión para cada host y se pueden recuperar datos adicionales a través de SNMP. Los servicios detectados de esta manera también se asignan al host.

Configurar la placa de gestión es muy sencillo. Solo tienes que introducir el protocolo, la dirección IP y los datos de acceso para SNMP en las propiedades del host y guardar estos nuevos ajustes:

Con la detección de servicios, los servicios recién detectados se activarán como de costumbre.

Cuando se desinstala el agente, se conserva el usuario cmk-agent creado por el script de instalación. Esto sirve como indicador para el script de posinstalación de que el agente ya estaba instalado en este sistema. Si este es el caso, no se activará el modo pull heredado durante una reinstalación posterior. Como resultado, tras ejecutar cmk-agent-ctl delete-all y reinstalar posteriormente el agente, no será posible establecer conexión en el puerto 6556.

Si deseas volver a habilitar el modo pull heredado sin cifrar, tendrás que habilitar este modo explícitamente.