Reachability hint¶
When a server dies, typically every service on it fails as well. Without a reachability hint, each individual check fires its own alert mail — a host with 12 services sends 12 mails for exactly one problem.
The reachability hint (in the UI also "reachability check" or "reachability anchor") marks one check per host as the "is the host online at all?" signal. If this check alerts, the host counts as unreachable and the alerts of the host's other checks are suppressed. You get one message: the one of the reachability check itself.
Typically this is a ping check. Ping checks created in a profile are automatically marked as reachability hint. When a host without an agent but with an IP address or DNS name is created, Vesana makes sure there is an anchor if none exists yet: an existing ping is marked, otherwise a ping check (60 s) is created. Agent hosts need none — there the agent heartbeat counts.
Relation to dependencies & inhibition¶
Dependencies & inhibition model manual parent-child relationships across host boundaries ("switch sw-core → 50 servers behind it"). The reachability hint acts within a single host: it pauses that host's own service alerts when the host is unreachable. It is also the basis for whether a parent host in a dependency counts as down.
Both work in parallel:
- Switch fails → inhibition suppresses alerts of the servers behind it.
- Single server fails → reachability hint suppresses alerts of the services ON that server.
Where is it configured?¶
At profile level (default for all hosts with the profile)¶
Profiles → expand profile → edit check → section "Behaviour", switch "Determines whether the device is reachable".
If you change the switch and hosts with this profile have their own setting for this check, Vesana asks when saving:
- Yes, replace own settings too — the new profile value applies everywhere immediately.
- Keep own settings — hosts with their own choice stay untouched.
In the profile's check list you recognise the marked check by the radar badge "Reachability".
Per host¶
Open host → "Manage host" → tab "Alerting" → "Reachability check"
| Option | Effect |
|---|---|
| Use profile default | Takes what the profile says (default, no own setting). |
| Disabled | No check of this host counts as reachability hint. On host outage every service alerts individually. |
| Set a specific check as hint | Expands a list of the host's active checks. Pick the check you want. |
The host's own choice wins over the profile. For a single check it also works in the check editor on the host: section "Alerting", switch "Use as reachability hint".
If you disable or delete a host's last anchor, Vesana warns ("Reachability anchor will be lost") and offers to transfer the anchor to another active check.
Visible in the check table¶
On the host detail page a radar icon follows the check that is currently the reachability hint; the tooltip explains it.
When does a host count as unreachable?¶
Vesana evaluates reachability every 30 seconds:
- Reachability hint: at least one hint check of the host is alerting with a measured CRITICAL or WARNING. A hint on No Data does not count — it only means the checker is missing, not that the host is gone.
- Agent hosts: additionally a host counts as unreachable when its agent has not reported for 3 minutes — even without its own ping check. An agent that has never reported delivers no verdict and does not overrule a green ping.
If both sources deliver data, "unreachable" wins.
When the host comes back, the checks continue normally; whatever is still broken afterwards is caught up — the start-up phase collects boot side effects, see If-then reference.
Several reachability hint checks per host¶
Via the profile a host can have several hint checks (e.g. ping AND HTTP); then: if one alerts, the host is unreachable. If you choose "Set a specific check as hint" on the host, Vesana reduces it to exactly that one check when saving.
Recommended defaults¶
- Servers with a ping check: ping as reachability hint (automatic).
- Switches/routers/firewalls with SNMP: ping as reachability hint. SNMP checks alone are not a good hint — snmpd can hang while the device is still there.
- Devices without ping (e.g. ICMP blocked): set a TCP port check or a lightweight HTTP check as hint.
- Agent hosts: no configuration needed, the agent heartbeat is enough.
When to disable?¶
As a rule you want to keep the reachability hint switched on. Disable it at most for hosts where you want a separate message for every service even when the host is completely gone.