Monitoring results/rules for host unclear

[slalomsk8er]

Expected Behavior

A host without problems is in state OK and it's easy to figure out why a host is in a certain state.

Current Behavior

• '/usr/bin/icingacli' 'vspheredb' 'check' 'host' '--name' 'HOST-FQDN' --verbose results in:

[CRITICAL] Checking VM
   [CRITICAL] Default Rules
    \_ [OK] Overall VMware status is 'green'
    \_ [OK] Host System is powered on
    \_ [CRITICAL] System booted 54d 22h ago

• no action URL that links back to the ESX host in the vSphereDB
• the "Monitoring" tab on the host details under https://icinga/icingaweb2/vspheredb/host?uuid=0b044c641062ade569d11c4affae0c167ef0875c is missing - it exists for VMs.
• rules for the host show that a uptime of less then 5min generates a warning but everything else is undefined but isn't ignored:

Possible Solution

Ignore undefined thresholds? Add a --verbose flag to the check that enriches the output with the input value and the applied rule to each state.

[CRITICAL] Checking VM
   [CRITICAL] Default Rules - got CRITICAL from "Powerstate"
    \_ [OK] Overall VMware status is 'green'
    \_ [OK] Host System is powered on
    \_ [CRITICAL] System booted 54d 22h ago - got 54d 22h from 48e9ad1a-8f88-4d80-9dd2-8ff74572bf4e for object "0b044c641062ade569d11c4affae0c167ef0875c" state defined in rule "default" "Raise CRITICAL for uptime greater than" with threshold ""

Steps to Reproduce (for bugs)

• update icingaweb2-module-vspheredb
• check a ESX host state via icingacli created via director and used in icingaweb2-module-businessprocess
• wait for user to complain about wrong state on dashboard
• try to figure out why all the ESX hosts are now critcal

Your Environment

• VMware vCenter®/ESXi™-Version: vCenter Server 6.7.0 build-18010599
• Version/GIT-Hash of this module: 1.4.0
• Icinga Web 2 version: 2.10.1
• Operating System and version:
• Webserver, PHP versions: