 |
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
Cada vez es más habitual en los entornos de nube y contenedores que los hosts a monitorizar no sólo se generen, sino que caduquen automáticamente. Mantener actualizada la configuración de la monitorización en un entorno así ya no es posible de forma manual. Las infraestructuras clásicas como, por ejemplo, los clústeres de VMware también pueden ser muy dinámicas, y aunque la atención manual siga siendo posible, en cualquier caso resulta engorrosa.
Las ediciones comerciales de Checkmk te ayudan en este proceso con una herramienta inteligente, el Dynamic Configuration Daemon o DCD para abreviar. La configuración dinámica de hosts significa que, basándose en la información de la monitorización de AWS,Azure, Kubernetes,VMware y otras fuentes, se pueden añadir y eliminar hosts de la monitorización en un proceso totalmente automatizado.
El DCD es muy genérico, y no se limita sólo a la creación de host. El DCD constituye la base para futuras extensiones de Checkmk que ajustarán dinámicamente la configuración. Esto también puede significar la administración de usuarios, por ejemplo. Para ello, el DCD funciona con los llamados conectores. Cada conector puede obtener información de un tipo de fuente muy concreto, y tiene su propia configuración específica.
Con conectores especiales, en el futuro será aún más fácil introducir automáticamente host en Checkmk desde una CMDB existente.
2. Administración del host con la DCD
2.1. El conector piggyback
Actualmente, el DCD de Checkmk sólo está equipado con un único conector: el que se utiliza para los datos piggyback. Éste es muy universal, ya que Checkmk utiliza el mecanismo piggyback en todas las situaciones en las que la consulta de un host (normalmente mediante un agente especial) proporciona datos de otros hosts (normalmente máquinas virtuales u objetos cloud).
Aquí tienes un par de ejemplos en los que Checkmk utiliza piggyback en la monitorización:
En todos estos casos, la monitorización recupera automáticamente datos de otros hosts (por ejemplo, las máquinas virtuales) con los que no se contacta directamente a través de la red y en los que tampoco es necesario que se ejecute ningún agente Checkmk. Con la DCD puedes añadir y también eliminar automáticamente dichos hosts en la monitorización, de modo que siempre reflejen la situación real de forma oportuna.
Para ello, el DCD analiza los datos piggyback existentes y los compara con los hosts que ya existen en la Configuración, y luego vuelve a crear los hosts que faltan o, respectivamente, elimina los redundantes. Hay hosts que la DCD crea automáticamente, pero que tú puedes editar en la GUI de Configuración.
2.2. El usuario de automatización
Por defecto, el usuario de automatización existe en Checkmk. Este usuario es creado por Checkmk para permitir las búsquedas automatizadas. Un usuario de automatización existente también es obligatorio para la configuración dinámica del host.
Si, por cualquier motivo, has eliminado o cambiado este usuario en tu sistema, tienes que establecer otro usuario con acceso automatizado a la API. En este caso, abre la configuración básica global a través de Setup > General > Global settings:
Si haces clic en Credentials: Use "Checkmk Automation" user, accederás a la página de edición de la conexión a la API-REST:
Aquí puedes introducir otro usuario y sus datos de acceso (nombre, contraseña) o introducir cambios en el usuario de automatización existente. En cuanto hayas guardado los cambios con Save, el usuario definido se utilizará para la automatización y podrás continuar con la configuración dinámica del host.
2.3. Establecimiento de la configuración dinámica
¿Hay datos piggyback?
El único requisito para poder utilizar el DCD es disponer de datos piggyback. Siempre dispondrás de estos datos si has configurado correctamente la monitorización de AWS, Azure y compañía. También puedes comprobarlo fácilmente a través de la línea de comandos, porque los datos piggyback de Checkmk se habrán creado en el directorio tmp/check_mk/piggyback:
OMD[mysite]:~$ ls tmp/check_mk/piggyback
myvm01 myvm02 myvm03Si este directorio no está vacío, se han generado datos piggyback en este site.
Configuración general del conector
Ahora ve a la administración del host. La entrada de menú Setup > Hosts > Dynamic host management te lleva a la configuración de la DCD respectivamente de su conector:
Crear una nueva conexión con Add connection. La primera parte de la configuración es General properties:
Aquí asignas, como siempre, un ID único y un título para este conector. También es importante la selección del site Checkmk en el que debe ejecutarse este conector. Dado que los datos piggyback siempre se procesan localmente, el conector debe asignarse siempre a un site concreto.
Propiedades del conector
La segunda parte es Connection Properties:
El conector Piggyback data ya está preseleccionado aquí (y actualmente es el único posible).
El Sync interval determina la frecuencia con la que el conector debe buscar nuevos host. Si mantienes el intervalo de check habitual de un minuto, no tiene sentido hacerlo con mucha más frecuencia, ya que un cambio de datos piggyback puede tener lugar una vez por minuto como máximo. En entornos muy dinámicos puedes utilizar tanto el intervalo de check como el intervalo del conector configurados con valores mucho más bajos. Sin embargo, esto también provoca una mayor utilización de la CPU en el servidor Checkmk.
Ahora es importante añadir en Piggyback creation options al menos un elemento (Add new element). Esto te llevará a la configuración de los host creados automáticamente:
Aquí puedes especificar dos cosas importantes: En qué carpeta deben crearse los hosts (aquí por ejemplo AWS Cloud 02), y qué atributos del host deben establecerse (para esto último debes tener activado el Modo mostrar más )). Hay cuatro atributos importantes preestablecidos que se aplican principalmente a los host piggyback:
Sin monitorización mediante SNMP.
No hay agente Checkmk en el propio host (los datos llegan a través de piggyback).
Siempre se esperan datos piggyback (y se produce un error si faltan).
Los hosts no tienen dirección IP.
Importante: Sólo si activas Delete vanished hosts se borrarán los hosts cuando desaparezcan de tu entorno dinámico.
Si no quieres crear automáticamente todos los hosts, puedes hacerlo restringiendo la opción Only add matching hosts con una expresión regular.Importante: aquí nos referimos a los hosts que se están creando, y no a los hosts que has configurado para monitorizar AWS, por ejemplo.
Esto último puede conseguirse con la opción Restrict source hosts. Se refiere a los nombres de los host que generan datos piggyback.
Activar cambios
Otras dos opciones se ocupan de la activación automática de cambios, para el caso de que realmente se hayan creado o eliminado hosts, ya que sólo entonces aparecerán en la monitorización.
Si activar cambios lleva mucho tiempo en tu site, puedes utilizarGroup "Activate changes" para que no se inicie inmediatamente con cada nuevo host, sino una vez que se hayan "coleccionado" unos cuantos hosts.
Además, también puedes detener por completo la activación automática de cambios para determinadas horas del día, por ejemplo, para las horas en las que tu sistema de monitorización está siendo vigilado activamente. Porque si la DCD activa cambios, ¡todos los demás cambios que tú o un compañero acabéis de hacer también se activarán!
Después de guardar, el conector aparece en la lista. Sin embargo, no puede ejecutarse antes de que hayas activado los cambios: sólo entonces empieza a funcionar. Por tanto, no te irrites por el mensaje que aparece justo después de guardar:
Failed to get the status from DCD (The connection 'piggy01' does not exist)
3. Puesta en marcha del conector
3.1. La primera activación
Después de guardar las propiedades del conector, y tras activar cambios, el conector iniciará automáticamente su funcionamiento. Esto puede ir tan rápido que justo después de activar los cambios verás inmediatamente cómo se van creando host en la monitorización:
Si vuelves a cargar esta página poco después, probablemente estos cambios ya habrán desaparecido, porque fueron activados automáticamente por la DCD. Los nuevos host ya están en la monitorización y serán monitorizados regularmente.
4. Eliminación automática de host
4.1. ¿Cuándo se borran los host?
Como ya se ha dicho, puedes permitir que los host que "ya no existen" sean eliminados automáticamente de la monitorización de la DCD, lo que a priori suena muy lógico. Sin embargo, lo que se entiende exactamente por "ya no existe" es, a primera vista, un poco más complejo, ya que hay varias situaciones a tener en cuenta. En el siguiente resumen asumimos que tienes activada la opción de borrado, ya que, de lo contrario, los hosts nunca se eliminarán automáticamente.
| Situación | ¿Qué ocurre? |
|---|---|
Eliminar un conector DCD |
Si cierras un conector DCD (do not activate this dynamic configuration connection), o lo eliminas por completo, se conservan todos los host creados por este conector. Si es necesario, debes eliminarlos a mano. |
El host piggyback ya no será monitorizado |
Si eliminas de la monitorización el host desde el que monitorizas tu entorno de nube o contenedor, por supuesto no generará más datos piggyback. En este caso, los host generados automáticamente se eliminarán automáticamente al cabo de una hora. |
No se puede contactar con el host piggybacked |
Si tu entorno de cloud es inalcanzable y el servicio Checkmk que lo solicita pasa a CRIT, los hosts generados permanecerán en monitorización indefinidamente. ¡Aquí no hay timeout de una hora! |
Se detiene el propio servidor Checkmk |
Detener toda la monitorización hará que los datos piggyback queden obsoletos, pero, por supuesto, esto no hará que se eliminen los hosts creados. Lo mismo ocurre si se reinicia el servidor Checkmk (lo que provoca una pérdida temporal de todos los datos piggyback, ya que éstos se encuentran en la RAM). |
Un host ya no está en los datos piggyback |
Esta es una situación normal: Un host en un entorno de nube/contenedor ha desaparecido. En este caso se eliminará inmediatamente de la monitorización. |
Ten en cuenta que, con la regla Automatic host removal, existe la opción de eliminar automáticamente todos los host. Ambas opciones de gestión del ciclo de vida funcionan de forma independiente, es decir, un host se elimina si se cumple una de las dos condiciones.
4.2. Opciones de configuración
Además de la cuestión de si los host deben eliminarse automáticamente, en las propiedades del conector hay tres opciones más que afectan a la eliminación, opciones que nos hemos saltado antes:
La primera opción - Prevent host deletion right after initialization - afecta a un reinicio completo del propio servidor Checkmk. En esta situación, al principio faltarán los datos piggyback de todos los hosts hasta que éstos se consulten por primera vez. Para evitar la eliminación y reaparición sin sentido de hosts (que también va acompañada de notificaciones repetidas por problemas conocidos), por defecto se renunciará a las eliminaciones durante los primeros 10 minutos. Este límite de tiempo puede personalizarse aquí.
La opción Validity of missing data gestiona la situación en la que un host, cuyos datos de monitorización crearon varios hosts automáticamente, no devuelve datos piggyback. Este puede ser el caso, por ejemplo, cuando el acceso a AWS y compañía ha dejado de funcionar. O también, por supuesto, si has eliminado el agente especial de la configuración. Los hosts generados automáticamente permanecerán durante el tiempo establecido en el sistema antes de ser eliminados de la Configuración.
La opción Validity of outdated data es similar, pero trata el caso de que, aunque se reciban datos piggyback, no se reciban de algunos host. Éste es el caso normal si, por ejemplo, las máquinas virtuales o los servicios en la nube dejan de estar disponibles. Si quieres que los objetos correspondientes desaparezcan de Checkmk a tiempo, establece aquí un periodo de tiempo correspondientemente corto.
5. Diagnósticos
5.1. Historial de ejecución
Si quieres ver cómo trabaja la DCD, en cada entrada de la lista de conectores encontrarás el icono Te lleva al historial de ejecución:
Si por alguna razón falla la creación de un host, lo verás en el historial de ejecución.
5.2. Registro de auditoría
Con Setup > General > Audit log abres una página con la lista de todos los cambios que se han realizado en la GUI de Configuración, independientemente de si ya se han activado o no. Busca las entradas del usuario automation. La DCD trabaja con esta cuenta y genera cambios en ella, así que aquí puedes ver qué host ha creado o eliminado la DCD y cuándo lo ha hecho.
5.3. Archivo de registro de la DCD
El archivo de registro de la DCD es var/log/dcd.log. Aquí tienes un ejemplo que se ajusta a la descripción anterior. Aquí también encontrarás el mensaje de error de que no se ha podido crear un host concreto:
2021-11-10 14:45:22,916 [20] [cmk.dcd] ---------------------------------------------------
2021-11-10 14:45:22,916 [20] [cmk.dcd] Dynamic Configuration Daemon (2.0.0p14) starting (Site: mysite, PID: 7450)...
2021-11-10 14:45:22,917 [20] [cmk.dcd.ConnectionManager] Initializing 0 connections
2021-11-10 14:45:22,918 [20] [cmk.dcd.ConnectionManager] Initialized all connections
2021-11-10 14:45:22,943 [20] [cmk.dcd.CommandManager] Starting up
2021-11-10 15:10:58,271 [20] [cmk.dcd.Manager] Reloading configuration
2021-11-10 15:10:58,272 [20] [cmk.dcd.ConnectionManager] Initializing 1 connections
2021-11-10 15:10:58,272 [20] [cmk.dcd.ConnectionManager] Initializing connection 'piggy01'
2021-11-10 15:10:58,272 [20] [cmk.dcd.ConnectionManager] Initialized all connections
2021-11-10 15:10:58,272 [20] [cmk.dcd.ConnectionManager] Starting new connections
2021-11-10 15:10:58,272 [20] [cmk.dcd.piggy01] Starting up
2021-11-10 15:10:58,273 [20] [cmk.dcd.ConnectionManager] Started all connections6. Archivos y directorios
| Ruta | Función |
|---|---|
|
Aquí se crean los datos piggyback. Se crea un directorio para cada host piggyback incluido en los datos piggyback. |
|
El archivo de registro del Daemon de Configuración Dinámica (DCD) |