Monitoring und Event Management

OpsWeave integriert externe Monitoring-Systeme und verarbeitet deren Ereignisse automatisch. Unterstuetzte Systeme umfassen Check_MK (v1 Livestatus + v2 REST API) sowie jedes System ueber Webhook-Eingang.

Monitoring-Quellen

Monitoring-Quellen werden zentral verwaltet. Jede Quelle definiert den Typ, Verbindungsdetails und optionale Webhook-Secrets.

Unterstuetzte Typen:

Typ	Beschreibung
checkmk_v1	Check_MK 1.x ueber Livestatus-Protokoll
checkmk_v2	Check_MK 2.x ueber REST API
zabbix	Zabbix API
prometheus	Prometheus Alertmanager
generic_webhook	Beliebiges System ueber Webhook

Quellen verwalten

• Hinzufuegen — Name, Typ, Verbindungskonfiguration (JSON), Webhook-Secret
• Bearbeiten — Konfiguration anpassen, aktivieren/deaktivieren
• Loeschen — Quelle entfernen (bestehende Ereignisse bleiben erhalten)
• Verbindungstest — Erreichbarkeit und Authentifizierung pruefen

Check_MK-Integration

Version 1.x (Livestatus)

Die Integration nutzt das Livestatus-Protokoll (TCP/Unix-Socket). OpsWeave fragt regelmaessig Host- und Service-Status ab und erstellt bei Zustandsaenderungen Ereignisse.

Konfiguration:

{
  "host": "checkmk.example.com",
  "port": 6557,
  "protocol": "tcp",
  "poll_interval_seconds": 60
}

Version 2.x (REST API)

Die Integration nutzt die offizielle Check_MK REST API mit einem Automationsbenutzer und -secret.

Konfiguration:

{
  "base_url": "https://checkmk.example.com/mysite/check_mk/api/1.0",
  "username": "automation",
  "secret": "...",
  "poll_interval_seconds": 60
}

Beide Versionen werden ueber einen abstrahierten Adapter unterstuetzt — die interne Verarbeitung ist identisch.

Event-Dashboard

Das Event-Dashboard zeigt alle eingehenden Monitoring-Ereignisse mit Statuskarten:

Karte	Farbe	Bedeutung
OK	Gruen	Service laeuft normal
Warning	Gelb	Schwellwert ueberschritten
Critical	Rot	Service ausgefallen oder kritisch
Unknown	Grau	Status unbekannt

Filtern und Paginierung

Ereignisse koennen gefiltert werden nach:

• Status (OK, Warning, Critical, Unknown)
• Hostname
• Servicename
• Quelle (Monitoring-Quelle)
• Verarbeitungsstatus (verarbeitet / unverarbeitet)
• Zeitraum

Die Ergebnisliste ist paginiert (Standard: 25 pro Seite).

Webhook-Eingang

Externe Systeme koennen Ereignisse per HTTP POST an OpsWeave senden:

POST /api/v1/monitoring/events
Content-Type: application/json
X-Webhook-Secret: <secret>

Der Mandant wird automatisch aus der Webhook-Quellkonfiguration ermittelt. Das Webhook-Secret wird gegen die gespeicherte Monitoring-Quelle validiert.

Asset-Matching

Eingehende Ereignisse werden automatisch gegen Assets in der CMDB abgeglichen. Der Matching-Algorithmus vergleicht den hostname des Ereignisses mit:

1. Asset-Name (exakter Treffer)
2. Asset-Anzeigename (exakter Treffer)
3. IP-Adresse (falls im Ereignis enthalten)

Bei einem Treffer wird das Ereignis mit dem Asset verknuepft (matched_asset_id).

Auto-Incident-Erstellung

Fuer Ereignisse mit Status Critical oder Warning kann OpsWeave automatisch Incidents erstellen:

1. Ereignis kommt mit Status critical an
2. Asset-Matching findet das betroffene Asset
3. Deduplizierung: Existiert bereits ein offenes Ticket fuer dieses Asset + Service?
   • Ja — Ereignis wird dem bestehenden Ticket zugeordnet
   • Nein — Ein neues Incident-Ticket wird erstellt
4. Das Ticket erhaelt source: 'monitoring' und referenziert das Ereignis

Bei Rueckkehr zu Status OK kann das zugehoerige Ticket automatisch als geloest markiert werden (Auto-Acknowledgment).

REST API

GET    /api/v1/monitoring/sources          # Alle Quellen auflisten
POST   /api/v1/monitoring/sources          # Quelle hinzufuegen
PUT    /api/v1/monitoring/sources/:id      # Quelle bearbeiten
POST   /api/v1/monitoring/events           # Ereignis empfangen (Webhook)
GET    /api/v1/monitoring/events            # Ereignisse auflisten (paginiert, filterbar)