It looks like Top Down Config Sync is no longer valid?

I’m trying to configure TopDown Config Sync with the zone trick described here and here. However, if the host object is in the parent zone, the checks are scheduled by the parent. Is this intended?

Not sure if I or you are missing something, but yes it is intended that scheduling happens in the zone where the host object is located, and execution happens in this zone or if a command endpoint is set for the service on the specified endpoint (which is done in the Director simply by setting run on agent to yes).

Did you read the linked article? I’m trying to configure an agent to schedule checks on its own.

Hello @rsx!

Please could you share concrete config and what do you expect/get?

Best,
AK

Hi @Al2Klimov,

I’m trying to configure an agent to schedule checks on its own as described here and here.

/etc/icinga2/zones.d/iatl.em.lan/host.conf:

object Host "iatl.em.lan" {
   address = "192.168.1.223"
   check_command = "hostalive4"
   vars.os = "Linux"
   zone = get_object(Zone, name).parent
}

Thanks
rsx

In this case: yes, the zone you’ve set is responsible for the host checks.

According to the linked article I’d assume the behavior in the past was different.

Or simplified question: Is there still a change that an agent can be configured to schedule its own checks?

You could put the desired checkables in the agent’s zone directory and not override the zone.

I know, but then hostalive and any other remote check is running locally as well (haven’t been trying to change it to its parent using command_endpoint, but I’d presume this direction of accept_command is not valid).

To me it looks like there was a change (I’d assume with 2.11) and I’m not sure if that scenario makes sense any longer.

Have you tried to override the services’ zones?

No, what is your recommendation?

To put the Host in the agent Zone and to override the Services’ Zones as desired.

Cool, thanks. This is working partly:

  • All service checks as expected
  • zone for host’s check_command cannot be reconfigured, hence, no suitable solution here?
  • perfdata is replayed but not stored in influxdb as described here which now belongs to Linux as well

But you put the Host into the desired Zone, didn’t you?

Yes, in the agent’s zone. Hence, the host check_command is executed locally on that host (which does not make sense).

BTW: Shall I add a comment for the influxdb issue that it happens on linux as well?

  1. What would make sense?
  2. Yes, please.
  1. e.g. hostalive or cluster-zone running on parent
  2. done

Please try setting the services’ zones respectively.

For check_command on host object?

No, the zone attribute on the hostalive and cluster-zone services.