Monitorización de Docker

Por supuesto, el aspecto interesante es la monitorización de los contenedores Docker. Esto se implementará automáticamente instalando los Plugin, aunque los servicios no se asignarán al nodo Docker, sino que Checkmk asume un único host por contenedor Docker.

El mecanismo utilizado aquí se denomina piggyback: el plugin o agente especial transporta datos de otros hosts - "piggybacked" por así decirlo- junto con sus propios datos. Checkmk coloca estos datos en el directorio tmp/check_mk/piggyback. Todo lo que tienes que hacer en la Configuración es crear hosts con los nombres correctos, y los servicios se les asignarán automáticamente.

En las ediciones comerciales puedes hacer que estos hosts se creen automáticamente. Utiliza el conector Piggyback en la configuración dinámica. Ten en cuenta lo siguiente, si creas los hosts manualmente:

Una vez creados los hosts contenedores, y tras realizar un descubrimiento de servicios, aparecen nuevos servicios en ellos.

Sin embargo, como muchos servicios monitorizados por el agente dentro de los contenedores en realidad muestran información del nodo (por ejemplo, la carga de la CPU, la temperatura y muchos otros parámetros del sistema operativo), se han eliminado.

Por defecto -como ya se ha dicho- se utiliza el ID abreviado de 12 caracteres del contenedor como nombre para el host del contenedor. Opcionalmente, esto puede configurarse de otra manera. Para ello, en el archivo de configuración docker.cfg (ver Ajuste fino del Plugin) establece la opción container_id en long para utilizar el ID completo del contenedor como nombre, o en name para utilizar el nombre del contenedor.

Los usuarios de ediciones comerciales pueden configurar esto en el Agent bakery utilizando la regla Docker node and containers, opción Host name used for containers.

Por cierto: Con el conjunto de reglas Access to agents > General settings > Hostname translation for piggybacked hosts puedes definir reglas bastante flexibles para renombrar los nombres del host contenidos en los datos piggyback. Con este método también puedes resolver el problema de tener contenedores con el mismo nombre en dos nodos Docker diferentes, por ejemplo.

Consulta el artículo El mecanismo piggyback para ver más opciones y una descripción más detallada de esta función.

Dado que el estado del host de un contenedor no puede verificarse realmente mediante paquetes TCP o ICMP, debe determinarse de otra forma. El servicio Docker container status facilita esta tarea: en cualquier caso, comprueba si el contenedor se está ejecutando, por lo que puede utilizarse como herramienta segura para detectar el estado del host. Define una regla en el conjunto de reglas Host Check Command para este fin, y establece la opción Use the status of the service…​ en el servicio mencionado. No olvides establecer las condiciones para que sólo se vean afectados los contenedores. En nuestro ejemplo, todos los contenedores se encuentran en una carpeta con el mismo nombre:

Para monitorizar detalles en el propio contenedor (por ejemplo, procesos en ejecución, bases de datos, archivos de registro, etc.), es necesario que el agente Checkmk esté instalado y se ejecute en el propio contenedor. Esto es especialmente cierto para el despliegue de los plugins de agente. Los tres plugins mem, cpu y diskstat (E/S de disco) funcionan, sin embargo, sin un agente en el contenedor, y son analizados por el agente Checkmk en el propio nodo.

Especialmente en el caso de las imágenes Docker creadas por ti mismo, es posible que desees desplegar el propio agente en el contenedor. En este caso, los datos ya no son analizados -como se ha descrito anteriormente- por el agente del nodo Docker. En su lugar, se ejecuta un agente independiente en cada contenedor. Sin embargo, la llamada a este agente se seguirá realizando mediante un procedimiento piggyback a través del nodo Docker.

Sin embargo, el agente instalado en el contenedor sólo funciona si todos los comandos necesarios también están presentes en el contenedor. Especialmente con los contenedores mínimamente construidos basados en Alpine Linux, es muy posible que elementos elementales como Bash no estén presentes. En tal situación, debes monitorizar el contenedor desde el nodo Docker.

El uso del conjunto de reglas Host Check Command sólo será necesario en este caso si el contenedor no es pingable, pero por lo demás funcionará exactamente como se ha descrito anteriormente.