Dependencies & Inhibition

Wenn der Switch im Server-Raum ausfällt, sind 50 Server hinter ihm nicht erreichbar. Ohne Inhibition würden 50 Mails kommen — aber das wirkliche Problem ist genau einer.

Eine Abhängigkeit sagt „A hängt ab von B". Fällt B aus, unterdrückt Vesana die Alarme von A — du bekommst den Ursachen-Alarm statt einer Folgefehler-Flut.

Dies ist die strukturelle Variante für Beziehungen zwischen verschiedenen Objekten (Switch → dahinterliegende Server). Für den Fall „ein einzelner Host ist komplett weg, alle seine eigenen Checks sollen nicht jeder einzeln alarmieren" gibt es den Reachability-Hint — beide Mechanismen ergänzen sich.

Modell

graph TD
    SW[sw-core: nicht erreichbar] -->|hängt drin| WEB1[web01: unterdrückt]
    SW -->|hängt drin| WEB2[web02: unterdrückt]
    SW -->|hängt drin| DB[db01: unterdrückt]
    DB -->|hängt drin| APP[app-server: unterdrückt, indirekt]

Was „ausgefallen" heißt

Ob der Elternteil (der Versorger) als ausgefallen gilt, hängt von seiner Art ab:

Elternteil	gilt als ausgefallen, wenn …
Host	er nicht erreichbar ist: sein Erreichbarkeits-Check (meist Ping) alarmiert mit gemessenem CRITICAL oder WARNING, bzw. bei Agent-Hosts der Agent schweigt. Einzelne rote Checks zählen nicht — sonst würde ein abgelaufenes Zertifikat die halbe Infrastruktur stummschalten. Ein Erreichbarkeits-Check auf No Data zählt ebenfalls nicht.
Check	genau dieser Check alarmiert. Wer an einem einzelnen Dienst hängen will, zieht die Abhängigkeit auf den Check.
Aggregat (Redundanz-Gruppe)	das Aggregat CRITICAL wird (Funktion verloren). Ein WARNING des Aggregats — einzelnes Mitglied weg — unterdrückt nichts.

Ein Collector ist selbst kein Elternteil, der etwas unterdrückt; sein Ausfall kommt als eigene Meldung „Collector offline" (siehe Wenn-Dann-Referenz). Läuft der Collector aber auf einer überwachten VM, kannst du ihn von dieser VM abhängig machen: fällt die VM aus, unterdrückt sie dann auch die No-Data-Flut aller Checks, die über diesen Collector laufen.

Anlegen

Am Host: Host verwalten → Reiter Alarmierung → Abhängigkeiten

• Dieser Host hängt ab von — „Übergeordneten Host auswählen…" und Hinzufügen.
• Abhängige Hosts (Kinder) — wer von diesem Host abhängt.
• Einträge mit indirekt sind über die Kette verbunden; die Unterdrückung wirkt auch für sie.
• Collector auf diesem Host — wird der Host von einem Collector geprüft, der auf dieser Maschine läuft, legst du hier mit einem Klick die Abhängigkeit Collector → Host an.
• Auf Karte zeigen springt zur Karte.

Auf der Karte: eine Linie vom Versorger (z. B. Switch, VM) zum abhängigen Gerät ziehen. Ein Bestätigungsdialog nennt den Satz („„web01" hängt ab von „sw-core"") und die Wirkung; mit Umkehren drehst du die Richtung. Zwischen Hosts, Checks, Collectors, Aggregaten und Zonen sind Abhängigkeiten möglich; eine Linie zu einem Collector richtet Vesana automatisch so aus, dass der Collector von seiner VM abhängt. Wer nur eine Verbindung zeichnen will, wählt Nur optische Linie — gestrichelt, ohne Wirkung.

Der Knopf Abhängigkeiten auf der Karte zeigt alle Abhängigkeiten als Liste (wahlweise nur die der aktuellen Karte), mit Richtung umkehren, Auf der Karte zeigen, Löschen und dem Hinweis unterdrückt gerade, wenn ein Elternteil im Moment ausgefallen ist.

Wirkung

flowchart LR
    R[Alarm eines Checks] --> Q{Hat sein Host einen Elternteil?}
    Q -->|nein| FORWARD[normale Auswertung]
    Q -->|ja| P{Elternteil irgendwo in der Kette ausgefallen?}
    P -->|nein| FORWARD
    P -->|ja| INHIB[Meldung unterdrücken, Grund im Diagnose-Log]

Die Unterdrückung gilt nur für Benachrichtigungen — der Status selbst wird nicht verändert. In der Oberfläche siehst du weiter, dass der Check kritisch ist; der Host-Kopf zeigt die Abhängigkeit als Chip („hängt an: sw-core"). Unterdrückte Meldungen stehen im Diagnose-Log unter „Unterdrückt".

Die Unterdrückung wirkt transitiv: hängt app-server an db01 und db01 an sw-core, ist app-server still, solange sw-core ausgefallen ist.

Wenn der Elternteil zurückkommt

1. Die Unterdrückung fällt weg.
2. Ist ein abhängiger Check weiterhin gestört (gemessen CRITICAL, WARNING oder UNKNOWN), holt Vesana seinen Alarm nach — die Wartezeit der Regel zählt ab der Rückkehr, Boot-Folgen sammelt die Anlaufphase.
3. Hat sich der abhängige Check mit dem Elternteil erholt, bleibt alles ruhig — auch ohne Entwarnung, denn sein Alarm war nie verschickt.

Erkennung von Eltern-Hosts

Manuell — Vesana legt Abhängigkeiten nicht selbst an. Für Zonen auf der Karte gibt es einen Sammelweg: „Übrige Mitglieder von den Status-Hosts abhängig machen".

Sonderfälle

Gelöschter Elternteil

Ein gelöschter Eltern-Host (auch im Papierkorb) unterdrückt nichts mehr — Folge-Alarme feuern wieder.

Elternteil in Downtime

Eine Downtime verhindert, dass der Erreichbarkeits-Check des Elternteils während des Fensters alarmiert; fällt der Elternteil erst in der Downtime aus, gilt er deshalb nicht als ausgefallen, und seine Kinder alarmieren normal. Ausnahme: Agent-Hosts, deren Agent schweigt, gelten unabhängig von der Downtime als nicht erreichbar. Für geplante Wartung am Switch gehören die Kinder deshalb mit in die Downtime — z. B. über mehrere Geräte oder den ganzen Tenant, siehe Downtimes.

Zyklen und Duplikate

Beim Anlegen erkennt Vesana Zyklen (A → B → A) und lehnt sie ab; dieselbe Abhängigkeit lässt sich nicht doppelt anlegen. Beide Enden müssen zum selben Tenant gehören — einzige Ausnahme ist der Aktive Collector.

Rechte und Audit

Abhängigkeiten sehen: hosts.view. Anlegen und Löschen: hosts.edit. Beides steht im Audit-Log (dependency_create, dependency_delete).

Anschluss

• Reachability-Hint — Pendant für Alarme innerhalb eines einzelnen Hosts
• Wenn-Dann-Referenz — wie Unterdrückung, Nachholen und Entwarnung zusammenspielen
• Downtimes — alternativer Ansatz für „während Wartung still"