Configuring Icinga agent to periodically send check_command results

I am using Icinga 2 (icinga server version v2.11.0-23-g0629617 and agent version r2.8.2-1) in a passive agent configuration. Currently, my checks all appear to be configured properly and working when I explicitly hit ‘Check Now’ in the Icinga web dashboard. A current response is returned from the agent. I can see the check command fire on the client. However, the check command never fires automatically. My objective is to have the agents fire the check command per a schedule configured at the master, and have the agents automatically execute the check command and connect to the server per schedule with update check results.

I am using standard check commands (i.e. check_disk) configured at the server as Passive checks:

template Service "Disk Checks Tmpl" {
    check_command = "disk"
    enable_active_checks = false
    enable_passive_checks = true
    command_endpoint = host_name
}

The agents are configured to allow connections to the Server but not to accept connections per the zone.conf file below (because I cannot count on a well known port being available on every agent):

object Endpoint "icinga2" {
        host = "myserver"
        port = "5665"
}
object Zone "master" {
        endpoints = [ "icinga2" ]
}
object Zone "global-templates" {
        global = true
}
object Zone "director-global" {
        global = true
}
object Endpoint NodeName {
}
object Zone ZoneName {
        endpoints = [ NodeName ]
        parent = "master"
}

As mentioned above, the check commands work and return results to the icinga server, the configurations of the check commands are synced between the client and server, and everything works as expected except that check commands only execute when check now is explicitly invoked from server. Since I do not always have a well known port for the agent on my hosts / docker containers, I am looking to avoid having the server connect to the agent and keep the connections from agent to server.

Here is a screenshot of successful check command but showing stale last update:

Hi & welcome to the icinga community.

You’ve switched off checks to run automatically. But if I understood you correctly you just want to make sure that only the agent is connecting to its master and these are to different topics. The latter is configured at the endpoint objects. For avoiding your master to initiate the connection to an agent, just define agent’s endpoint without a host variable. Agents needs to be configured as your have that already.

In addition you need to follow Top Down Config Sync. This will enable the scheduler at your agents (which is by the way not supported for Windows) and it works even the connection to the master is down.

You should update your environment as the versions 2.11 with 2.8 is not supported. v2.11.0-23-g0629617 looks like pre-release and have some bugs which are already fixed.

2 Likes

Thanks @rsx. I have the periodic checks working now.

I am a bit vague on exactly what Top Down Config Sync does and does not do. Specifically, I know that using Director on my Master, I am able to tweak my arguments / etc. to check commands and the agent responds as appropriate IFF it knows about the check command / the configuration of the check command matches between the agent and the master. However, if I add new arguments to the check command definition and the service definition in director, the agent does not respond properly until I manually update the check command definition on the agent host.

Is this expected? Should Config Sync automatically update the definition of check commands on the agent?

Thanks again,
Phil Usatine

p.s. BTW, the reason I am using older agents is that my agents are SLES (SuSE Enterprise) 12.2 hosts and there are no newer builds of Icinga 2 available than 2.8, whereas my master is Centos7 where I am now using the latest release build of 2.11. They seem to be working together well.

Yes, if you have enabled accept_config for the ApiListener and you have a global zone for your command objects.

Thanks. Yes, this worked. I went into /etc/icinga2/features-enabled/api.conf and added the accept_config=true line to object ApiListener “api”

Configs are now getting updated based on changes in director.