Disregard passive check results while no active checks are being scheduled due to violated dependencies.
This copes with the fact that programs feeding passive check results into Icinga may have no notion of reachability and so drive a checkable into HARD state although dependencies have caused active check scheduling being suspended. This may prevent superflous problem notifications being emitted during recovery.
As disable_checks defaults to false, it was regarded OK (by @Al2Klimov) to make this behaviour (which resembles the active check case) unconditional and not conditionalize it on an additional attribute.
In the description of disable_checks, note that a value of true both disables scheduling of active checks and drops passive check results.
The `process-check-result` action can now optionally set the
`ttl` parameter. This overrules the configured freshness
check (check_interval).
The main idea behind this is to allow the external sender
to specify when the next check result is coming in.
For example, a backup script which should be run every
24h can specify the exact expected next check result.
The addition to the CheckResult class is necessary to
forward the check result throughout the cluster and
calculate the `next_check` value on each node. This
allows us to send in a check result on a satellite,
and the master determines the freshness and possible
notifications/state changes for Icinga Web 2.
What does this change?
* Remove use of spaces for formatting
These could be found by using `grep -r -l -P '^\t+ +[^*]'
* Removal of training whitespaces
* A few lines longer than 120 chars
It was preventing email notifications with default settings, as `persistent` defaults to false and therefore `notify` was not set.
Signed-off-by: Michael Friedrich <michael.friedrich@icinga.com>
This patch also moves the next check updates for passive
check results into ProcessCheckResult(). That way the
next check status updates for DB IDO work in a sane way
again.
refs #11336
Only valid for active check results. The API actions were
missing that marker similar to the external command processor.
The initial OK -> NOT-OK transition should use the retry_interval
but nothing else.
fixes#11336
This reverts commit 2a11b27972e4325bf80e9abc9017eab7dd03e712.
This patch does not properly work and breaks the check_interval setting
for passive checks. Requires a proper patch.
refs #11248
refs #11257
refs #11273
(the old issue)
refs #7287
Otherwise the changes from #7287 already take care of setting
the proper next check time from inside ProcessCheckResult().
There is no need to use the generic OnNextCheckChanged signal
but instead we're using a new one, locally just for DB IDO.
fixes#11019
