Was ist betroffen,
wenn etwas kippt?

SNAG-View 4-Architektur und Geschäftsprozess-Monitoring

Neu in SNAG-View 4: das Addon Impact Analyzer

So denkt SNAG-View 4

• Crashkurs Monitoring mit SNAG-View 4 — seit 4.9 (Abschied von der InfluxDB) hat sich unter der Haube einiges geändert.
• Ein Agent (aktuell Telegraf) fragt die Systeme ab und sammelt Kennzahlen — die Metriken.
• Die Metriken werden in einer Timeseries-Datenbank gespeichert (aktuell Postgres TimescaleDB).
• Ein regelmäßiger Hintergrund-Job liest alle seit dem letzten Lauf geschriebenen Metriken und berechnet daraus den Status.
• Das Ergebnis: ein Monitoring-System.

Vier Begriffe. Mehr nicht.

• Device — ein physischer oder virtueller Host: Server, VM, Switch, Drucker, Telefon. Alles, was sich abfragen lässt.
• Sensor — ein Dienst oder eine Hardware-Komponente auf dem Device (Festplatte, RAM, MariaDB, Web-Server). Definiert, welche Metriken gesammelt werden.
• Rating — bewertet die Daten eines Sensors. Sensor-Status = Worst-State seiner Ratings.
• Interpretation — legt fest, welche Daten wie interpretiert werden: ab welchem Füllstand WARNING, ab wann CRITICAL. Rating-Status = Worst-State seiner Interpretations.

Der schlimmste gewinnt.

• Alle Status gehen oben rein — der schlechteste kommt unten raus.
• Das ist der Worst-State.
• Er gilt auf jeder Ebene: Interpretation → Rating → Sensor → Device.

Die Rangfolge ist fest. Noch.

• Der Worst-State wird über die Kardinalität berechnet — eine Liste, die die Schwere der Status gegeneinander vergleicht.
• Von harmlos nach schwer: OK → WARNING → CRITICAL → NODATA → UNKNOWN.
• Aktuell ist diese Liste fest verdrahtet. Das könnte sich bald ändern — mehr dazu in „Planning the future“.

Vom Sensor zum Service.

• Zurück zur Eingangsfrage: Was bewirkt das Kippen eines Sensors?
• Das ist die Kernfrage des Geschäftsprozess-Monitorings — deshalb heißt das Addon Impact Analyzer.
• Services und Dienste werden in Beziehung gesetzt: Aus der flachen Liste wird ein Abhängigkeitsbaum.
• Die Logik, um Objekte zu Gruppen zu verknüpfen, liefern die Operatoren.

Objekt-Status ≠ Node-Status

• Der Status einer Node ist nicht der Status des verknüpften Objekts.
• Ein Objekt meldet OK, WARNING, CRITICAL, NODATA oder UNKNOWN — eine Node kennt nur OK oder CRITICAL.
• Pro Node wird definiert, welche Objekt-Status „für den Prozess OK“ sind. Alles andere zählt als CRITICAL.
• Kein Graubereich, kein Pending: Der Baustein trägt den Prozess — oder nicht.

Wartung zählt als OK. Wenn du willst.

• Pro Geschäftsprozess einstellbar: Zählen Downtimes als OK? Zählen quittierte Probleme als OK?
• So verfälschen Wartungsfenster und bereits bekannte Probleme den Prozess-Status nicht.

Simulationsmodus: Was wäre, wenn?

• Das Feature, dem das Addon seinen Namen verdankt.
• Per Switch wechselt ein gespeicherter Prozess in den Simulationsmodus.
• Für jede Node lässt sich ein temporärer Status setzen — der Prozess-Status reagiert sofort.
• Prüfen, ob der Prozess richtig gebaut ist und sich so verhält, wie er soll.
• Durchspielen: Welche Dienste dürfen ausfallen — und wie viele, bis der Prozess wirklich kippt?

Was ist betroffen, wenn etwas kippt?

• Der Impact Analyzer bildet Geschäftsprozesse als Abhängigkeitsbaum ab — mit AND, OR, XOR und MIN.
• Ein Blick zeigt, ob ein Kern-Prozess gekippt ist oder nur ein einzelner Knoten.
• Beim Mittagessen wissen Sie: losrennen — oder reicht die Zeit noch für den Nachtisch?