Skip to content

Alerting Ablaeufe

Auswertungsfluss

sequenceDiagram
    participant Worker as Alert-Task
    participant CFG as cConfigExt jobs.alerts
    participant DATA as Message-, Flow- und Keystore-Tabellen
    participant TYPE as Typspezifische Auswerter
    participant ALERT as cpiAlert
    Worker->>CFG: Aktivierte Alert-Definitionen lesen
    Worker->>TYPE: Nach Alert-Typ dispatchen
    TYPE->>DATA: Aktuellen Tenant-Zustand auswerten
    TYPE->>ALERT: Alerts anlegen, fortschreiben, unterdruecken oder schliessen
    ALERT-->>Worker: Persistierter Alert-Zustand fuer die UI verfuegbar

Message-, iFlow-, Keystore- und No-Message-Pruefungen teilen sich die Orchestrierung, aber nicht dieselben Evaluatoren. Diese Aufteilung ist wichtig bei unerwartetem Alert-Verhalten.

Review-Fluss

sequenceDiagram
    participant UI as AlertPopup
    participant API as CPI Alert APIs
    participant ALERT as cpiAlert Daten
    UI->>API: Overview, Liste, Statistik und Detail laden
    API->>ALERT: Persistierten Alert-Zustand abfragen
    API-->>UI: Zeilen und Details liefern

Operatives Alert-Review startet oft in Tenant-Overview-Karten und verzweigt danach je nach Alert-Typ in Message-, Artefakt- oder Keystore-Analyse.

Acknowledge-Fluss

sequenceDiagram
    participant U as Benutzer
    participant UI as AlertAcknowledgeModal
    participant API as Acknowledge-Endpunkt
    participant ALERT as cpiAlert
    U->>UI: Alert bestaetigen
    UI->>API: POST acknowledge
    API->>ALERT: Status aktualisieren
    API-->>UI: Aktualisierten Zustand liefern

Ein Acknowledge aendert den Alert-Zustand, entfernt aber nicht automatisch die technische Ursache. Wenn die ausloesende Bedingung bestehen bleibt, koennen spaetere Auswertungszyklen den Alert offen halten oder Folgezustaende erzeugen.