Check command does not exist

(azthec) #1

Hi, I am trying to debug why an added command does not seem to be recognized by (I assume) the Icinga Agent running on a slave machine.

I have another older working install where I have also added custom commands (Plugin Check Command) in a very similar fashion, so I do not understand why this error occurs. The version where the issue occurs is running in a Docker compose solution. The default commands (eg: disk-windows, uptime-windows) run flawlessly after configuration. The agent was configured via the Director kickstart script.

System information:

  • Platform: Debian GNU/Linux
  • Platform version: 10 (buster)
  • Kernel: Linux
  • Kernel version: 4.9.184-linuxkit
  • Architecture: x86_64

Icinga2: r2.11.1-1
IcingaWeb2: 2.7.3
Director 1.7.0

Steps to reproduce
All the new configurations are done via IcingaWeb2 Director.

  1. Create new Plugin Check Command under Icinga Director > Commands > Commands.
  2. Create new Service Template under Icinga Director > Services > Service Templates.
  3. Create new Service under Icinga Director > Services > Single Services.
  4. Check command never resolves.
    When running the check the following message is returned with an UNKNOWN state “Check command … does not exist”.
Inspect object properties
__name “vm-prod-test!check-proc-windows”
acknowledgement 0
acknowledgement_expiry 0
action_url “”
active true
check_attempt 1
check_command proc-windows
check_interval 120
check_period “”
check_timeout null
command_endpoint “vm-prod-test”
display_name “check-proc-windows”
downtime_depth 0
enable_active_checks true
enable_event_handler true
enable_flapping false
enable_notifications true
enable_passive_checks true
enable_perfdata true
event_command “”
flapping false
flapping_current 0
flapping_last_change 0
flapping_threshold 0
flapping_threshold_high 30
flapping_threshold_low 25
force_next_check false
force_next_notification false
ha_mode 0
handled false
host_name “vm-prod-test”
icon_image “”
icon_image_alt “”
last_check 1571736750.728161
last_hard_state 3
last_hard_state_change 1571734503.167683
last_reachable true
last_state 3
last_state_change 1571734124.641337
last_state_critical 0
last_state_ok 0
last_state_type 1
last_state_unknown 1571736750.728207
last_state_unreachable 0
last_state_warning 0
max_check_attempts 3
name “check-proc-windows”
next_check 1571736870.720000
notes “”
notes_url “”
original_attributes null
package “director”
paused false
previous_state_change 1571734124.641337
problem true
retry_interval 30
severity 72
state 3
state_type 1
type “Service”
vars { proc_name: “java.exe” }
version 0
volatile false
zone “master”

On the master:

  • The command definition appears under lib\icinga\api\zones\global-templates\director\commands.conf
  • The service template appears under lib\icinga\api\zones\director-global\director\service_templates.conf
  • The service appears under lib\icinga\api\zones\master\director\services.conf

I am unable to find the definitions on the agent, but running the object list command returns nothing.


PS C:\Program Files\ICINGA2\sbin> .\icinga2.exe object list --type checkcommand --name proc-windows
PS C:\Program Files\ICINGA2\sbin> .\icinga2.exe object list --type checkcommand --name check-proc-windows
PS C:\Program Files\ICINGA2\sbin> .\icinga2.exe object list --name check-proc-windows
PS C:\Program Files\ICINGA2\sbin> .\icinga2.exe object list --name proc-windows

I have attempted to specify the zones manually, overriding the default ones provided by the Icinga Director but to no avail.

(azthec) #3

I have verified that the zones are not being synchronized correctly, as the following command does not report the director-global or global-templates zones.

.\icinga2.exe object list --type Zone

By manually running the Agent daemon I have found out the following error is output when booting:

warning/ApiListener: Ignoring config update from endpoint 'icinga2' for unknown zone 'director-global'.
warning/ApiListener: Ignoring config update from endpoint 'icinga2' for unknown zone 'global-templates'.

Still debugging the origin of this issue at this point, any recommendations are appreciated.