 |
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. |
1. Introducción
En entornos de cloud y contenedores, cada vez es más habitual que los hosts supervisados aparezcan y desaparezcan automáticamente. Mantener la configuración de monitorización actualizada manualmente ya no es una opción viable. Sin embargo, incluso las infraestructuras clásicas, como los clústeres de VMware, pueden ser muy dinámicas, y aunque el mantenimiento manual no sea factible en este caso, sigue siendo posible mantener la configuración actualizada manualmente.
Las ediciones comerciales de Checkmk te ayudan
con una herramienta inteligente: la administración dinámica del host.
La administración dinámica del host utiliza información de la monitorización de Amazon Web Services (AWS), Microsoft Azure, Kubernetes, VMware ESXi y otras fuentes para añadir automáticamente hosts a la monitorización, así como para eliminarlos cuando ya no son necesarios.
La administración dinámica del host es genérica y no se limita a la creación de hosts. Constituye la base para futuras ampliaciones de Checkmk que ajustarán dinámicamente la configuración. Para ello, la administración dinámica del host funciona con conexiones. Cada conexión puede recuperar información de un tipo específico de fuente y cuenta con su propia configuración específica para este fin.
El Demonio de Configuración Dinámica (DCD) es el componente de software que proporciona la administración dinámica del host. La arquitectura de software del DCD se ha rediseñado por completo en Checkmk 2.4.0 para cumplir con los requisitos de entornos grandes y altamente dinámicos, y garantizar un procesamiento estable y seguro. La recopilación de información de las conexiones configuradas ahora está desacoplada de los cambios de configuración resultantes en Checkmk. Los cambios pendientes se organizan en colas y se procesan secuencialmente en ciclos, lo que garantiza un procesamiento estable y seguro. La configuración del gestor de hosts te ofrece opciones para personalizar los ciclos de procesamiento. Para obtener más información, consulta el capítulo Configuración.
2. Tipos de conexión
Al configurar una conexión en la administración dinámica del host, puedes añadir automáticamente hosts a la monitorización y también eliminarlos de forma automática, para que siempre tengas una visión en tiempo real de la situación. Para ello, la administración dinámica del host analiza los datos existentes, compara qué hosts ya están presentes en el entorno de configuración y crea los hosts que faltan o elimina los que ya no están presentes. Posteriormente, se lleva a cabo (opcionalmente) un descubrimiento de servicios en los hosts y, finalmente, se activan los cambios para que el estado actual se pueda ver en el entorno de monitorización.
2.1. Conexión piggyback
La conexión piggyback se utiliza para evaluar —como es lógico— datos piggyback. Este tipo de conexión se puede utilizar de forma universal en Checkmk, ya que Checkmk utiliza el mecanismo piggyback en todas las situaciones en las que una consulta a un host (normalmente a través de un agente especial) proporciona datos sobre otros hosts (normalmente máquinas virtuales u objetos en la nube).
Checkmk utiliza piggyback, por ejemplo, para monitorizar Proxmox, Docker, VMware ESXi y los hiperescaladores AWS, Azure y GCP. En todos estos casos, la monitorización recupera automáticamente datos de otros hosts, como máquinas virtuales (VM), a los que no se puede acceder directamente a través de la red y en los que no es necesario que se ejecute ningún agente Checkmk. Puedes incluir automáticamente dichos hosts en la monitorización y también eliminarlos de nuevo. Los hosts creados automáticamente se pueden seguir editando manualmente en la GUI de Setup.
El único requisito para usar una conexión piggyback son los datos piggyback. Siempre los tendrás si has configurado la monitorización para AWS, Azure y otros tal y como se describe en el Manual de usuario.
También puedes comprobar fácilmente la presencia de datos piggyback en la línea de comandos, ya que Checkmk crea estos datos en el directorio ~/tmp/check_mk/piggyback/:
Si este directorio no está vacío, se han generado datos piggyback en este site.
2.2. Conexión OpenTelemetry
Checkmk 2.4.0 ofrece en 
Checkmk Ultimate soporte experimental para procesar métricas de OpenTelemetry.
Para ello, un colector de OpenTelemetry en Checkmk recopila los datos de métricas que recibe a través del Protocolo OpenTelemetry (OTLP) o recupera a través de un endpoint de Prometheus.
Al configurar el colector, también se establecen reglas para generar nombres del host para Checkmk a partir de los datos.
Una vez configurado, el colector comienza a recopilar los datos y los almacena en el sitio de Checkmk con nombres de archivo que se corresponden con los nombres del host.
La configuración de OpenTelemetry, incluido el colector de OpenTelemetry, se describe en el artículo «Monitorización de métricas de OpenTelemetry».
Los datos de OpenTelemetry siempre están disponibles en el site si el colector de OpenTelemetry se ha configurado correctamente. Esto se puede comprobar mediante la línea de comandos, ya que los datos de OpenTelemetry se almacenan en el directorio ~/tmp/check_mk/otel_collector/:
Si este directorio no está vacío, se han generado datos de OpenTelemetry en este site.
3. Configurar una conexión
Abre la página de administración dinámica del host en Setup > Hosts > Dynamic host management:
Crea una nueva conexión usando Add connection.
3.1. Propiedades generales
La primera parte de la configuración es General properties:
Como suele ser habitual, aquí le asignas un ID único y un título a esta conexión.
En «Site», debes seleccionar el site de Checkmk donde se generan los datos.
«Generado» se refiere aquí al site donde se almacenan los datos en el directorio ~/tmp/check_mk/ para el tipo de conexión correspondiente.
En la mayoría de los casos, un agente especial maneja el almacenamiento de los datos.
Dado que los datos solo pueden procesarse localmente en un site específico, la conexión debe asignarse a ese site. En una monitorización distribuida con configuración centralizada, debes especificar, por lo tanto, el sitio en el que se recopilarán y procesarán posteriormente los datos, ya sean datos piggyback o de otras fuentes. Aquí no se determina en qué sitio se crearán los hosts. Esto se especifica en Host attributes to set utilizando el atributo de host Basic settings: Monitored on site. A continuación, la conexión se asigna al host.
3.2. Propiedades de una conexión piggyback
La segunda parte son las propiedades de la conexión (Connection properties). Como hay bastante que configurar aquí, repasaremos las opciones una por una.
Para una conexión piggyback, selecciona Piggyback data como Connector type.
Con «Restrict source hosts», puedes restringir esta conexión a hosts específicos como fuentes. Estos suelen ser los hosts para los que se ha configurado un agente especial. La administración dinámica del host solo está activa para estos hosts. La restricción se establece en el campo de entrada correspondiente, cuyo contenido se interpreta como una expresión regular. Una vez que hayas editado el primer campo de entrada, el siguiente se abrirá automáticamente, lo que significa que puedes especificar varias expresiones regulares.
Con el Sync interval, puedes determinar con qué frecuencia la conexión debe buscar nuevos hosts. Si has mantenido el intervalo de comprobación habitual de un minuto, no tiene sentido hacerlo con mucha más frecuencia, ya que los datos solo pueden cambiar una vez por minuto como máximo. En entornos más dinámicos, puedes establecer tanto el intervalo de comprobación como el intervalo de conexión en valores significativamente más pequeños. Sin embargo, esto también se traduce en una mayor carga en el servidor Checkmk.
Debe existir al menos una entrada en Piggyback creation options. También puedes añadir más mediante Add new entry:
Esta sección trata sobre las propiedades de los hosts generados automáticamente, para los que puedes especificar dos cosas importantes: La carpeta en la que se crearán los hosts (Create hosts in) y qué atributos de host se deben configurar. Hay cuatro atributos importantes preconfigurados, que suelen ser útiles para los hosts piggyback:
Sin monitorización vía SNMP.
Sin agente Checkmk en el propio host (los datos llegan a través del piggyback).
Siempre se esperan datos piggyback (y se produce un error si faltan).
Los hosts no tienen dirección IP.
Si quieres usar los datos piggyback en otro sitio, activa la opción «Add attribute» y luego la opción «Basic settings: Monitored on site» y especifica el site deseado.
Solo si activas la checkbox en «Delete vanished hosts» se volverán a eliminar los hosts si han desaparecido en tu entorno dinámico. Si no quieres crear automáticamente todos los hosts piggyback, puedes restringirlo con la opción «Only add matching hosts» mediante una expresión regular.
En la tercera y última parte de las propiedades de conexión, puedes especificar que se realice el descubrimiento de servicios en los hosts generados automáticamente activando la checkbox en «Service discovery»:
Las tres opciones restantes afectan a la eliminación de los hosts creados automáticamente, un tema que se explica en detalle en un capítulo aparte.
La opción «Prevent host deletion after initialization» afecta a un reinicio completo del propio servidor Checkmk. En esta situación, los datos de todos los hosts faltarán inicialmente hasta que se hayan consultado por primera vez. Para evitar la eliminación y reaparición innecesarias de hosts (lo que también va acompañado de notificaciones repetidas de problemas ya conocidos), por defecto no se realiza la eliminación durante los primeros 10 minutos. Puedes configurar este tiempo aquí.
La opción «Validity of missing data» se ocupa del caso en el que un host, a partir de cuyos datos de monitorización se crearon automáticamente varios hosts, ya no proporciona datos piggyback. Esto puede ocurrir, por ejemplo, si el acceso a AWS y similares ya no funciona. O, por supuesto, si has eliminado el agente especial de la configuración. Los hosts generados automáticamente permanecerán entonces en el sistema durante el tiempo establecido antes de ser eliminados de la GUI de Setup.
La opción «Validity of outdated data» es similar, pero se aplica al caso en el que siguen llegando datos, pero ya no para algunos hosts. Este es el caso habitual cuando, por ejemplo, las máquinas virtuales o los servicios en la nube ya no están disponibles. Si quieres que los objetos correspondientes desaparezcan de Checkmk rápidamente, establece aquí un periodo de tiempo corto.
3.3. Propiedades de una conexión OpenTelemetry
Las opciones para crear una conexión piggyback y una conexión OpenTelemetry, que se pueden configurar en Checkmk Ultimate, son casi idénticas. Por lo tanto, te ofrecemos una vista general de las propiedades de una conexión OpenTelemetry.
Para una conexión OpenTelemetry, selecciona «Opentelemetry collector data» como «Connector type».
Usa «Sync interval» para determinar con qué frecuencia debe buscar la conexión nuevos hosts.
En «Open telemetry hosts creation options», especifica la carpeta en la que deben crearse los hosts (Create hosts in) y qué atributos de host deben configurarse. Hay dos atributos preconfigurados:
Solo se utilizan para la monitorización los datos entregados a través de integraciones de API.
Los hosts no tienen una dirección IP.
Solo si activas la checkbox en «Delete vanished hosts» se volverán a eliminar los hosts si han desaparecido de tu entorno dinámico. Si no quieres que se creen todos los hosts automáticamente, puedes restringirlo con la opción «Only add matching hosts» mediante una expresión regular.
Al marcar la caja en «Service discovery», especificas que se realice el descubrimiento de servicios en los hosts generados automáticamente. Sin embargo, esto solo da el resultado deseado si se ha configurado el agente especial para OpenTelemetry.
Las dos últimas opciones, Prevent host deletion after initialization y Validity of outdated data, afectan a la eliminación de los hosts creados automáticamente. Estas opciones funcionan tal y como se describe en la sección de conexión piggyback. La eliminación de los hosts creados automáticamente se explica en detalle en un capítulo aparte.
3.4. Guardar la conexión
Una vez guardada, la conexión aparecerá en la lista de conexiones. Sin embargo, solo se podrá ejecutar después de que se hayan activado los cambios. Solo entonces empezará a funcionar la conexión.
Por lo tanto, no te dejes confundir por el mensaje que aparece inicialmente en la columna «Status
» después de guardar:
Connection 'my_connection' isn’t found: consider activating changes
3.5. Activar la conexión
Después de guardar las propiedades de la conexión y activar los cambios, la conexión empezará a funcionar automáticamente. Si ya hay datos disponibles para esta conexión y esperas que se generen los hosts correspondientes, pronto verás una entrada correspondiente en la lista bajo «Recent processing cycles», que podría tener un aspecto similar a este:
En la imagen de ejemplo, puedes ver que esta ejecución está casi completa y que al final se crearán al menos 50 hosts. Si actualizas esta página poco después, es probable que estos cambios ya se hayan activado automáticamente mediante la administración dinámica del host. El resultado del proceso del ejemplo anterior tendrá entonces este aspecto:
Los nuevos hosts ya estarán en monitorización y se realizarán controles regulares.
La lista «Recent processing cycles» mostrará los ciclos de un periodo de tiempo más largo que realmente han dado lugar a cambios.
Los ciclos de la conexión que no hayan dado lugar a ningún cambio se ocultarán tras unos segundos.
Para verlos de todos modos, haz clic en el símbolo del reloj 
en la columna «Actions», lo que te llevará al «Execution history of this connection» (Historial de ejecuciones).
3.6. Acciones para una conexión
Para cada conexión, la lista de conexiones de la columna «Actions» muestra iconos para realizar acciones:
Algunos de los siguientes iconos solo se muestran para una conexión activada:
| Icono | Acción |
|---|---|
|
Abre la conexión para realizar la edición. |
|
Clona la conexión y la abre para realizar la edición. |
|
Muestra una lista de los hosts creados por esta conexión. |
|
Muestra el historial de ejecución de la conexión. |
|
Muestra el estado de la administración dinámica del host, es decir, los ciclos de procesamiento actuales. |
|
Ejecuta la conexión sin esperar al siguiente ciclo de proceso. |
|
Muestra cómo se puede crear la conexión con la API-REST de Checkmk. |
|
Elimina la conexión tras la confirmación. |
4. Eliminación automática de hosts
Como se ha mencionado anteriormente, los hosts que «ya no existen» pueden eliminarse automáticamente de la monitorización mediante la administración dinámica del host. A primera vista, esto parece muy lógico; sin embargo, lo que significa exactamente «ya no existe» es un poco más complejo si lo piensas bien, ya que hay varios casos alternativos a tener en cuenta.
En la siguiente vista general, daremos por hecho que has activado la opción en Delete vanished hosts para la conexión. De lo contrario, los hosts nunca se eliminarán automáticamente.
| Situación | ¿Qué ocurre? |
|---|---|
Se elimina una conexión. |
Si desactivas una conexión (con do not activate this connection en el General properties) o la eliminas por completo, todos los hosts creados por esta conexión se conservan. Si es necesario, debes eliminarlos manualmente. |
Ya no se realiza la monitorización de un host piggyback. |
Si eliminas de la monitorización un host piggyback que utilizas para supervisar tu entorno de cloud o contenedores, este, por supuesto, ya no generará datos piggyback. En este caso, los hosts piggyback generados automáticamente se eliminan de forma predeterminada al cabo de una hora. Puedes ajustar este periodo mediante la opción «Validity of missing data». |
No se puede acceder a un host piggyback. |
Si tu entorno de cloud no está disponible y el servicio Check_MK que lo consulta devuelve un error de «CRIT», los hosts generados automáticamente permanecen en la monitorización de forma indefinida. ¡Aquí no hay un timeout de una hora! |
Un host creado automáticamente ya no se incluye en los datos. |
Esto es bastante habitual en un entorno de cloud/contenedores. En este caso, por defecto, el host se elimina automáticamente tras un minuto. Puedes ajustar el periodo de tiempo mediante la opción Validity of outdated data. |
El servidor Checkmk en sí se detiene. |
Detener toda la monitorización hace que los datos queden desactualizados, pero, por supuesto, los hosts existentes no se eliminan como resultado. Lo mismo ocurre cuando se reinicia el servidor Checkmk (lo que provoca la pérdida temporal de todos los datos, ya que se almacenan en el disco RAM). |
Ten en cuenta que con la regla «Automatic host removal», es posible que todos los hosts se eliminen automáticamente. Ambas opciones de gestión del ciclo de vida funcionan de forma independiente entre sí, es decir, un host se elimina si se cumple una de las dos condiciones.
5. Configuración
La configuración del gestor de hosts te permite personalizar los ciclos de procesamiento de la administración dinámica del host. Puedes acceder al diálogo a través de Setup > Hosts > Dynamic host management > Host manager settings:
Los ajustes predeterminados aquí ya están seleccionados, por lo que deberían funcionar bien incluso en entornos más grandes y extremadamente dinámicos. Sin embargo, si tu entorno sufre muchos cambios cada minuto, estos generarán una cierta carga en tu servidor Checkmk. Para controlar mejor esta carga, se introdujeron los Host manager settings con Checkmk 2.4.0.
Lo que hacen exactamente las opciones individuales ya se describe con gran detalle en la ayuda en línea, por lo que no se repetirá aquí. A continuación, describimos las tres áreas y cuáles son sus funciones.
Host processing Consiste en buscar y asignar datos específicos de los hosts a partir de los datos disponibles. Esto responde a preguntas como si se han encontrado nuevos datos y si se deben crear hosts para estos datos. Si hay que tomar un gran número de decisiones de este tipo con regularidad, puede ser útil aumentar las pausas entre ejecuciones para dar tiempo suficiente a que se procesen las colas.
Como administrador de Checkmk, probablemente ya estés muy familiarizado con la función «Activate changes». Esta acción determina cómo y cuándo la administración dinámica del host debe activar los cambios y cuánto tiempo puede tardar en hacerlo.
Es posible que incluso la propia función «Service discovery» ya no sea un gran misterio para ti. Sin embargo, dependiendo del entorno que se esté supervisando, es posible que haya algunos hosts más esperando a ser objeto de descubrimiento masivo en la administración dinámica del host. Consulta la ayuda en línea detallada en el texto en una situación así, para que puedas intervenir de forma oportuna y específica en caso de que se produzcan retrasos en el proceso de administración dinámica del host.
La última opción del grupo (Do not monitor hosts without discovered services) se introdujo para manejar una situación especial. Básicamente, solo es necesaria si los cambios pendientes se fuerzan con frecuencia sin un descubrimiento previo de servicios. Esta opción debe activarse con precaución. Sin embargo, si es necesario, esto puede indicar que las opciones anteriores no se han configurado de forma óptima, o que el servidor Checkmk ya no puede hacer frente a la carga generada por la administración dinámica del host.
6. Diagnóstico
6.1. Historial de ejecuciones
Si quieres ver cómo funciona el DCD, encontrarás el icono del reloj en la lista de conexiones de cada entrada,
que te llevará al historial de ejecución:
Si, por cualquier motivo, falla la creación de un host, esto se verá en el historial de ejecución.
6.2. El archivo de registro del DCD
El archivo de registro del DCD es ~/var/log/dcd.log.
Aquí tienes un ejemplo que tiene una coincidencia con la ilustración anterior:
2025-08-21 11:46:18,962 [20] [cmk.dcd.Manager] 1 batches arrived 50, last activated is reset
2025-08-21 11:46:19,059 [20] [cmk.dcd.Manager] Batches: {281} = Create: 0 Edit: 0 Delete: 0 Discover: 0
2025-08-21 11:46:19,059 [20] [cmk.dcd.Manager] Skip batches {281}7. Archivos y directorios
| Ruta del archivo | Función |
|---|---|
|
Aquí es donde se generan los datos piggyback. Se crea un subdirectorio para cada host piggyback incluido en los datos piggyback. |
|
Aquí es donde se generan los datos de OpenTelemetry. Se crea un subdirectorio para cada host. Los archivos que se crean allí están en formato JSON. |
|
Archivo de registro del Demonio de Configuración Dinámica (DCD). |