The commercial editions can update their agents on Linux, Windows and Solaris automatically.
This feature enables easy updating of the agents in the case of new Checkmk versions, and even a changed configuration of the agents can be applied automatically.
In this way you can take advantage of the Agent Bakery to apply individual configurations to hosts.
 |
This is a machine translation based on the English version of the article. It might or might not have already been subject to text preparation. If you find errors, please file a GitHub issue that states the paragraph that has to be improved. |
Las ediciones comerciales pueden actualizar sus agentes en Linux, Windows y Solaris automáticamente.
Esta función permite actualizar fácilmente los agentes cuando salen nuevas versiones de Checkmk, e incluso se pueden aplicar automáticamente cambios en la configuración de los agentes.
De esta forma, puedes aprovechar Agent bakery para aplicar configuraciones individuales a los hosts.
1. Configuración de las actualizaciones automáticas
Para implementar las actualizaciones, sigue estos pasos: Primero, abre Setup > Agents > Windows, Linux, Solaris, AIX y selecciona «Agents > Automatic updates»:
Consulta Prerequisites para ver una lista de los requisitos previos que deben cumplirse para que las actualizaciones automáticas funcionen correctamente.
Solo tienes que marcarlos en orden.
No olvides que puedes obtener más información sobre cada uno de estos items en Help > Show inline help.
Al hacer clic en 
, accederás directamente a la configuración que necesitas ajustar.
En concreto, debes realizar los ajustes descritos en las siguientes cinco secciones y, a continuación, activarlos a través de Master switch.
1.1. Creación de una clave de firma
El sistema está diseñado de manera que los agentes puedan descargar actualizaciones a través de HTTP o HTTPS desde su servidor de monitorización central. Dado que los agentes contienen código ejecutable, es especialmente importante protegerse contra la posibilidad de que un atacante envíe agentes falsificados. Para ello se utilizan claves de firma. Estas claves consisten en un par de claves pública y privada (el método de clave pública).
Puedes crear tantas claves de firma como quieras. Cada una de ellas está protegida con una frase de contraseña, que tendrás que introducir cada vez que firmes. Esto evita, por ejemplo, que un atacante que haya accedido a una copia de seguridad del servidor de monitorización pueda firmar agentes.
Crea aquí una clave de firma y anota la frase de contraseña.
|
Esta clave de firma no se podrá cambiar ni restaurar posteriormente. Si se pierde la clave, puede significar que haya que actualizar todos los agentes manualmente de nuevo. |
1.2. Configuración del Plugin de actualización
La actualización propiamente dicha la realiza un plugin de agente llamado «cmk-update-agent».
El agente lo invoca en un ciclo definible (por ejemplo, una vez por hora).
En ese momento, pregunta al servidor de implementación (tu sistema de monitorización central) si hay un nuevo paquete disponible para este host y, si es así, realiza la actualización.
Por supuesto, el Plugin debe estar presente y correctamente configurado en el agente. Para ello, amplía los agentes con este Plugin utilizando el conjunto de reglas «Agent updater (Linux, Windows, Solaris)». Puedes encontrar este conjunto de reglas haciendo clic en la entrada «Configuration of update plug-in» en la página «Automatic agent updates».
Ten en cuenta que el conjunto de reglas aquí sigue el principio de «la primera regla por parámetro prevalece». Esto te permite definir ajustes básicos de forma general para que no tengas que volver a configurarlos una y otra vez en las reglas más específicas. Además, la ayuda en línea proporciona más información sobre cada item tan pronto como lo actives.
A continuación encontrarás algunas explicaciones sobre cada punto.
Activación
Esta configuración debe estar habilitada (Deploy plugin …) para permitir que el plugin se añada al agente. Aquí, por ejemplo, se puede utilizar la herencia de reglas para establecer un valor predeterminado en una carpeta de nivel superior y anularlo para hosts o carpetas individuales según sea necesario.
Información del servidor de actualización
Aquí puedes introducir datos de configuración opcionales para la conexión del actualizador de agentes al servidor Checkmk. Si no se configura esta entrada, la información deberá introducirse más tarde al registrar el actualizador de agentes.
Carga
En el caso de una monitorización distribuida con configuración centralizada, el actualizador de agentes recibe por defecto su servidor de actualización correspondiente del sitio de Checkmk al que tiene la conexión. Esta opción se puede utilizar para configurar que se utilice de forma permanente el servidor de actualización introducido aquí y que se ignore el servidor de actualización automático.
Nombre DNS o dirección IP del servidor de actualización
Aquí introduces —con algunas excepciones— el nombre del servidor en el que estás configurando esta regla actualmente. Por lo tanto, puedes copiar la URL de la ventana actual de tu navegador.
Una excepción a este enfoque sería si los hosts afectados debieran «trasladarse» a otro servidor Checkmk. En esta situación, introduce aquí un servidor Checkmk diferente solo una vez. Consulta también más abajo en «Escenarios de aplicación». Introduce el nombre DNS bajo el cual se puede acceder al servidor Checkmk. Es importante que el host que se va a supervisar pueda resolver este nombre DNS y que se haya configurado como host en Checkmk. Si utilizas HTTPS, asegúrate de que el nombre del certificado coincida con el nombre del servidor Checkmk conocido por el host.
Nombre del site Checkmk del servidor de actualización
Aquí introduces —con algunas excepciones— el nombre del sitio en el que estás configurando actualmente esta regla. Una excepción a este enfoque sería si los hosts afectados debieran «trasladarse» a otro sitio de Checkmk. En tal caso, solo por esta vez, introduce aquí un sitio diferente. Consulta también más abajo en «Escenarios de aplicación». En una monitorización distribuida con configuración centralizada, el site en el que deseas registrarte también puede ser diferente del site central donde se configura esta regla.
Protocolo a utilizar para obtener actualizaciones
Si, como recomendamos, utilizas HTTPS, debes asegurarte de que el actualizador de agentes también disponga de un certificado CA (CA = Autoridad de Certificación) para verificar la conexión.
|
Dependiendo de la configuración del servidor, el uso de HTTPS (incluido el reenvío de HTTP a HTTPS) puede ser obligatorio. En tal caso, configurar esta regla para HTTP no tiene ningún efecto. |
Certificados para la verificación de HTTPS
Los certificados CA o autofirmados configurados aquí están disponibles para el actualizador de agentes para la verificación de conexiones HTTPS. Alternativamente, en el caso de una monitorización distribuida con configuración centralizada, los certificados también pueden ponerse a disposición del actualizador de agentes desde el sitio de Checkmk, o pueden importarse directamente durante la conexión mediante parámetros de línea de comandos.
|
Si la cadena de certificados del servidor está firmada por una CA pública, la conexión normalmente se puede verificar sin certificados importados. Sin embargo, en cuanto el actualizador de agentes tenga disponibles certificados importados de una de las fuentes mencionadas, ¡se ignorarán todas las demás autoridades de certificación CA! Si tienes problemas con la configuración de HTTPS, consulta las siguientes preguntas frecuentes. |
Intervalo para el check de actualizaciones
Aquí se especifica el intervalo en el que el actualizador de agentes consulta al servidor de monitorización configurado si hay actualizaciones disponibles. Mientras no haya expirado el intervalo especificado, se devuelve una llamada almacenada en la caché, para sobrecargar lo menos posible la red. Por lo general, tiene sentido utilizar un intervalo de no menos de 10 minutos, de lo contrario, existe un gran riesgo de que tu red se vea muy sobrecargada si tienes un gran número de agentes Checkmk. Si no estableces un valor aquí, se aplicará un valor por defecto de 1 hora.
Configuración del proxy
Esta configuración de regla también es opcional. El actualizador de agentes asume inicialmente que existe una conexión directa con el servidor Checkmk en el host de destino, incluso con la configuración de proxy activada, e ignora toda la configuración de proxy local. Si este es el comportamiento deseado, puedes omitir esta configuración de regla. De lo contrario, introduce la configuración de proxy manualmente o utiliza las variables del entorno existentes del host.
Formato del ejecutable (Linux)
Opcionalmente, puedes especificar cómo se añade el plugin de agente al paquete de instalación del agente. El comportamiento predeterminado de la regla depende del sistema de destino:
Linux (deb, rpm, tgz): No tienes que editar nada manualmente para estos sistemas; el actualizador de agentes se pasa como un binario de 64 bits. También puedes seleccionar opcionalmente un binario de 32 bits para sistemas heredados, o el antiguo script de Python. Nota: Para el binario necesitarás el paquete glibc (como mínimo la versión 2.5). Las distribuciones de Linux suelen cumplir estos requisitos desde 2006.
Windows: Para los hosts de Windows, Checkmk siempre distribuirá un ejecutable de 32 bits. Por lo tanto, esta regla se ignora por defecto. Nota: Si encuentras un binario de 64 bits del actualizador de agentes en cualquiera de tus hosts de Windows, esta versión corresponde a una versión anterior de Checkmk y no está actualizada.
Solaris: Aquí tampoco tienes que modificar nada. Checkmk utilizará el script de Python incluso si dejas el valor por defecto en el binario de 64 bits.
Otras arquitecturas: Si tienes paquetes para otras arquitecturas, como arm o ppc, configura esta opción manualmente en Python, ya que Checkmk no lo detecta automáticamente y no se ofrecen binarios para estas plataformas.
Si aún necesitas utilizar el antiguo script de Python, se aplican los siguientes requisitos al sistema:
Python 3 en la versión 3.4 o posterior
Los módulos de Python requests, PySocks y pyOpenSSL
Claves de firma que el agente aceptará
Selecciona al menos una clave de firma cuya firma deba ser aceptada por el actualizador de agentes. También puedes especificar opcionalmente varias claves. Esto puede ser necesario si, por ejemplo, quieres desactivar una clave antigua. Para ello, el actualizador de agentes del host debe aceptar ambas claves de forma provisional.
Tras esta última configuración, tu regla podría tener el aspecto de la siguiente captura de pantalla:
Guarda todas tus entradas haciendo clic en «
» (Guardar cambios) Save.
1.3. Generación y firma de agentes
A continuación, puedes compilar y firmar inmediatamente los agentes configurados de esta manera en una sola acción. Esto se debe a que las reglas recién creadas y personalizadas no aparecerán en los paquetes de instalación hasta que las hayas creado/compilado de nuevo.
Para ello, haz clic en la entrada «Baked agents» en la página «Automatic agent updates» y, a continuación, haz clic en «Bake and sign agents». Ahora debes introducir la frase de contraseña de la clave de firma. Después de hacer clic en «Bake and sign», el proceso de compilación se iniciará en segundo plano. Cuando este proceso haya finalizado, se te informará:
Todos los agentes firmados de esta manera se asignarán a un símbolo 
correspondiente.
Si has creado varias claves, firma con estas claves adicionales por separado.
Basta con que el actualizador de agentes del host compruebe si el nuevo paquete ha sido firmado con una de las claves que conoce.
1.4. Registrar el actualizador de agentes
En el siguiente paso, registra los hosts que se van a supervisar en el servidor Checkmk. Dado que el servidor Checkmk aún no confía en un nuevo host y el servidor aún no sabe que el host debe actualizarse automáticamente, el agente debe instalarse manualmente —solo una vez— en el host.
Para ello, primero ve a Setup > Agents > Windows, Linux, Solaris, AIX y descarga el paquete adecuado para el host desde Agent bakery. Asegúrate de que el paquete realmente contiene el plugin del actualizador de agentes.
Selección de un usuario para el registro
El registro debe realizarlo un usuario de Checkmk que tenga los permisos necesarios.
 |
Ten en cuenta que el usuario de automatización |
Puedes realizar el registro como administrador, es decir, con un usuario al que se le haya asignado el rol de administrador, ya que un administrador tiene todos los permisos. Sin embargo, si por motivos de seguridad necesitas utilizar un usuario al que solo se le permita registrar un actualizador de agentes, también puedes hacerlo. Debes crear dicho usuario manualmente, ya que Checkmk actualmente no lo crea automáticamente. Para ello, procede de la siguiente manera:
Primero, crea un nuevo rol en la página Setup > Users > Roles & permissions clonando el rol existente no_permissions.
Edita el nuevo rol asignándole nombres descriptivos en Internal ID y Alias y asignándole únicamente los siguientes permisos.
La forma más rápida de encontrarlos es buscarlos utilizando Find on this page en la larga lista de la página de permisos:
Register host & download monitoring agents of your hosts.
Register all hosts & download all monitoring agents.
Use the GUI at all
A continuación, en la página Setup > Users > Users, crea un nuevo usuario con un nombre descriptivo Username (por ejemplo, agent_updater_registration) y asigna solo el rol recién creado a este usuario.
Haz clic en Automation secret for machine accounts para crear el nuevo usuario como usuario de automatización.
Se te pedirá la contraseña de automatización correspondiente durante el registro.
Las siguientes secciones muestran el registro con un usuario de automatización agent_updater_registration creado de esta manera.
Finalización del registro
- Linux
Ahora copia el paquete del agente al host e instálalo con
rpmodpkg(instalación del paquete en Linux).Tras la instalación, encontrarás el complemento del actualizador de agentes en el directorio
/usr/lib/check_mk_agent/plugins/3600/cmk-update-agent. El valor del subdirectorio3600indica el intervalo de comprobación de actualizaciones en segundos (aquí, el valor por defecto de una hora). También hay un script con el mismo nombre almacenado en/usr/bin/, por lo quecmk-update-agenttambién está disponible como comando.Ahora ejecuta el actualizador de agentes con el argumento
register. Introduce la información necesaria en orden.Con el siguiente comando, ahora registras el actualizador de agentes desde un host Linux:
Como alternativa, puedes realizar el registro en modo no interactivo introduciendo los datos necesarios a través de las opciones de la línea de comandos. Una llamada a
cmk-update-agent register --helpaquí muestra las opciones configurables.- Windows
Ahora copia el paquete del agente al host e instálalo con
msiexec(instalación del paquete de Windows).Tras la instalación, el actualizador de agentes se integra en el agente de Windows
C:\Program Files (x86)\checkmk\service\check_mk_agent.exe. El actualizador se puede controlar con el comandocheck_mk_agent.exe updater.Ahora ejecuta el actualizador de agentes con el argumento
register. En Windows, esto debe hacerse en una ventana de comandos con derechos de administrador. Introduce la información necesaria en orden.Como el actualizador de agentes para hosts de Windows está integrado en el propio agente, el comando para registrarlo es el siguiente:
Como alternativa, puedes realizar el registro en modo no interactivo introduciendo los datos necesarios a través de las opciones de la línea de comandos. El comando completo para el registro es el siguiente:
La opción «
-S» se utiliza para pasar la contraseña de automatización del usuario de automatización.
Información general sobre el registro
Al registrarte, el Plugin también necesita el nombre del host tal y como se conoce en la monitorización. Esto no tiene por qué ser idéntico al nombre del host del ordenador. El nombre del host se almacena entonces localmente junto con la clave.
Para usar HTTPS, también debes configurar HTTPS en tu servidor de monitorización. HTTP es mucho más sencillo en este caso, pero no proporciona cifrado de la transmisión. Dado que el agente puede contener contraseñas en teoría, HTTPS es el método recomendado. No obstante, la autenticidad del agente queda garantizada de forma independiente mediante la firma.
El registro solo es necesario una vez. Al registrarse, el agente y el servidor acuerdan una clave secreta (secreto del host) conocida únicamente por este host. La contraseña que introduzcas no se almacena en ningún sitio.
Mientras que el modo interactivo solo consulta los campos que aún no están en ningún archivo de configuración, el modo no interactivo permite configurar todos los campos que se muestran en la ayuda y tiene la máxima prioridad para esta llamada. Las opciones que solo se guardan en
cmk-update-agent.statese sobrescribirán; sin embargo, las opciones decmk-update-agent.cfgno. Puedes encontrar más detalles sobre esto más abajo, en «Ver la configuración local».
Tras un registro correcto, el secreto del host se almacena en el agente, en el archivo /etc/cmk-update-agent.state.
En el servidor, se encuentra en ~/var/check_mk/agent_deployment/myhost.
A partir de ahora, el secreto del host permite que el host descargue su propio agente del servidor sin necesidad de contraseña.
No es posible descargar agentes de otros hosts, ya que estos podrían contener datos confidenciales.
1.5. Switch maestro
La distribución automática de agentes está desactivada globalmente por defecto.
Por último, actívala haciendo clic en Master switch.
Esto cambia la configuración global Activation of automatic agent updates en Setup > General > Global Settings > Automatic Agent Updates.
Ahora ya deberían haberse cumplido todas las condiciones. La tabla «Prerequisites» debería tener ahora este aspecto:
A partir de ahora, el agente informará al final de cada intervalo de actualización configurado y buscará una nueva versión del agente. Si hay una nueva versión disponible —y firmada—, se descargará e instalará automáticamente.
Al mismo tiempo, la tabla Master switch también es una forma de desactivar el proceso de actualización de forma global.
El vídeo, que se presentó en la Checkmk Conference #3 (2017), ofrece una guía paso a paso en el siguiente enlace. Esta no es la última versión, pero el procedimiento básico no ha cambiado: Las nuevas actualizaciones automáticas del agente
1.6. Desactivar las actualizaciones automáticas para un host
Si quieres excluir un host de las actualizaciones automáticas, usa el conjunto de reglas «Agent updater (Linux, Windows, Solaris)» para ajustar su configuración de modo que el complemento de actualización quede desactivado allí. ¡La próxima vez que se realice una actualización periódica, el agente eliminará su propio actualizador de agentes!
No hace falta decir que, posteriormente, la actualización solo se podrá reactivar instalando manualmente un nuevo paquete del agente. Sin embargo, el registro permanece intacto y no es necesario realizar la renovación.
2. Limitar las actualizaciones a hosts específicos
Antes de implementar un nuevo agente en un gran número de hosts, seguramente querrás probarlo primero con un número más reducido de hosts. Este paso importante evita un posible error de graves consecuencias.
Para esta función, usa la caja del centro en la página Automatic agent updates:
Se aplica una conjunción lógica (AND) a las condiciones: solo los hosts que cumplan todos los criterios seleccionados recibirán la actualización. Una vez que hayas establecido aquí las condiciones para seleccionar los hosts, puedes usar el campo «Test hostname before activation» para introducir nombres de hosts individuales y checkear si las actualizaciones para estos hosts se han habilitado o no.
Importante: En los hosts que aún no van a recibir actualizaciones automáticas, el paquete instalado no debe contener el plugin de actualizador de agentes; de lo contrario, el plugin te avisará regularmente de que el host aún no se ha registrado.
3. Diagnósticos
Hay bastantes fuentes de información para saber si todas las actualizaciones funcionan como se espera.
3.1. Estadísticas de distribución de agentes
Esta vista general muestra cómo se comportan los hosts individuales en la actualización del agente.
La ayuda en línea ofrece más explicaciones.
Al hacer clic en «
» (Estado de los hosts), obtienes una lista detallada de los hosts individuales.
También puedes acceder a la lista completa de todos los hosts registrados a través de la vista de tabla «Monitor > System > Agent update status» (Lista de hosts).
Allí podrás buscar hosts individuales.
En esta lista también encontrarás documentación sobre cómo comienza el hash de un agente, qué agente está destinado a un host (Target Agent), qué agente se descargó más recientemente del host (Downloaded Agent), y qué agente está instalado actualmente en el host (Installed Agent). De esta forma, siempre puedes ver si se han cumplido las especificaciones o en qué punto del proceso se encuentra actualmente. Cabe señalar aquí que la información de estado aparece a la izquierda directamente en la comunicación entre Agent bakery y el actualizador de agentes, mientras que los campos Update Check y Update Check Output provienen del Plugin del actualizador de agentes al consultar el agente del host, y que, debido al almacenamiento en caché (definido por el intervalo de tiempo de consulta), estos pueden actualizarse en un momento diferente.
3.2. El servicio «Check_MK Agent »
Si ha instalado el plugin de actualizador de agentes en un agente, este mostrará periódicamente el estado actual de la actualización en forma de datos de monitorización. El descubrimiento de servicios genera un nuevo servicio con el nombre Check_MK Agent en el host. Esto refleja de nuevo el estado actual de la actualización. De esta forma, se te notificará cualquier problema con las actualizaciones.
Entre otras cosas, el estado del servicio indica cómo se evalúa el estado de la clave de firma. Son posibles los siguientes estados:
WARN: El certificado de la clave de firma está dañado, ya no es inválido o dejará de serlo en los próximos 90 días.
CRIT: No hay ningún certificado válido para la clave de firma o el certificado perderá su validez en los próximos 30 días.
3.3. Ver la configuración local
El comportamiento del actualizador de agentes viene determinado por los dos archivos cmk-update-agent.cfg y cmk-update-agent.state.
Siempre se aplica que los valores definidos en el archivo .cfg tienen prioridad sobre los del archivo .state.
Si el actualizador de agentes muestra un comportamiento inesperado, a veces vale la pena echar un vistazo a la configuración.
También hay una función muy útil si ejecutas el actualizador de agentes directamente desde la línea de comandos:
3.4. Mensajes de registro
En caso de que surja algún problema, también encontrarás datos de registro de las actualizaciones en el host que se va a realizar la monitorización.
En Linux, cmk-update-agent registra información importante en syslog, como advertencias y errores:
Jul 02 13:59:23 myhost [cmk-update-agent] WARNING: Missing config file at ./cmk-update-agent.cfg. Configuration may be incomplete.
Jul 02 13:59:23 myhost [cmk-update-agent] ERROR: Not yet registered at deployment server. Please run 'cmk-update-agent register' first.En Linux y en Windows puedes encontrar un archivo de registro más detallado de cmk-update-agent.log, que incluye salida de depuración y posibles rastreadores:
2026-01-16 07:49:23,295 [288229] DEBUG: Starting Checkmk Agent Updater v2.4.0p19
2026-01-16 07:49:23,295 [288229] DEBUG: Updating the certificate store "/var/lib/check_mk_agent/cmk-update-agent/cas/all_certs.pem"...
2026-01-16 07:49:23,297 [288229] INFO: Updated the certificate store "/var/lib/check_mk_agent/cmk-update-agent/cas/all_certs.pem" with 1 certificate(s)
...
2026-01-16 07:49:23,326 [288229] DEBUG: Successfully read /var/lib/check_mk_agent/cmk-update-agent/cmk-update-agent.state.
2026-01-16 07:49:23,326 [288229] DEBUG: Successfully read /var/lib/check_mk_agent/cmk-update-agent/cmk-update-agent.state.
2026-01-16 07:49:23,327 [288229] DEBUG: Saved deployment status to /var/lib/check_mk_agent/cmk-update-agent/cmk-update-agent.state.
2026-01-16 07:49:23,327 [288229] INFO: Target state (from deployment server):
2026-01-16 07:49:23,327 [288229] INFO: Agent available: True
2026-01-16 07:49:23,327 [288229] INFO: Signatures: 1
2026-01-16 07:49:23,327 [288229] INFO: Target hash: 37221b87f5cb46a2
2026-01-16 07:49:23,327 [288229] INFO: Agent 37221b87f5cb46a2 already installed.
2026-01-16 07:49:23,340 [288229] DEBUG: Caught Exception:
Traceback (most recent call last):
File "cmk_update_agent.py", line 1733, in main
File "cmk_update_agent.py", line 714, in run
File "cmk_update_agent.py", line 1372, in _run_mode
File "cmk_update_agent.py", line 1071, in _do_update_as_command
File "cmk_update_agent.py", line 1150, in _do_update_agent
File "cmk_update_agent.py", line 1221, in _check_signatures
Exception: No valid signature found.En ambos sistemas también puedes usar la opción de línea de comandos --logfile LOGFILE para especificar una ruta alternativa para el archivo de registro.
4. Casos de uso
4.1. Desactivar las actualizaciones automáticas del host
Si quieres eliminar un host de las actualizaciones automáticas, modifica su configuración con el conjunto de reglas «Agent updater (Linux, Windows, Solaris)» para desactivar allí el plugin de actualización. ¡En la siguiente actualización periódica, el propio agente eliminará su propio actualizador de agentes!
¡No hace falta decir que la actualización solo se puede reactivar instalando manualmente un nuevo paquete del agente! El registro se mantiene y no es necesario realizar su renovación.
4.2. Migración a un nuevo site de monitorización
Si quieres pasar a un nuevo sitio de Checkmk en una configuración de un solo sitio sin perder los hosts registrados en el servidor, ten en cuenta que, para que el proceso de actualización del agente se realice correctamente, la siguiente información sobre el servidor y el host debe coincidir:
El nombre con el que se realiza la monitorización y el registro del host.
El secreto del host, que se asignó automáticamente durante el registro.
La firma utilizada para firmar los agentes.
Para ello, sigue estos pasos:
Primero, añade a la monitorización todos los hosts cuya información de registro se vaya a migrar al nuevo site. Asegúrate de que los hosts del nuevo site se monitorizan con el mismo nombre. A continuación, copia la carpeta
~/var/check_mk/agent_deploymentdel site de monitorización antiguo al nuevo.Exporta las claves de firma que aceptan los agentes instalados en los hosts. Las claves de firma se pueden exportar e importar usando Setup > Agents > Windows, Linux, Solaris, AIX > Agents > Signature keys.
Importa estas claves de firma del paso 2 al nuevo site de monitorización.
Configura la regla del actualizador de agentes en el nuevo site de monitorización siguiendo las instrucciones y firma los agentes compilados con las claves de firma importadas.
Por último, en la regla del actualizador de agentes del sitio antiguo, configura los campos del servidor de actualización y el nombre del sitio Checkmk de acuerdo con tu nuevo sitio de monitorización, y vuelve a compilar los agentes. Nota: Comprueba en este punto que has especificado todo correctamente antes de volver a compilar los agentes.
Tan pronto como las próximas actualizaciones automáticas se apliquen a los hosts, el antiguo sitio de monitorización quedará bloqueado. A partir de ese momento, los hosts que se van a monitorizar solo responderán al nuevo servidor Checkmk. Tras la segunda actualización automática, el agente se instalará en el nuevo servidor Checkmk como corresponde.
4.3. El actualizador de agentes como instalador automático
|
Esta no es una función oficial del actualizador de agentes. Por lo tanto, estas instrucciones están destinadas principalmente a usuarios con más experiencia. La forma oficial de instalar un agente Checkmk en un host es descargar y ejecutar el paquete de agente adecuado para el sistema. Sin embargo, también es posible permitir que el agente Checkmk se instale inicialmente mediante el actualizador de agentes, ya que este también funciona como un programa independiente. |
Haz lo siguiente:
Copia el binario cmk-update-agent o el script
cmk_update_agent.pyen el host que se va a supervisar (ambos se encuentran en~/share/check_mk/agents/pluginsen el servidor Checkmk).Registra el host en el servidor Checkmk ejecutando
cmk-update-agent register. Aquí tiene sentido pasar la información de registro necesaria directamente a través de la línea de comandos, especialmente si quieres usar un script de instalación. Las opciones correspondientes se pueden ver al ejecutarcmk-update-agent register --help.A continuación, con una última llamada al plugin de actualizador de agentes, instala el agente con todos los detalles de configuración para el host que se está sometiendo a monitorización. Sin embargo, dado que no hay configuración local (el actualizador de agentes también muestra una advertencia al respecto) y, por lo tanto, no hay firma para el paquete del agente que se va a descargar, vuelve a llamar al actualizador con
cmk-update-agent --skip-signaturespara confiar explícitamente en el paquete descargado. El requisito previo para la instalación mediante el actualizador de agentes es, por supuesto, que Agent bakery tenga un paquete de agente adecuado listo para el host de destino en el servidor Checkmk.
5. Actualizaciones de agentes en la monitorización distribuida
Desde Checkmk2.0.0 también es posible distribuir agentes preconfigurados a través de sitios remotos. El requisito previo para ello es una monitorización distribuida con configuración centralizada y una conexión que permita acceder al site central desde los sitios remotos a través de HTTP/HTTPS.
Esta monitorización distribuida puede —especialmente de forma temporal— funcionar también con diferentes versiones de Checkmk. Esto permite switchear progresivamente sistemas más grandes a una nueva versión de Checkmk. En este caso, sin embargo, asegúrate de seguir las notas sobre entornos de monitorización con versiones mixtas en la monitorización distribuida.
5.1. Funcionalidad
Técnicamente, la función está implementada de tal manera que las solicitudes de actualización de los sitios remotos se reenvían al site central, de modo que toda la configuración, así como la actualización de los agentes, se lleva a cabo exclusivamente en el site central. Los paquetes de agentes que ya se hayan solicitado en un sitio remoto se almacenan en caché en dicho sitio (siempre que sean válidos), de modo que no sea necesario volver a descargarlos desde el sitio central. Además, se verifica la coherencia de los datos solicitados en el sitio remoto, con lo que se evitan conexiones innecesarias al sitio central.
A diferencia de una configuración de un solo sitio, el servidor de actualización adecuado para los hosts no se deriva exclusivamente del conjunto de reglas del actualizador de agentes, sino que se comunica al actualizador de agentes solicitante por parte del sitio de Checkmk contactado. En este proceso, el sitio desde el que se supervisa proporciona a un host su servidor. Por lo tanto, la especificación de un servidor Checkmk solo es necesaria para el registro único, que teóricamente puede realizarse en cualquier sitio —al que pueda acceder el host— de todo el sistema de monitorización distribuida. Si falla la conexión con el servidor determinado automáticamente, se utiliza como alternativa el servidor guardado previamente (desde la configuración de reglas o introducido manualmente durante el registro).
5.2. Configuración
No es necesario activar por separado la distribución de paquetes de agentes a través de sitios remotos: el sitio remoto correspondiente reconoce la situación automáticamente y se comunica en consecuencia con el site central, así como con el actualizador de agentes solicitante. Si se desea que los agentes envíen informes explícitamente solo al site central para las actualizaciones, esto se puede hacer mediante un servidor de actualización fijo en el conjunto de reglas del actualizador de agentes.
Sin embargo, para que las actualizaciones de los agentes funcionen realmente en una monitorización distribuida, hay que realizar algunos ajustes en el site central,
todos los cuales se pueden encontrar en Setup > General > Global Settings > Automatic Agent Updates.
Si los ajustes difieren para cada site remoto, también se pueden editar por separado.
Para ello, ve a Setup > General > Distributed monitoring y selecciona el icono de engranaje 
en la fila del sitio deseado para acceder a la configuración de ese sitio Site specific global settings.
Conexión con el agente central bakery
En este punto, debes especificar la URL a través de la cual se puede acceder al site central desde el site remoto, incluyendo su protocolo y la cadena de caracteres /check_mk/, por ejemplo, https://myserver.org/mysite/check_mk/.
Aunque el sitio de Checkmk intentará identificar por sí mismo todos los demás ajustes que falten, la especificación de esta URL no es opcional, ya que, de lo contrario, esta dirección de conexión no se establecerá en el caso de una configuración central.
Si el protocolo es HTTPS, el sitio remoto utiliza automáticamente los certificados CA o autofirmados disponibles en la configuración para la verificación de la conexión Setup > General > Global Settings > Site management > Trusted certificate authorities for SSL.
Conexión al agente remoto bakery
Dado que no siempre se puede acceder a los sitios remotos desde los respectivos hosts supervisados a través de la misma URL que desde el site central, aquí se puede configurar una URL para este fin. Esta URL se comunica automáticamente al host (o al actualizador de agentes solicitante) cuando se establece una conexión con un sitio de Checkmk. La configuración como Site specific global settings tiene especial sentido aquí. Si no se especifica ninguna URL, se asume que se puede acceder a los sitios remotos tanto desde el site central como desde los hosts supervisados mediante la misma URL. Si se trata de una conexión HTTPS, también se puede poner automáticamente a disposición del host el certificado adecuado. Dado que el almacén central de CA no se puede utilizar para esto, se pueden especificar los certificados adecuados en este punto. Como alternativa, los certificados también se pueden especificar en las reglas del actualizador de agentes.
6. Trabajar con HTTPS
En varios puntos de este artículo se hace referencia a la protección de las conexiones correspondientes mediante HTTPS. Aquí volveremos a ofrecer una vista general de lo que hay que hacer para proteger completamente las conexiones mediante HTTPS. Tanto la conexión desde un dispositivo remoto a su site central como la conexión desde un host a un sitio de Checkmk pueden y deben protegerse mediante TLS, es decir, utilizando HTTPS. Esto es independiente de si se trata de una configuración de un solo sitio o de una monitorización distribuida.
6.1. Configuración de HTTPS
Para poder realizar una conexión a un sitio de Checkmk a través de HTTPS, primero hay que configurar el servidor de monitorización para HTTPS. Esto se puede lograr, por ejemplo, mediante una configuración adecuada del sistema Apache, o de la forma más sencilla, a través de los ajustes de HTTPS en la Appliance Checkmk.
El hecho de que un servidor Checkmk se acceda a través de HTTP o HTTPS viene determinado por la URL configurada en cada caso.
Si esta comienza por https://, se accede al servidor a través del protocolo HTTPS utilizando el puerto 443.
Esto también se aplica al protocolo que hayas configurado con el ajuste Update server information.
En principio, puedes forzar el redireccionamiento de HTTP a HTTPS en el lado de Apache y (inicialmente) excluir rutas individuales para ello.
Para obtener detalles de configuración, consulta la documentación de Apache sobre los módulos mod_rewrite y mod_redirect.
6.2. Proporcionar certificados
Para que se establezca una conexión HTTPS, debe ser posible verificar la cadena de certificados del servidor contactado o el certificado autofirmado (dependiendo de cómo esté configurado el servidor). El suministro de certificados CA adecuados o certificados autofirmados lo hace posible y puede realizarse de diversas maneras.
Conexiones desde un host a un servidor Checkmk
El actualizador de agentes siempre intenta verificar las conexiones HTTPS y las interrumpe si la verificación no es posible. Los certificados para la verificación están disponibles para el actualizador de agentes en las siguientes fuentes:
El actualizador de agentes: Por defecto, el actualizador de agentes viene con un entorno de ejecución de Python que incluye todos los módulos necesarios. También se incluye el paquete de certificados del módulo Certifi, que a su vez se basa en la colección de certificados del proyecto Mozilla. Esto garantiza que las CA públicas se den a conocer al actualizador de agentes de manera oportuna, incluso cuando haya actualizaciones del sistema operativo pendientes.
Certificados a través de Agent bakery: Los certificados contenidos en el módulo Certifi se ignoran una vez que se han importado uno o más certificados a través de uno de los siguientes mecanismos. Los certificados de las siguientes fuentes se almacenan localmente en el host y solo los usa el actualizador de agentes:
Mediante la configuración Certificates for HTTPS verification, los certificados se pueden integrar en un paquete de agente y estarán disponibles para el actualizador de agentes desde la instalación (o una actualización).
Al configurar la conexión con el site remoto mediante Setup > General > Global settings > Automatic agent updates > Connection to remote agent bakery, puedes especificar certificados que se pueden usar para verificar la conexión HTTPS con el site remoto correspondiente. Esto resulta especialmente útil si en el momento de la configuración aún no está claro qué host se asignará a cada site. Esta opción de importación también se puede usar para reducir el número de agentes que hay que incluir, ya que no es necesario configurar los certificados correctos para los respectivos servidores de actualización de forma específica para cada host.
Almacén de certificados:
el actualizador de agentes solo puede utilizar el almacén de certificados del sistema operativo si se ha configurado para usar System-Python en lugar del entorno de ejecución de Python proporcionado, y no hay ningún módulo Certifi configurado en System-Python.
Dado que aquí intervienen muchos factores, como los parámetros de instalación o la variable del entorno _PIP_STANDALONE_CERT, no ofrecemos soporte oficial para esta configuración.
Certificado vía línea de comandos - Importar certificado:
También puedes llamar al actualizador de agentes con el argumento de línea de comandos --trust-cert.
Esto recupera e importa el certificado del servidor.
Esto se hace sin tener en cuenta el tipo de certificado:
El certificado se considera de confianza sin checkear más a fondo una posible cadena, independientemente de si se trata de un certificado autofirmado, un certificado al final de una cadena de certificados pública o un certificado firmado con una CA interna.
|
|
Certificado vía línea de comandos - Ignorar certificado:
Si el actualizador de agentes no dispone de ningún certificado válido, se puede omitir la validación del certificado utilizando el comando `--insecure` en una llamada.
Esto puede ser útil si el certificado válido ya está esperando a ser recuperado del servidor en la próxima conexión,
pero el actualizador de agentes quedaría «bloqueado» por la falta de este certificado.
|
En realidad, esto desactiva por completo la comprobación del certificado para esta llamada. La comunicación sigue realizándose de forma cifrada, por lo que el uso de este argumento es «mejor que nada». |
Conexión desde un sitio remoto a un sitio central
La distribución de certificados es más sencilla cuando realizas la conexión desde un sitio remoto al sitio central, ya que no hay que salir del procedimiento de configuración en absoluto. El sitio remoto puede usar el almacén de certificados de Checkmk en Global settings > Site management > Trusted certificate authorities for SSL. Por lo tanto, basta con importar los certificados a través del sitio central; si es necesario, también a través de Site specific global settings cuando se pueda acceder al sitio central mediante varias URL.
Procedimiento para sustituir un certificado
Si trabajas con tu propia infraestructura de certificación, lo ideal es que utilices un certificado raíz con una validez muy larga y cuya clave asociada se utilice regularmente para crear certificados intermedios. Estos, a su vez, se utilizan para firmar los certificados de servidor. En este caso, implementas los certificados intermedios como una cadena de certificados en el servidor Checkmk. Los hosts que reciben actualizaciones automáticas del agente solo necesitan conocer el certificado raíz.
Si no estás seguro de si un nuevo certificado de servidor requiere un nuevo certificado raíz, utiliza el siguiente comando. Úsalo para determinar el identificador de la clave raíz utilizada para firmar un certificado de servidor:
Si el identificador mostrado es idéntico tanto para el certificado antiguo como para el nuevo, no es necesario realizar ninguna acción adicional. Los hosts que confían en este certificado raíz pueden seguir obteniendo actualizaciones incluso si cambia la cadena de certificados, siempre que la cadena se haya almacenado correctamente en el sistema Apache.
Si hasta ahora se ha utilizado un certificado autofirmado o un certificado raíz de corta duración de una CA interna, o si la clave raíz anterior de una de tus CA internas se ha visto comprometida, procede de la siguiente manera al sustituir el certificado:
Añade el nuevo certificado utilizando el parámetro `Certificates for HTTPS verification` (en la regla `Agent updater (Linux, Windows, Solaris)`).
Vuelve a compilar los paquetes del agente y actualiza todos los hosts en la monitorización. Asegúrate de que esta actualización se haya ejecutado en todos los hosts antes de continuar.
Ahora sustituye el certificado del servidor.
Prueba con unos cuantos hosts en los que sea fácil reinstalar el agente manualmente si falla, para ver si es posible actualizar de nuevo usando el nuevo certificado.
Si el paso anterior (4) se ha podido realizar con éxito —puedes hacerlo (el certificado caducará) o debes hacerlo (la clave se ha visto comprometida)—, elimina el certificado antiguo y realiza otra actualización del agente.
7. Solución de problemas
En este capítulo se tratan primero los errores típicos y generales, así como sus causas:
El actualizador de agentes solo se ejecutará una vez dentro del intervalo de actualización, por lo que el error se mostrará continuamente hasta que ejecutes el Plugin manualmente o hasta que llegue el siguiente intervalo.
El actualizador de agentes crea su propio archivo de estado cmk-update-agent.state de forma independiente (en Linux/Unix en /etc y en Windows en la carpeta config).
Este archivo permanece en el host tras la desinstalación, para que no se pierda la información del registro.
Una nueva instalación encontrará el archivo y seguirá utilizándolo.
Si esta situación no te conviene, simplemente borra el archivo cmk-update-agent.state manualmente tras la desinstalación.
La página Monitor > System > Agent Update Status muestra todos los hosts que están en la monitorización y para los que existe un archivo de estado en el servidor Checkmk.
No importa si el host realmente se comunica con el servidor Checkmk para las actualizaciones automáticas.
Si aparece aquí un host inesperado, vale la pena echar un vistazo a la carpeta /omd/sites/mysite/var/check_mk/agent_deployment; la causa probablemente sea un registro antiguo o creado accidentalmente.
El actualizador de agentes está diseñado para confiar explícitamente solo en los certificados que suelen especificarse en Agent updater (Linux, Windows, Solaris) dentro de la configuración HTTPS. En particular, se ignoran los certificados instalados localmente. También puede ocurrir que se pueda acceder al servidor Checkmk a través del navegador, mientras que el actualizador de agentes no pueda establecer una conexión debido a una configuración incorrecta.
En la configuración HTTPS de la regla del actualizador de agentes, debes especificar un certificado raíz con el que se pueda verificar la conexión al servidor Checkmk. En otras palabras: la cadena de certificados incluida en el certificado del servidor Checkmk debe poder verificarse mediante el certificado indicado aquí. A menudo se especifica aquí el certificado del servidor en su lugar; sin embargo, esto no es adecuado para este propósito.
Echa un vistazo a la cadena de certificados del servidor Checkmk con la herramienta OpenSSL.
Debido a la longitud de la cadena, para mayor claridad aquí solo se muestra una sección relevante y las secciones omitidas están marcadas con «[...]»:
Para la última entrada —en nuestro caso, subject=/CN=mymonitoring.example.net— necesitas un certificado raíz válido.
Este no tiene por qué ser necesariamente —como en este ejemplo— el emisor del certificado.
Normalmente será una cadena de emisores.
A continuación, fíjate en el certificado utilizado. Aquí también, debido a su longitud, se acortará como en el ejemplo anterior:
El certificado superior —que se ve en el fragmento anterior— no puede tener una dependencia de otro certificado.
Puedes ver que Issuer y Subject son idénticos y que se incluye la opción CA:TRUE.
Además, la cadena del emisor que autentifica un objeto debe ser coherente hasta la entrada final.
Por lo tanto, también necesitas todos los certificados intermedios si el emisor del último certificado no es una CA.
En ocasiones —especialmente en sistemas Red Hat/CentOS— ha ocurrido que la llamada a rpm, activada por la actualización automática, falla repetidamente,
mientras que una llamada manual a cmk-update-agent se procesa correctamente.
La causa en estos casos era una directiva de SELinux que impedía una llamada sin errores si rpm era llamada por un proceso hijo de xinetd.
Puedes resolver el problema, es decir, llegar al fondo del asunto analizando los registros de SELinux y ajustando la directiva en consecuencia con la herramienta audit2allow.
La siguiente sección trata los problemas que se indican mediante mensajes de error específicos:
En algunos sistemas Linux, el programa Prelink está instalado y se activa un cronjob
que examina regularmente todos los archivos binarios del sistema y los adapta si es necesario para acelerar los programas.
Sin embargo, el plugin del actualizador de agentes está empaquetado con el programa PyInstaller, que no es compatible con tales acciones y, por lo tanto, deja de funcionar.
Por eso, Checkmk tiene una entrada en la lista negra para paquetes deb/rpm que se guarda en /etc/prelink.conf.d,
y —si prelink existe— establece una entrada en el archivo /etc/prelink.conf ya existente.
Como este problema es difícil de manejar, puede ocurrir que estas medidas no surtan efecto, especialmente si se instala prelink más tarde.
Por lo tanto, si instalas prelink más adelante, configura la entrada tú mismo y añade la siguiente línea al archivo con este comando:
Este mensaje de error se produce cuando el directorio /tmp se ha montado en el sistema con el indicador «noexec».
Para solucionar este problema, puedes eliminar el indicador o, si lo has configurado deliberadamente y lo necesitas, crear una regla en el servidor Checkmk en Setup bajo «Agents > Windows, Linux, Solaris, AIX > Agents > Agent rules > Installation paths for agent files (Linux, Unix)».
Allí puedes definir tú mismo el directorio tmp en la opción Directory for storage of temporary data (set TMPDIR environment variable).
El plugin de actualizador de agentes escribirá entonces en el futuro los archivos temporales en el directorio definido.
Esto funciona incluso si ejecutas el plugin manualmente con el helper en /usr/bin/cmk-update-agent.
Si el servicio Check_MK Agent muestra la advertencia «No valid signature found», significa que el paquete de agente destinado al host en Agent bakery no ha sido firmado con una de las claves aceptadas.
En el caso más sencillo, solo tienes que firmar tus agentes utilizando la función «Sign agents» en Agent bakery con una de las claves que aparecen en Signature keys the agent will accept.
En cuanto el actualizador de agentes envíe su próximo informe desde el host afectado al servidor Checkmk, y haya expirado el intervalo de caché del servicio, la advertencia desaparecerá.
Sin embargo, si el host no tiene (o ya no tiene) ni una sola clave de firma ubicada en el servidor Checkmk, debes repetir el proceso de creación y firmar con una clave que aparezca en Signature keys the agent will accept, luego copiar el agente creado al host afectado y reinstalarlo allí.
En un host afectado, puedes ejecutar cmk-update-agent -v o check_mk_agent.exe updater -v para obtener más detalles sobre este error.
El mensaje de error detallado hace una lista explícita de las firmas del archivo de configuración del plugin de actualizador de agentes que no tienen una contraparte aceptada (es decir, configurada) en tu servidor Checkmk.
Ignoring signature #1 for certificate: certificate is unknown.
No valid signature found.8. Archivos y directorios
8.1. Rutas de archivos en el servidor Checkmk
| Ruta de archivo | Descripción |
|---|---|
|
Contiene los agentes precompilados, ordenados primero en subdirectorios por sistema operativo (p. ej., |
|
Contiene archivos con los nombres de los hosts registrados. Uno de estos archivos contiene la hora del último registro y el secreto del host. |
8.2. Rutas de los archivos en el host objeto de monitorización
- Linux
Ruta del archivo Descripción /usr/lib/check_mk_agent/plugins/3600/cmk-update-agentEl actualizador de agentes, en formato binario o de script, dependiendo de la configuración, en formato ejecutable. El subdirectorio «
3600» indica el intervalo de comprobación de actualizaciones en segundos (en este caso, el valor por defecto de una hora)./usr/bin/cmk-update-agentScript para llamar al plugin de actualizador de agentes y registrar el agente con el comando
cmk-update-agent register./etc/check_mk/cmk-update-agent.cfgArchivo de configuración del plugin de actualizador de agentes, que contiene los ajustes de la regla Agent updater (Linux, Windows, Solaris). No edites este archivo, ya que se escribe en él durante las instalaciones y actualizaciones.
/etc/cmk-update-agent.stateArchivo con información del registro, incluido el secreto del host.
/var/lib/check_mk_agent/cmk-update-agent.logArchivo de registro detallado con mensajes de depuración.
- Windows
Ruta del archivo Descripción C:\ProgramData\checkmk\agent\plugins\cmk_update_agent.checkmk.pyEl plugin de actualizador de agentes como archivo Python.
C:\Program Files (x86)\checkmk\service\check_mk_agent.exePrograma del agente para registrar el agente con el comando «
check_mk_agent.exe updater register».C:\ProgramData\checkmk\agent\config\cmk-update-agent.cfgArchivo de configuración del plugin de actualizador de agentes, que contiene los ajustes de la regla «Agent updater (Linux, Windows, Solaris)». No edites este archivo, ya que se escribe en él durante las instalaciones y actualizaciones.
C:\ProgramData\checkmk\agent\config\cmk-update-agent.stateArchivo con información del registro, incluido el secreto del host.
C:\ProgramData\checkmk\agent\log\cmk-update-agent.logArchivo de registro detallado con mensajes de depuración.
C:\ProgramData\checkmk\agent\bakery\check_mk.bakery.ymlArchivo de configuración creado por Agent bakery, que, entre otras cosas, define el intervalo para la comprobación de actualizaciones.