Monitorización de Docker

Por supuesto, lo interesante es la monitorización de los contenedores Docker. Esto se implementará automáticamente al instalar los Plugins; sin embargo, los servicios no se asignarán al nodo Docker, sino que Checkmk asume un único host por contenedor Docker.

El mecanismo que se utiliza aquí se llama piggyback: El complemento o agente especial transporta datos de otros hosts —«a cuestas», 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 tipo de conexión «Piggyback data» en la administración dinámica del host. Ten en cuenta lo siguiente si creas los hosts manualmente:

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

Si tienes un agente de Linux instalado en el contenedor, se ejecutará automáticamente. Sin embargo, dado que muchos servicios supervisados por el agente dentro de los contenedores muestran en realidad información del nodo (por ejemplo, la carga de la CPU, la temperatura y muchos otros parámetros del sistema operativo), estos se han eliminado.

Por defecto —como se ha mencionado anteriormente— se utiliza el ID corto de 12 caracteres del contenedor como nombre del host del contenedor. Esto se puede configurar de forma diferente si se desea. Para ello, en el archivo de configuración docker.cfg (consulta Ajuste preciso 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 las ediciones comerciales pueden configurar esto en Agent bakery utilizando la regla Docker node and containers, opción Host name used for containers.

Por cierto: con el conjunto de reglas «Host name 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 Docker 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 se puede verificar realmente mediante paquetes TCP o ICMP, esto debe determinarse de otra manera. El servicio Docker container status facilita esto: en cualquier caso, check si el contenedor está en ejecución y, por lo tanto, puede utilizarse como una herramienta segura para detectar el estado del host. Define una regla en el conjunto de reglas Host check command para este fin y configura la opción Use the status of the service…​ con el servicio mencionado. No te olvides de configurar las condiciones para que solo se vean afectados los contenedores. En nuestro ejemplo, todos los contenedores se encuentran en una carpeta con el mismo nombre:

Para supervisar detalles dentro del 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 dentro del propio contenedor. Esto es especialmente cierto para la implementación de plugins de agente. Sin embargo, los tres plugins mem, cpu y diskstat (E/S de disco) funcionan sin un agente en el contenedor y son analizados por el agente Checkmk en el propio nodo.

Especialmente en el caso de imágenes Docker creadas por ti mismo, es posible que quieras implementar 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. No obstante, la llamada a este agente seguirá estando integrada en un procedimiento piggyback a través del nodo Docker.

No obstante, el agente instalado en el contenedor solo funciona si todos los comandos necesarios también están presentes en el contenedor. Especialmente con contenedores de construcción mínima basados en Alpine Linux, es muy posible que no estén presentes elementos básicos como Bash. En tal situación, deberías supervisar el contenedor desde el nodo Docker.

El uso del conjunto de reglas «Host check command» solo será necesario en este caso si no se puede hacer ping al contenedor, pero, por lo demás, funcionará exactamente como se ha descrito anteriormente.