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.

Dependencies modellieren „A hängt von B ab", Inhibition unterdrückt Alerts an A, solange B selbst kritisch ist.

Modell¶

graph TD
    SW[sw-core: CRITICAL] -->|hängt drin| WEB1[web01: CRIT inhibited]
    SW -->|hängt drin| WEB2[web02: CRIT inhibited]
    SW -->|hängt drin| DB[db01: CRIT inhibited]
    SW -.geht weiter zu.-> ROUTER[router: OK]
    DB -->|hängt drin| APP[app-server: CRIT inhibited]

Wenn sw-core CRIT ist, werden alle Kinder als „inhibited" markiert. Ihre Status erscheinen mit grauem Badge im UI, ihre Alert-Rules feuern nicht.

Dependency-Modell¶

In dependencies (Migration 036):

Feld	Bedeutung
`parent_host_id`	Eltern-Host
`child_host_id`	abhängiger Host
`parent_service_id`	optional: Beziehung auf Service-Ebene
`child_service_id`	optional
`inhibit_when_parent`	Status, ab dem inhibitiert wird (Default `CRITICAL`)

Eine Beziehung kann „nur wenn Eltern-CRIT inhibitieren" oder „auch bei WARN inhibitieren" sein.

Anlegen¶

/dependencies zeigt eine Tree-View. Pro Eltern auf + Abhängigkeit hinzufügen:

Kind-Host wählen
Optional: spezifische Service-Beziehung statt Host-Ebene
inhibit_when_parent setzen

Alternativ als Bulk-Operation: mehrere Kinder gleichzeitig anhängen.

Inhibition-Logik im Worker¶

flowchart LR
    R[Check-Result CRIT] --> Q{Eltern existieren?}
    Q -->|nein| FORWARD[normale Auswertung]
    Q -->|ja| P{Eltern-Status >= inhibit-Schwelle?}
    P -->|nein| FORWARD
    P -->|ja| INHIB[Alert unterdrücken<br/>Status sichtbar als inhibited]

Die Inhibition gilt nur für Notifications — der Status selbst wird nicht maskiert. Im UI siehst du, dass der Service kritisch ist, aber wegen sw-core (Eltern) inhibited.

Inhibition + Recovery¶

Wenn der Eltern wieder OK wird:

Inhibition fällt
Wenn das Kind weiterhin CRIT ist, wird jetzt eine Notification erzeugt — du siehst tatsächliche Folge-Probleme erst jetzt
Wenn das Kind durch Wieder-Zugriff auf Eltern auch OK wird, ist alles ruhig (kein Alert-Spam)

Tree-View¶

sw-core (CRITICAL)
├── web01 (CRIT, inhibited)
├── web02 (CRIT, inhibited)
└── db01 (CRIT, inhibited)
    └── app-server (CRIT, inhibited transitiv)
router-edge (OK)
└── (keine Abhängigkeiten)

Transitive Inhibition: wenn db01 inhibited ist (weil sw-core CRIT), und app-server von db01 abhängt, wird app-server ebenfalls inhibited.

Erkennung von Eltern-Hosts¶

Manuell — keine automatische Erkennung. Empfehlung:

Bei Discovery-Walks notiert sich Vesana das Default-Gateway pro Host (wenn vorhanden) — das ist der Standard-Eltern-Vorschlag
Bei Storage-Volumes: Storage-Host ist der Eltern
Bei VMs: VM-Host ist der Eltern

Auto-Population dieser Beziehungen ist ein offener Punkt — manuelles Pflegen für die wichtigsten Eltern reicht in der Praxis.

Edge-Cases¶

Soft-Delete des Eltern¶

Seit v0.17.x

Inhibition ignoriert orphan / soft-deleted Eltern-Hosts — sonst hätten gelöschte Switches Folge-Alerts dauerhaft unterdrückt.

Wenn der Eltern-Host gelöscht wird, fällt die Inhibition automatisch — Folge-Alerts feuern wieder.

Eltern in Downtime¶

Wenn der Eltern in einer Downtime ist, wird er nicht als CRIT gewertet — alle Kinder sehen ihn als „nicht inhibitierend". Sinnvoll: während geplanter Wartung am Switch fragen wir uns nicht „wie viele Hosts hängen drin", sondern überwachen sie normal.

Zirkuläre Abhängigkeit¶

Beim Anlegen erkennt das Backend Zyklen (A → B → A) und lehnt mit 400 ab.

Anschluss¶

Alert Rules — wie Inhibition mit Rules zusammenspielt
Downtimes — alternativer Ansatz für „während Wartung still"