Monitorización de Linux

Instalas el agente de Linux instalando el paquete RPM o el 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 obtener el paquete y llevarlo al host (por ejemplo, con scp o WinSCP) donde quieras que se ejecute el agente.

Una vez que hayas obtenido el paquete RPM o DEB y, si es necesario, lo hayas copiado al host que vas a monitorizar mediante 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 correctamente una instalación inicial. Esto también significa que puedes utilizar este comando para actualizar un agente existente a la versión actual, y también utilizar 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:

En este caso, el paquete se instaló por primera vez en un host que anteriormente no tenía agente. Se ha creado el usuario cmk-agent y se ha configurado systemd. Abordaremos la advertencia provisional sobre insecure mode, es decir, el modo Legacy Pull, dentro de un momento.

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

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 de agentes se realiza automáticamente tras la instalación del paquete de agentes y ya no es 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.

Si el Controlador de agentes se pudo configurar con systemd durante la instalación, 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 después en la monitorización.

Hay una función especial cuando el agente se instala con el Controlador de agentes por primera vez. Entonces, el agente pasa 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 instalación nueva como a una actualización de un agente de la versión 2.0.0 y anteriores.

Recibirás un aviso del modo Legacy Pull activado en la salida del comando durante la instalación del agente. Tendrá este aspecto en la monitorización:

El site Checkmk reconoce en la salida del agente que el Controlador de agentes está presente y que, por tanto, el cifrado TLS es posible, pero aún no está activado. El servicio Check_MK Agent cambia al estado WARN y permanece así hasta que lo registres. Tras el registro, sólo se utiliza el modo pull cifrado 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.

El caso es distinto si el Controlador de agentes no se pudo registrar como daemon con systemd durante la instalación. Sin Controlador de agentes, el registro no es posible y la única ruta de comunicación sigue siendo el modo Legacy.

En el próximo capítulo, podrás determinar si puedes proceder al registro probando el Controlador de agentes y el entorno del sistema.

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 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 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 .

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 agente con el Controlador de agentes requiere una distribución de Linux con systemd, más concretamente systemd en una versión 219 o superior.

Hay muchas posibilidades de que este requisito se cumpla en tu host, ya que desde 2015 la mayoría de las distribuciones Linux han adoptado systemd como sistema de init, sustituyendo a otros sistemas de init 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 únicamente el número de versión no aporta seguridad, ya que systemd puede faltar incluso en un sistema Linux actual si "sólo" se ha actualizado a lo largo de los años.

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

Atención: El modo push y el autoregistro dependen necesariamente del Controlador de agentes y, por tanto, no se pueden utilizar en el modo Legacy, cuestión a la 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 se está ejecutando systemd y en qué versión:

La salida del comando anterior muestra que systemd está instalado en la versión correcta. Si systemd no se está ejecutando, o se está ejecutando en una versión demasiado antigua, no se puede utilizar el Controlador de agentes. Completa la configuración como se describe en el artículo Monitorización de Linux en modo Legacy.

Ahora comprueba si se puede iniciar el Controlador de agentes:

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

En raras ocasiones, puede aparecer el siguiente mensaje de error:

El motivo es que tu Linux utiliza una arquitectura de ordenador distinta de x86_64, por ejemplo la antigua x86 de 32 bits o ARM. En este caso, no se puede utilizar el Controlador de agentes. Completa la configuración como se describe en el artículo Monitorización de Linux en modo Legacy.

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

En este caso es cmk-agent-ctl. De este modo se han cumplido los requisitos para una comunicación encriptada. Sin embargo, si systemd, xinetd o inetd están entre paréntesis, no se cumplen los requisitos para utilizar el Controlador de agentes. En tal caso, completa también la configuración como se describe en el artículo Monitorizar Linux en modo Legacy.

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, con cmk-agent-ctl help register por ejemplo.

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í, con privilegios root, haz una petición al site 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 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.

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 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 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 el autoregistro, 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 tanto, la llamada a la línea de comandos que se presenta aquí sirve 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 $HOSTNAME. 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:

En caso de necesitar 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:

Este proceso también es posible en un solo paso utilizando una canalización en la que la salida de cmk-agent-ctl proxy-register se entrega como entrada a ssh hostname cmk-agent-ctl import:

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 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 el elemento de menú Host > Remove TLS registration y confirma la consulta.

En caso de que prefieras 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.

El script del agente es un simple script 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. Como la salida puede ser un poco larga, la opción less para desplazar la salida es muy útil en este caso. Puedes salir de ella con la tecla Q:

Esto te permite comprobar si el script del agente y sus plugins y local checks están instalados correctamente.

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

Para evitar que cualquier salida de error de plugins o comandos inactivos "contamine" los datos necesarios, el script del agente generalmente suprime el canal de error estándar (STDERR). Si buscas un problema concreto, puedes volver a activar el STDERR llamando al script del agente en un modo de depuración especial.

De antemano, debes comprobar si el script del agente y el Controlador de agentes en modo de volcado ofrecen una salida idéntica y, si es necesario, garantizar un entorno idéntico. Esto puede hacerse estableciendo variables en un plugin/local check o en el shell. Puedes crear un volcado del entorno añadiendo la línea

a un archivo Plugin y comprobando después el contenido del archivo tras su ejecución por el Controlador de agentes.

La información de depuración adicional se emite entonces utilizando la opción -d. También se emitirán todos los comandos del shell ejecutados por el script. Para que puedas trabajar aquí con less, 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 el certificado, conocer las formas de comunicación puede ayudar a identificar el problema y, por supuesto, a resolverlo.

Tras introducir 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 pocos bytes, que contienen 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, puedes 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 averiguar el puerto del Receptor del agente y anotarlo. Para ello, en la ejecución del servidor Checkmk, inicia sesión como usuario del site:

Ahora puedes especificar el puerto al introducir el comando para el registro. De este modo se omite la primera solicitud a la API-REST. La comunicación se produce entonces 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.

El Controlador de agentes proporciona su propio subcomando dump que muestra la salida completa del agente tal y como llega a la monitorización:

Esto te permite verificar que los datos del script 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.

En algunos casos, la salida tendrá este aspecto:

Este sería el caso 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 los paréntesis, no se cumplen los requisitos del sistema para utilizar el Controlador de agentes. En este caso, completa la configuración como se describe en el artículo Monitorizar Linux en modo Legacy.

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

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

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 Legacy Pull), o está y seguirá sin estar cifrada (como en el modo Legacy Pull), este comando te dará la salida completa del agente sin cifrar en lugar de 16.

Nota: Para obtener más diagnósticos que 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 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 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 se está interrumpiendo por problemas esporádicos de la red, por ejemplo.

Además, puedes mostrar el estado de las últimas transmisiones e 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 un host se ha configurado para el autoregistro con el conjunto de reglas Agent controller auto-registration y la opción Keep existing connections se establece en 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.

Si posteriormente se añade una conexión en modo pull a otro site a un host que inicialmente estaba configurado en 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. 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 se puede especificar mediante el ajuste global Agent Certificates > Lifetime of certificates.

Dado que sólo los servidores Checkmk autorizados pueden recuperar datos y que 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 esta razón, actualmente no está prevista ninguna otra restricción de acceso. Por supuesto, puedes bloquear el puerto 6556 contra el acceso no autorizado a través de iptables. Cualquier regla que pueda existir y que se haya transferido a los clientes a través del 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 esté activa la encriptación integrada (simétrica ), que realiza el propio script 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, cambia el nombre del archivo de configuración /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 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, modificar la regla Symmetric encryption (Linux, Windows), ya casi has terminado. Sólo tienes que empaquetar y distribuir los nuevos agentes. El archivo de configuración /etc/check_mk/encryption.cfg se modificará automáticamente por ti y se incluirá en los paquetes de agentes. Sólo queda el tercer paso, es decir, modificar la regla Enforce agent data encryption.

Tras la siguiente actualización automática del agente, la encriptación del script del agente queda desactivada, pero la encriptación está garantizada por el Controlador de agentes. Ten en cuenta que, tras la actualización automática del agente, sólo los hosts registrados podrán proporcionar datos de monitorización.

El script del agente /usr/bin/check_mk_agent contiene toda una serie de secciones que proporcionan datos de monitorización para varios check plugins, que luego son encontrados automáticamente por el descubrimiento de servicios. Esto incluye toda la monitorización importante para el 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 que contienen datos de monitorización adicionales. El proyecto Checkmk ofrece toda una serie de plugins de este tipo, que -si están correctamente instalados y configurados- proporcionan automáticamente nuevos servicios mediante un descubrimiento de servicios.

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

Todos los Plugin incluidos con Linux y Unix se pueden encontrar en el servidor Checkmk en ~/share/check_mk/agents/plugins.

También están disponibles en la página de descarga de agentes en el Menú de configuración (como se describe en el capítulo de instalación ) en la caja Plugins:

Para todos los plugins de agente que proporcionamos, hay check plugins coincidentes que pueden evaluar los datos del agente y crear servicios. Éstos ya están instalados, de modo que los servicios recién encontrados pueden detectarse y configurarse inmediatamente.

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

A continuación, la instalación propiamente dicha es sencilla: copia el archivo en /usr/lib/check_mk_agent/plugins. Asegúrate de que es ejecutable. Si no lo es, utiliza chmod 755, de lo contrario el agente no ejecutará el Plugin. Ten en cuenta que, sobre todo si no transfieres los archivos a través de scp, sino que los obtienes a través de HTTP desde la página de descarga, se perderá el permiso de ejecución.

Una vez que el plugin sea ejecutable y se encuentre 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 plugin. Los plugins complejos, como mk_oracle por ejemplo, crean incluso toda una serie de secciones nuevas.

Algunos Plugins necesitarán un archivo de configuración en /etc/check_mk/ para funcionar. Para otros, la configuración es opcional y habilita características especiales o personalizaciones. Y otros funcionarán simplemente tal cual. Hay varias fuentes de información sobre un Plugin:

Al igual que con MRPE, también puedes ejecutar los Plugins de forma asíncrona. Esto es muy útil si los Plugins tienen un tiempo de ejecución largo y, de todos modos, no es necesario regenerar cada minuto los datos de estado obtenidos.

La ejecución asíncrona no se configura a través de un archivo, sino que creas un subdirectorio dentro de /usr/lib/check_mk_agent/plugins cuyo nombre es un número: una cantidad de segundos. Los plugins de este directorio no sólo se ejecutan de forma asíncrona, sino que al mismo tiempo especificas un tiempo mínimo de espera con el número de segundos antes de que el plugin deba ejecutarse de nuevo. Si el agente vuelve a ser consultado antes de que expire el tiempo, utiliza los datos almacenados en caché de la última vez que se ejecutó el plugin. Esto te permite configurar un intervalo más largo para el plugin que el típico de un minuto.

El siguiente ejemplo muestra cómo cambiar el Plugin my_foo_plugin de ejecución síncrona a ejecución asíncrona con un intervalo de 5 minutos (o 300 segundos):

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

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

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, también 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. Establece estas variables manualmente antes de la ejecución:

Algunos plugins también utilizan opciones de llamada especiales para la depuración. Basta con que eches un vistazo al archivo del plugin.

Hay dos buenas razones para seguir utilizando los plugins de Nagios en Checkmk. Si has migrado tu monitorización desde 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 configura con un sencillo archivo de texto, que creas como /etc/check_mk/mrpe.cfg. En él especificas una llamada al Plugin por línea, junto con el nombre que quieres que utilice Checkmk para el servicio que crea automáticamente para él. He aquí un ejemplo:

Nota: Los plugins de Nagios no pueden colocarse en el directorio /usr/lib/check_mk_agent/plugins. Este directorio está reservado para los plugins de agente. Aparte de este directorio, eres libre de elegir siempre que el agente pueda encontrar y ejecutar los plugins 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 el siguiente y práctico comando grep:

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

El resto lo hará ahora Checkmk automáticamente. Una vez que invoques un descubrimiento de servicios para el host, los dos nuevos servicios aparecerán como disponibles. Tendrá el siguiente aspecto:

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 hexadecimal 20):

Ten en cuenta que todos los plugins que enumeras en mrpe.cfg se ejecutarán de forma sincrónica por orden. Por esta razón, los plugins no deben tener un tiempo de ejecución demasiado largo. Si un plugin necesita demasiado tiempo, la ejecución de todos los demás se retrasará. Esto puede provocar que la ejecución completa del script del agente se ejecute en un timeout e impida que el host se monitorice de forma fiable.

Si realmente necesitas que los Plugin se ejecuten durante más tiempo, debes cambiarlos a ejecución asíncrona y evitar así tales problemas. Esto puede conseguirse especificando un tiempo en segundos durante el cual un resultado calculado debe seguir siendo válido. Para configurar un timeout de cinco minutos, establece la expresión (interval=300) después del nombre del servicio en mrpe.cfg:

Este servicio tiene varias ventajas:

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

Los usuarios de las ediciones comerciales también pueden configurar MRPE con la Agent bakery. El responsable de ello es el conjunto de reglas Setup > Agents > Windows, Linux Solaris, AIX > Agent Rules > Generic Options > Execute MRPE checks. En él puedes configurar lo mismo que se ha descrito anteriormente. El archivo mrpe.cfg será generado automáticamente por la Agent bakery.

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

Si se cumplen estos requisitos y se instala el Plugin, 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 de vez en cuando aparece cmd_timeout, cambia el Plugin 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 la monitorización del hardware. Para ello, Checkmk utiliza freeipmi para acceder al hardware directamente y sin 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 llame a Checkmk.

Si freeipmi no está disponible o hay otras razones para no instalarlo, también se puede utilizar ipmitool.ipmitool suele estar ya presente en el sistema y sólo es necesario suministrarle un controlador de dispositivo IPMI, como el que proporciona el paquete openipmi. De nuevo, no necesitas hacer nada más tras la instalación, y los datos serán recogidos automáticamente por Checkmk.

Para el diagnóstico de errores, también puedes ejecutar las herramientas manualmente en un shell host. Una vez 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 proporcionan sus propias herramientas para recopilar la información de hardware y ponerla a disposición a través de SNMP. Para recuperar estos datos y proporcionarlos a Checkmk deben cumplirse los siguientes requisitos previos:

Entonces se detectan automáticamente los nuevos servicios de monitorización de hardware soportados y no se necesitan más Plugins.

Se puede configurar una placa de gestión para cada host y obtener datos adicionales mediante SNMP. Los servicios detectados de esta forma se asignan también al host.

Configurar la tarjeta de gestión es muy sencillo: basta con 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 un descubrimiento de servicios, los servicios recién descubiertos se habilitará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 al script post-instalación de que el agente ya estaba instalado en este sistema. Si este es el caso, no se activará el modo Legacy Pull durante una reinstalación posterior. Como resultado, después de ejecutar cmk-agent-ctl delete-all y reinstalar posteriormente el agente, no será posible ninguna conexión en el puerto 6556.

Si se desea volver a activar el modo Legacy Pull no encriptado, por ejemplo, para permitir la comunicación de un site 2.0.0 con un agente 2.2.0, tendrás que activar explícitamente este modo.