Skip to content

Dependencies & inhibition

When the switch in the server room fails, 50 servers behind it become unreachable. Without inhibition you would get 50 mails — but the real problem is exactly one.

A dependency says "A depends on B". If B fails, Vesana suppresses A's alerts — you get the root-cause alert instead of a flood of follow-up errors.

This is the structural variant for relationships between different objects (switch → servers behind it). For the case "a single host is completely gone, and none of its own checks should alert individually" there is the reachability hint — the two mechanisms complement each other.

Model

graph TD
    SW[sw-core: unreachable] -->|behind it| WEB1[web01: suppressed]
    SW -->|behind it| WEB2[web02: suppressed]
    SW -->|behind it| DB[db01: suppressed]
    DB -->|behind it| APP[app-server: suppressed, indirect]

What "down" means

Whether the parent (the supplier) counts as down depends on its kind:

Parent counts as down when …
Host it is unreachable: its reachability check (usually ping) is alerting with a measured CRITICAL or WARNING, or — for agent hosts — the agent is silent. Individual red checks do not count — otherwise an expired certificate would mute half the infrastructure. A reachability check on No Data does not count either.
Check exactly this check is alerting. If you want to depend on a single service, point the dependency at the check.
Aggregate (redundancy group) the aggregate turns CRITICAL (function lost). A WARNING of the aggregate — one member gone — suppresses nothing.

A collector is not itself a parent that suppresses anything; its failure arrives as a separate "Collector offline" message (see If-then reference). If the collector runs on a monitored VM, however, you can make it depend on that VM: when the VM fails, it then also suppresses the No Data flood of all checks running through this collector.

Creating dependencies

On the host: Manage host → Alerting tab → Dependencies

  • This host depends on — "Select parent host…" and Add.
  • Dependent hosts (children) — who depends on this host.
  • Entries marked indirect are connected via the chain; suppression applies to them too.
  • Collector on this host — if the host is checked by a collector running on this machine, you create the collector → host dependency here with one click.
  • Show on map jumps to the map.

On the map: draw a line from the supplier (e.g. switch, VM) to the dependent device. A confirmation dialog states the sentence ("“web01” depends on “sw-core”") and the effect; Reverse flips the direction. Dependencies are possible between hosts, checks, collectors, aggregates and zones; a line to a collector is automatically oriented so that the collector depends on its VM. If you only want to draw a connection, choose Visual line only — dashed, without any effect.

The Dependencies button on the map shows all dependencies as a list (optionally only those of the current map), with Reverse direction, Show on map, delete and the marker suppressing now when a parent is currently down.

Effect

flowchart LR
    R[Alert of a check] --> Q{Does its host have a parent?}
    Q -->|no| FORWARD[normal evaluation]
    Q -->|yes| P{Parent down anywhere in the chain?}
    P -->|no| FORWARD
    P -->|yes| INHIB[Suppress message, reason in diagnostic log]

Suppression applies only to notifications — the status itself is not changed. In the UI you still see that the check is critical; the host header shows the dependency as a chip ("depends on: sw-core"). Suppressed messages are listed in the diagnostic log under "Suppressed".

Suppression works transitively: if app-server depends on db01 and db01 on sw-core, app-server stays silent while sw-core is down.

When the parent comes back

  1. Suppression is lifted.
  2. If a dependent check is still broken (measured CRITICAL, WARNING or UNKNOWN), Vesana catches up on its alert — the rule's delay counts from the return, boot side effects are collected by the start-up phase.
  3. If the dependent check recovered together with the parent, everything stays quiet — without a recovery too, because its alert was never sent.

Detecting parent hosts

Manual — Vesana does not create dependencies on its own. For zones on the map there is a bulk path: "Make remaining members depend on the status hosts".

Edge cases

Deleted parent

A deleted parent host (including one in the recycle bin) no longer suppresses anything — follow-up alerts fire again.

Parent in downtime

A downtime prevents the parent's reachability check from alerting during the window; if the parent only fails during the downtime, it therefore does not count as down, and its children alert normally. Exception: agent hosts whose agent is silent count as unreachable regardless of the downtime. For planned maintenance on the switch, put the children into the downtime as well — e.g. via several devices or the whole tenant, see Downtimes.

Cycles and duplicates

When creating, Vesana detects cycles (A → B → A) and rejects them; the same dependency cannot be created twice. Both ends must belong to the same tenant — the only exception is the Active Collector.

Permissions and audit

Viewing dependencies: hosts.view. Creating and deleting: hosts.edit. Both are recorded in the audit log (dependency_create, dependency_delete).

Next