Debian 12: algo no va bien con el agente

Verificar los Nombres de los Servicios Instalados:

Basado en el mensaje de instalación, parece que el paquete instala varios servicios, incluidoscheck-mk-agent@.service, check-mk-agent-async.service, cmk-agent-ctl-daemon.service, y check-mk-agent.socket, pero no un servicio llamado check-mk-agent.service directamente. Intenta verificar el estado de los servicios instalados, por ejemplo:

systemctl status check-mk-agent@.service
systemctl status check-mk-agent-async.service
systemctl status cmk-agent-ctl-daemon.service
systemctl status check-mk-agent.socket

Activar el Socket o Servicios Específicos:

En lugar de intentar iniciar un servicio llamado check-mk-agent, es posible que necesites habilitar e iniciar el socket check-mk-agent.socket o uno de los servicios específicos mencionados anteriormente. Intenta:

Y luego verifica si el socket está escuchando:

Revisar los Logs del Sistema:

Si aún encuentras problemas, revisa los logs del sistema para obtener más información sobre por qué el servicio o socket no se puede iniciar:

Busca entradas relacionadas con check-mk-agent o los servicios específicos que se mencionaron durante la instalación.

Consultar la Documentación:

La documentación de Check_mk puede tener información específica sobre la configuración y gestión de los agentes en distintas distribuciones de Linux. Esto puede ofrecer pistas sobre pasos adicionales necesarios después de la instalación.

Verificar la Configuración del Firewall:

Asegúrate de que tu firewall permite conexiones entrantes en el puerto por defecto del agente de Check_mk (6556/tcp), ya que esto es necesario para que el servidor de Check_mk se comunique con el agente.

Comprobar la Configuración del Agente:

Revisa la configuración del agente de Checkmk en /etc/check_mk/ para asegurarte de que esté configurado correctamente según tus necesidades.

Siguiendo estos pasos, deberías poder identificar y solucionar el problema con la activación del servicio check-mk-agent en tu sistema Debian.

Basándose en la salida de los comandos que ejecutaste, parece que los servicios del agente de Check_mk se han instalado y están funcionando correctamente en tu sistema. Aquí tienes un resumen de lo que indican los estados de los servicios:

• check-mk-agent-async.service está activo y en ejecución. Este servicio se encarga de realizar tareas asincrónicas para el agente de Check_mk. Está corriendo correctamente desde hace unos minutos.

• cmk-agent-ctl-daemon.service también está activo y en ejecución. Este servicio es el controlador del agente de Check_mk, gestionando las operaciones y la configuración del agente.

• check-mk-agent.socket está activo y escuchando. Este socket permite la comunicación local con el agente de Check_mk. Que esté en estado "listening" indica que está listo para aceptar conexiones.

La confusión inicial parecía deberse a un intento de verificar el estado de un servicio check-mk-agent@.service, que no existe como tal. En realidad, el agente de Check_mk utiliza el socket check-mk-agent.socket para las conexiones, junto con los servicios check-mk-agent-async.service y cmk-agent-ctl-daemon.service para sus operaciones.

No necesitas realizar ninguna acción adicional para iniciar el servicio del agente, ya que los componentes necesarios ya están activos y funcionando. El agente de Check_mk debería estar listo para aceptar conexiones y comunicarse con el servidor de Check_mk.

Si quieres verificar que el agente de Check_mk está respondiendo correctamente, puedes intentar hacer una solicitud al socket o al puerto que escucha el agente (por defecto, el 6556) con algo como:

O, si el agente está configurado para escuchar en TCP:

Esto debería devolverte la salida del agente de Check_mk, mostrando información del sistema que está siendo monitoreado.

La salida del comando nc -U /run/check-mk-agent.socket | head confirma que el agente de Checkmk está funcionando correctamente en tu sistema. Aquí tienes un breve resumen de lo que indican las líneas:

• Version: Muestra la versión del agente de Checkmk instalado, en este caso, 2.2.0p24.
• AgentOS: El sistema operativo detectado por el agente, linux.
• Hostname: El nombre del host en el que está instalado el agente, ns3144843.
• AgentDirectory: La ubicación del directorio de configuración del agente de Checkmk, /etc/check_mk.
• DataDirectory: El directorio donde el agente almacena datos, /var/lib/check_mk_agent.
• SpoolDirectory: El directorio para datos temporales y de spooling, /var/lib/check_mk_agent/spool.
• PluginsDirectory: La ubicación donde se almacenan los plugins del agente, /usr/lib/check_mk_agent/plugins.
• LocalDirectory: El directorio para scripts locales personalizados, /usr/lib/check_mk_agent/local.

Esto indica que el agente está listo y proporcionando datos como se espera. Estos datos pueden ser recogidos por el servidor Checkmk para el monitoreo del sistema.

Si tienes un servidor Checkmk configurado para monitorear este host, debería poder conectarse al agente y recoger esta información. Asegúrate de que la configuración del servidor Checkmk esté actualizada para incluir este host y que no haya problemas de red o de firewall que impidan la comunicación entre el servidor Checkmk y el agente.

Si aún no has configurado este host en tu servidor Checkmk, este sería el próximo paso para asegurarte de que el sistema está siendo monitoreado adecuadamente. Esto generalmente implica añadir el host en la interfaz de usuario de Checkmk y configurar los servicios que deseas monitorear.

Mensaje: Failed to get properties: Unit name check-mk-agent@.service is neither a valid invocation ID nor unit name.

El mensaje de error que recibiste, "Failed to get properties: Unit name check-mk-agent@.service is neither a valid invocation ID nor unit name", sugiere un problema al intentar consultar el estado de un servicio systemd con un nombre inválido o mal formado. En el contexto de Checkmk y cómo se despliegan sus agentes, parece haber habido un malentendido en cómo se intentó usar el comando.

Entendiendo el Error

El servicio check-mk-agent@.service parece estar intentando usar una sintaxis de instancia de servicio con @, pero sin proporcionar un identificador de instancia después del @. Los nombres de unidades de servicio systemd que incluyen @ generalmente se utilizan para instancias de servicio "templated", donde puedes iniciar múltiples instancias del mismo servicio con diferentes configuraciones pasando un identificador único para cada instancia después del @.

Solución y Verificación Correcta

Dado que los servicios relevantes del agente Check_mk instalados y que se muestran activos son check-mk-agent-async.service, cmk-agent-ctl-daemon.service, y check-mk-agent.socket, no necesitas utilizar una sintaxis de instancia de servicio (con @) para estos servicios.

Para estos casos, el comando systemctl status seguido por el nombre exacto del servicio o socket, como ya hiciste, es el método correcto para verificar su estado. No hay necesidad de intentar verificar un servicio con el nombre check-mk-agent@.service, ya que este no coincide con los nombres de los servicios o sockets desplegados por el paquete del agente Check_mk según la salida que proporcionaste.

Si tu intención era verificar el estado de un servicio específico para el agente de Check_mk, deberías usar uno de los nombres de servicio exactos como se muestra en tus comandos anteriores, por ejemplo:

systemctl status check-mk-agent-async.service
systemctl status cmk-agent-ctl-daemon.service
systemctl status check-mk-agent.socket

Si estabas buscando una funcionalidad específica relacionada con las instancias de servicios en systemd y Check_mk que creías que requería una sintaxis de @, te recomendaría revisar la documentación de Check_mk o la ayuda de systemd para servicios "templated" para aclarar cómo debería formarse correctamente el comando.

Comprobar contra socket y contra localhost

Cuando ejecutas el comando nc -U /run/check-mk-agent.socket | head y obtienes la información del agente de Check_mk, esto indica que el agente está funcionando correctamente a través del socket Unix /run/check-mk-agent.socket. Sin embargo, cuando intentas conectarte al puerto TCP 6556 con nc 127.0.0.1 6556 | head y no recibes ninguna respuesta, sugiere que el agente de Check_mk no está configurado para escuchar en ese puerto TCP o que hay un problema de configuración que impide la conexión.

Hay varias razones por las cuales podrías estar experimentando este comportamiento:

1. El Agente de Check_mk No Está Configurado para TCP: La instalación predeterminada de algunos agentes de Check_mk puede estar configurada para usar solo sockets Unix y no escuchar en un puerto TCP. Esto depende de cómo se compiló el paquete y de la configuración específica del agente.

2. Configuración de Firewall: Aunque mencionaste que esto se ejecuta localmente, siempre es bueno verificar que no haya reglas de firewall bloqueando el acceso al puerto 6556 en localhost.

3. El Servicio del Agente Está Configurado para Usar Solo Sockets Unix: Si el agente está configurado para usar exclusivamente sockets Unix, no responderá a las conexiones TCP.

Pasos para Diagnosticar y Solucionar

Verificar la Configuración del Agente: Revisa la configuración del agente de Check_mk para asegurarte de que está configurado para escuchar en el puerto 6556. La configuración puede encontrarse en /etc/check_mk/, específicamente en archivos como check_mk_agent.cfg o similar.

Verificar la Escucha en el Puerto 6556: Puedes usar ss -tuln | grep 6556 o netstat -tuln | grep 6556 para verificar si algún servicio está escuchando en el puerto 6556.

Revisar la Documentación de Check_mk: La documentación de Check_mk puede ofrecer indicaciones sobre cómo configurar el agente para escuchar en un puerto TCP si no está habilitado por defecto.

Reconfigurar o Reiniciar el Agente: Si encuentras que el agente debería estar escuchando en TCP pero no lo está, intenta reconfigurar el agente según la documentación de Check_mk y reinicia el servicio del agente.

Alternativa

Si tu objetivo es asegurarte de que el servidor Check_mk pueda monitorear este host, y el acceso a través del socket Unix funciona correctamente, podrías configurar el servidor Check_mk para usar este método de comunicación si es compatible y si solo necesitas monitorear el sistema localmente o puedes configurar un enfoque de reenvío de solicitudes al socket Unix desde TCP en caso de ser absolutamente necesario usar TCP.

Si el comando ss -tuln | grep 6556 no devuelve ningún resultado, significa que no hay ningún servicio escuchando en el puerto TCP 6556 en tu sistema. Esto está en línea con el comportamiento que observaste cuando intentaste conectarte al puerto 6556 con nc y no recibiste respuesta.

Via socket funciona, pero vía localhost no funciona

Esto confirma que el agente de Check_mk no está configurado para escuchar en un puerto TCP, o si lo está, algo está impidiendo que el servicio se inicie o se enlace correctamente a ese puerto. Aquí hay algunas acciones que puedes tomar para resolver o diagnosticar más a fondo este problema:

Revisar la Configuración del Agente de Check_mk

• Asegúrate de que el agente esté configurado para escuchar en el puerto TCP 6556. Esto puede implicar revisar los archivos de configuración específicos del agente dentro de /etc/check_mk/ o la documentación del agente para cualquier paso de configuración necesario para habilitar la escucha TCP.

Comprobar la Existencia de un Firewall

• Aunque mencionaste que el comando se ejecuta localmente, es bueno asegurarse de que no haya un firewall bloqueando el puerto 6556. Puedes verificar las reglas de firewall con sudo iptables -L o sudo ufw status, dependiendo de cuál estés utilizando.

Revisar los Logs del Sistema y del Agente

• Los logs del sistema o del agente de Check_mk pueden ofrecer pistas sobre por qué el agente no está escuchando en el puerto 6556. Puedes revisar los logs del sistema con journalctl o buscar logs específicos del agente de Check_mk en su directorio de configuración o en /var/log/.

Reiniciar el Agente o el Sistema

• Si has realizado cambios en la configuración del agente para habilitar la escucha en el puerto TCP y aún no ves el puerto 6556 abierto, intenta reiniciar el servicio del agente o incluso el sistema completo para asegurarte de que todos los servicios se inicien correctamente.

Verificar la Versión y la Documentación del Agente

• Asegúrate de que la versión del agente de Check_mk que estás utilizando soporte la escucha en un puerto TCP y revisa la documentación por cualquier paso adicional o requisito de configuración que pueda haber sido pasado por alto.

Si después de revisar estos puntos el agente aún no escucha en el puerto TCP 6556, podría ser útil consultar la documentación de Check_mk o buscar asistencia en foros de la comunidad de Check_mk para obtener ayuda específica relacionada con la versión del agente que estás utilizando y tu configuración particular.

El archivo super-server.cfg

El archivo super-server.cfg es parte de la configuración del agente de Checkmk y controla cómo el "super servidor" (normalmente implementado a través de xinetd o systemd) gestiona las conexiones entrantes al agente. A continuación, te proporciono un ejemplo de cómo podría verse un archivo super-server.cfg con varios parámetros configurables. Ten en cuenta que este es solo un ejemplo y los parámetros específicos y sus valores pueden variar según tus necesidades y la versión del agente de Checkmk que estés utilizando.

# /etc/check_mk/superserver.cfg
# Configuration of the Checkmk agent super server.

# Specify the user the agent runs as. Usually "root" is needed to collect most metrics.
user=root

# Define the port on which the agent listens. The default is 6556.
port=6556

# Only allow connections from certain IP addresses or networks. Use CIDR notation.
# Example: allow only connections from the local network.
only_from = 127.0.0.1/32 192.168.0.0/24

# Maximum parallel connections to the agent.
# This prevents overload of the monitored system by too many simultaneous connections.
max_parallel_connections=50

# Log file for errors and debug messages. Ensure the agent user has write access.
log_file=/var/log/check_mk_agent.log

# Log level: 0 = off, 1 = on (log errors only), 2 = debug (verbose logging).
log_level=1

# Disable or enable the agent. Useful for maintenance or troubleshooting.
disable=no

# Set the connection timeout for handling incoming connections.
# This is useful to prevent hanging checks.
connection_timeout=60

# Banner shown when someone connects to the agent.
# Useful for identifying the agent or displaying legal notices.
banner="Welcome to the Checkmk agent on %H"

# Define a list of commands that can be executed via the agent.
# This is for plugins or local checks that need parameters.
# Example: Allowed command with argument
# allowed_commands = check_disk!20%!10%!/

Recuerda que este archivo debe ser adaptado a tus necesidades específicas. Algunas configuraciones, especialmente las relacionadas con la seguridad como only_from, son importantes para evitar accesos no autorizados al agente. Además, asegúrate de que cualquier cambio en la configuración sea soportado por tu versión del agente de Checkmk y testeado en un entorno seguro antes de aplicarlo en producción.

Para implementar este archivo, simplemente crea o edita super-server.cfg en el directorio /etc/check_mk/ en tu servidor donde está instalado el agente de Checkmk, y luego reinicia el servicio del agente para que los cambios tengan efecto. La forma de reiniciar el servicio puede variar dependiendo de cómo está configurado (por ejemplo, usando systemctl restart check_mk.socket si está usando systemd sockets).

Reiniciar el agente

Para reiniciar el agente de Checkmk y aplicar los nuevos parámetros de configuración, el proceso variará dependiendo de cómo esté instalado y configurado el agente en tu sistema. Si el agente está configurado para funcionar a través de xinetd o systemd, aquí te muestro cómo puedes proceder en cada caso:

Si el Agente se Ejecuta a través de xinetd

1. Recargar la Configuración de xinetd: Después de hacer cambios en la configuración del agente, necesitas decirle a xinetd que recargue su configuración. Esto se puede hacer con el siguiente comando:

   shCopy code

   sudo systemctl reload xinetd

   Este comando le pide a xinetd que recargue su configuración sin necesidad de reiniciar el servicio completamente.

Si el Agente se Ejecuta a través de systemd

Para sistemas que usan systemd para gestionar el agente (por ejemplo, si tienes un socket de systemd o un servicio para el agente de Checkmk):

1. Recargar la Configuración del Daemon systemd: Primero, puedes recargar la configuración de systemd para asegurarte de que cualquier cambio en los archivos de unidad sea reconocido:

   shCopy code

   sudo systemctl daemon-reload

2. Reiniciar el Socket o Servicio: Luego, si el agente de Checkmk está configurado para usar un socket de systemd, puedes reiniciar el socket:

   shCopy code

   sudo systemctl restart check-mk-agent.socket

   O si está configurado como un servicio:

   shCopy code

   sudo systemctl restart check-mk-agent.service

   Nota: Asegúrate de usar el nombre correcto del socket o servicio. Este nombre puede variar según cómo se configuró o instaló el agente.

Verificación

Después de reiniciar el agente, puedes verificar que esté corriendo y escuchando como se espera. Para servicios gestionados por xinetd, puedes revisar los logs de xinetd o usar herramientas como netstat o ss para ver si el puerto del agente está escuchando. Para servicios o sockets de systemd, puedes verificar su estado con systemctl status.

Ejemplo de Verificación para un Servicio de Systemd:

O para un socket:

Esto te dará el estado actual y te permitirá confirmar que los cambios de configuración han sido aplicados correctamente.