I have a situation where Icinga reports two satellite hosts as down, even though I can ping them from the master in an OS shell. This makes me wonder: where does Icinga run its host checks for satellites? I thought (in the absence of command_endpoint) its on the master. Am I mistaken?
It depends on the zone of the satellite’s host object. If you’ve configured the host objects for your satellites in your master zone, hostalive ping is executed at the master.
1 Like
Thanks for you quick reply. The host objects are defined in the satellites’ zones in my case and as it turns out those satellites cannot ping themselves. So that explains the overall picture, I guess.
This is still a bit puzzling to me: I now have another case where an agent (unlike in the earlier example) can ping itself on the OS level and where its host object is defined in its local zone. Even though its status is DOWN. If I add zone = "master" (i.e. a reference to the parent zone) to the same host object the status switches to UP and indeed the master node can also ping the agent the OS level. But should the status not be UP in both cases, because both zone’s endpoint can ping?
Are there any concrete entries in the log files (icinca2.log and/or debug.log) that would allow me to determine where these checks are really executed (i.e. who is doing the pinging)? I can see “information/HttpServerConnection: Request: POST /v1/actions/reschedule-check” (i.e. the checks invocation when I issue “Check Now” in Icinga Web) in icinga2.log, but apparently no further trace.
You could query icinga service objects with icinga2 object list ... with focus on zone and command_endpoint attributes. if command_endpoint is defined than the check will be executed there. If not it will be executed on an endpoint node of the zone.
You could also have a look at Check Source in icingaweb or a query result of icinga’s Rest API.
1 Like