Check Commands Running on Client, not Satellite

satellite
distributed
icinga2

(Joe Valerio) #1

Hello, I’m working on configuring Icinga2 for the first time, and I have been following the documentation extremely closely, and frankly it is confusing me like crazy! So I will step through how I have it configured and explain how I discovered my problem.

So – I have the top down configuration set up as per the distributed documentation recommends. This means my master zones.conf defines the following
Itself as an endpoint,
The master zone, with itself as the endpoint.
The satellite Endpoint
The satellite zone containing the satellite endpoint with the parent set to master.
All the global options set to True.

The satellite conf is configured for the master to reach to it, and the client confs are configured for the satellite to reach it.

Where I am getting confused is when it introduces the zones.d/satellite/.conf configurations. Per the documentation I should be defining the Endpoint of the client (done), the zone for the client (done), and the Host object of the client (done). I then created a few services, one of which is a “custom” check that exists on the satellite hosts (which is confirmed to be loaded by the constants configuration file.) When I try to restart icinga, I get an error that the check command doesn’t exist on the CLIENT node. I’ve gone and added it to the client node and the error goes away. This is indicating to me the test is running from the client and not the satellite. If this is the case, what is the purpose of the command_endpoint = host.vars.client_endpoint?

Is the documentation just incorrect?


(Kevin Honka) #2

there are settings on each client that controls where the command is executed.

in /etc/icinga2/features-enabled/api.conf are two settings

  accept_commands = true
  accept_config = true

By default both are false.
accept_commands, controls wether the client accepts commands from the satellite/master and executes them
accept_config, controls the synchronisation of the config from master to client. If you set both to false, the checks will run on the satellite. This can be useful for ssh checks that have to run remote.


(Roland) #3

Without command_endpoint a check is executed on an endpoint of its associated zone. If you want to run a check locally on a client you need to add

command_endpoint = host.name

to the service definition.


(Joe Valerio) #4

Hello – This makes sense, however I went and adjusted those values to false, restarted the icinga2 service on the Client and Satellite nodes, then when I went to the master node I’m still receiving the following error:

Nov 27 09:07:12 <master> icinga2[72987]: [2018-11-27 09:07:12 -0500] critical/config: Error: Validation failed for object 'client01!OpenVPN' of type 'Service'; Attribute 'check_command': Object 'check_openvpn' of type 'CheckCommand' does not exist.

Edit:
For reference, here is my service entry:

apply Service "OpenVPN" {
  check_command = "check_openvpn"
  assign where host.zone == "prod1-na1"
}

Here is my api config on the client node:

/**
 * The API listener is used for distributed monitoring setups.
 */
object ApiListener "api" {
  accept_commands = false
  accept_config = false
}

(Joe Valerio) #5

This api.conf DID solve my issues, actually. I found that there was one other change required to get my tests working. Thanks for the help!!!


(Joe Valerio) #6

I take back my previous statement. This is still an issue. I got around it by utilizing NRPE for checks, but anything outside of NRPE throws the same errors. The check exists on the satellite, but not the client nodes:

Nov 27 14:41:07 <master> icinga2[98790]: [2018-11-27 14:41:07 -0500] critical/config: Error: Validation failed for object 'client01!Customer Portal' of type 'Service'; Attribute 'check_command': Object 'check_customer_portal' of type 'CheckCommand' does not exist.
Nov 27 14:41:07 <master> icinga2[98790]: Location: in /etc/icinga2/zones.d/prod1-na1/services.conf: 73:3-73:41
Nov 27 14:41:07 <master> icinga2[98790]: /etc/icinga2/zones.d/prod1-na1/services.conf(71):
Nov 27 14:41:07 <master> icinga2[98790]: /etc/icinga2/zones.d/prod1-na1/services.conf(72): apply Service "Customer Portal" {
Nov 27 14:41:07 <master> icinga2[98790]: /etc/icinga2/zones.d/prod1-na1/services.conf(73):   check_command = "check_customer_portal"
Nov 27 14:41:07 <master> icinga2[98790]:                                                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Nov 27 14:41:07 <master> icinga2[98790]: /etc/icinga2/zones.d/prod1-na1/services.conf(74):   assign where host.zone == "prod1-na1" && host.vars.type == "web"
Nov 27 14:41:07 <master> icinga2[98790]: /etc/icinga2/zones.d/prod1-na1/services.conf(75): }
Nov 27 14:41:07 <master> icinga2[98790]: [2018-11-27 14:41:07 -0500] critical/config: 6 errors