Not everything worth monitoring can be polled: an SNMP trap, a batch job
that alone knows its own outcome, an external system pushing results in.
A passive check is an object whose state comes from outside, not from
jaque running a probe. The contract has one non-negotiable clause: the
operator names a freshness_threshold, so that when results stop arriving
jaque has an opinion about it. An unbounded freshness window is the
silent-green failure this check type exists to prevent, and the schema
refuses to default it.
1. Declaring one
services: backup: check: {
type: "passive"
freshness_threshold: "24h"
stale_status: "CRITICAL"
}
freshness_threshold is required and has no default; a passive check
without one is a concretion error at load. stale_status is the status
the object is forced to once a result is older than the threshold:
UNKNOWN by default, because that is the honest reading (jaque does not
know, rather than knows something is broken), or WARNING or CRITICAL
if the operator prefers. It cannot be OK: staleness never means
"everything is fine".
2. When results stop arriving
A fresh result reschedules the object's next evaluation at the moment it
would go stale. If nothing arrives by then, the engine synthesizes a
result carrying stale_status and the object walks the same soft-to-hard
ladder an active check would: max_attempts and retry_interval govern
the steps, check_interval is how often staleness is re-evaluated once
hard, and flap behaves as it does anywhere else. A dead sender keeps
re-alerting on that cadence rather than jumping straight to hard.
timeout is the one #Schedule field with no meaning for a passive
check.
3. Feeding results in
Two doors, one destination; FIFO and API has the wire detail of each.
The Nagios-compatible FIFO accepts PROCESS_SERVICE_CHECK_RESULT and
PROCESS_HOST_CHECK_RESULT lines, for anything that already speaks the
legacy external-command format.
The ConnectRPC API's ProcessCheckResult and ProcessCheckResults
(batch) RPCs are the fit for a translator receiving bursts: the batch
call validates all-or-nothing and enqueues in order.
Both land on the same command channel the engine consumes, tagged
origin: passive. A result for an object not declared passive is
logged as a warning and discarded, never applied; a result for an object
owned by another engine is forwarded to it. SNMP
traps is the reference pipeline that turns a
trap flood into passive results without forking a process per trap.
4. Security considerations
A passive result is an assertion about an object's state made by whoever
can reach the FIFO or the API. The FIFO trusts anyone who can write the
file; the API trusts anyone who presents -api-token, or anyone at all
when no token is configured. The passive declaration is the only
per-object guard: an active object cannot be overwritten from outside,
whatever the sender claims.