Monitoring-Integration

OpsWeave ist kein Monitoring-Tool. OpsWeave ist der Event-Empfänger, der Alerts aus deinem bestehenden Monitoring-System (Check_MK, Prometheus, Grafana, Jira Service Management, eigenes System) in strukturierte Incidents mit Asset- und SLA-Kontext verwandelt.

Der Flow: Alert kommt als Webhook → Hostname wird gegen die CMDB gematcht → Asset-Kritikalität bestimmt Priorität → SLA-Tier steuert Eskalation → Incident wird (optional) automatisch erstellt.

Unterstützte Quellen

Quelle	Typ	Auth
Check_MK 2.x	REST-API (gepullt)	Automation-User + Secret
Alertmanager	Webhook	`X-Webhook-Secret` Header
Grafana	Contact Point (Webhook)	`X-Webhook-Secret` Header
Jira Service Management	Webhook (Automation Rule)	`X-Webhook-Secret` Header
Beliebige Quelle	Generischer Webhook	`X-Webhook-Secret` Header

Konfiguration: Settings → Monitoring. Pro Quelle wird automatisch ein Webhook-Secret generiert.

Integration-Playbooks

Check_MK 2.x

Check_MK wird per REST-API gepullt. OpsWeave fragt im konfigurierten Intervall nach Non-OK Services und Hosts ab.

1. Automation-User in Check_MK anlegen: Setup → Users → Automation. Secret merken (wird nur einmal angezeigt).

2. In OpsWeave konfigurieren:

Settings → Monitoring → Quelle hinzufügen
  Name: Check_MK Production
  Typ: checkmk_v2
  Config:
    {
      "base_url": "https://checkmk.example.com/mysite/check_mk/api/1.0",
      "username": "automation",
      "secret": "<automation-secret>",
      "poll_interval_seconds": 60
    }
  Test → "OK, Version 2.4.x, 127 Hosts"

Events fließen automatisch alle 60 s.

Prometheus / Alertmanager

Alertmanager schickt Alerts per Webhook. Da Alertmanagers JSON-Format vom OpsWeave-Format abweicht, brauchst du einen kleinen Bridge-Receiver (z.B. ein Express- oder Flask-Endpoint), der die Alerts transformiert und an OpsWeave weiterreicht.

1. OpsWeave Webhook-Quelle anlegen: Typ generic_webhook, Secret kopieren.

2. alertmanager.yml ergänzen:

yaml

receivers:
  - name: opsweave-bridge
    webhook_configs:
      - url: 'https://your-bridge.example.com/alertmanager-bridge'
        send_resolved: true

route:
  receiver: opsweave-bridge
  group_by: [alertname, instance]
  group_wait: 30s
  repeat_interval: 4h

3. Bridge-Endpoint (minimal, Node.js):

app.post('/alertmanager-bridge', async (req, res) => {
  for (const alert of req.body.alerts || []) {
    const hostname = (alert.labels.instance || '').split(':')[0];
    const state = alert.status === 'firing' ? 'critical' : 'ok';
    await fetch('https://opsweave.example.com/api/v1/monitoring/events/webhook/<source-id>', {
      method: 'POST',
      headers: { 'Content-Type': 'application/json', 'X-Webhook-Secret': '<secret>' },
      body: JSON.stringify({
        hostname,
        service_name: alert.labels.alertname,
        state,
        output: alert.annotations.summary || '',
        external_id: alert.fingerprint
      })
    });
  }
  res.status(204).end();
});

Native Prometheus/Alertmanager-Adapter ohne Bridge sind auf der Roadmap (Q3).

Grafana

Alerting → Notification policies → Contact point → Webhook:

Type:    Webhook
URL:     https://opsweave.example.com/api/v1/monitoring/events/webhook/<source-id>
Headers: X-Webhook-Secret: <secret>

Grafana-Payload-Mapping läuft analog zu Alertmanager über einen Bridge-Endpoint (oder warte auf den nativen Adapter).

Jira Service Management

Eingehende JSM-Tickets können per Automation-Rule an OpsWeave gespiegelt werden:

Project Settings → Automation → New rule:

Trigger: Issue created oder Transition to In Progress
Action: Send web request

URL:     https://opsweave.example.com/api/v1/monitoring/events/webhook/<source-id>
Method:  POST
Headers: X-Webhook-Secret: <secret>
Body:
  {
    "hostname":     "{{issue.summary | split(' ')[0]}}",
    "service_name": "jira-{{issue.key}}",
    "state":        "critical",
    "output":       "{{issue.description}}",
    "external_id":  "{{issue.key}}"
  }

Resultat: JSM-Tickets landen als Events in OpsWeave, werden mit CMDB-Assets verknüpft und können zu Incidents werden.

Was passiert mit einem Event?

1. Validierung

OpsWeave erwartet:

Feld	Typ	Pflicht	Beispiel
`hostname`	String	ja	`prod-db-01`
`service_name`	String	nein	`mysql_replication`
`state`	Enum	ja	`ok`, `warning`, `critical`, `unknown`
`output`	String (max 65 535)	nein	`Replication lag 3600s`
`external_id`	String	nein	`prom_alert_12345`

Validiert via Zod. X-Webhook-Secret wird timing-safe geprüft.

2. Deduplizierung (5-Minuten-Fenster)

Identische Events (gleiche hostname + service_name + state) innerhalb von 5 Minuten werden nicht erneut gespeichert — die ID des Originals wird zurückgegeben ({ deduplicated: true }).

13:00:01  prod-db-01 / mysql_critical   → gespeichert  (id: abc)
13:00:15  prod-db-01 / mysql_critical   → dedupliziert (id: abc)
13:01:00  prod-db-01 / mysql_critical   → dedupliziert (id: abc)
13:05:02  prod-db-01 / mysql_critical   → gespeichert  (id: def)  ← neues Fenster

State-Wechsel werden immer gespeichert:

13:00  prod-db-01 / mysql_critical   → gespeichert
13:01  prod-db-01 / mysql_warning    → gespeichert (anderer State)
13:02  prod-db-01 / mysql_ok         → gespeichert (Auflösung)

3. Asset-Matching

OpsWeave sucht das betroffene Asset nacheinander über:

exakter Name: assets.name = hostname
Display-Name: assets.display_name = hostname
IP (falls im Event): assets.ip_address = ip

Kein Treffer → Event bleibt ungebunden in der Event-Liste sichtbar (matched_asset_id = null).

4. CMDB-Enrichment

Sobald gematcht, hängt OpsWeave automatisch dran:

Asset-Details (Name, Typ, Standort, Owner)
SLA-Tier (direkt oder vererbt)
Service-Referenz, falls Asset Teil eines Services ist
Aktive Changes auf dem Asset (Kontext für den Incident-Bearbeiter)
Compliance-Impact (welche Controls betroffen sind)

5. Incident-Auto-Erstellung (optional)

Tenant-Setting: auto_create_incidents_from_events.

Bei critical oder warning:

Existiert bereits ein offenes Incident für asset_id + service_name? → Event dem bestehenden Ticket zuhängen.
Sonst neues Incident:
- title: „Alert: {hostname} / {service_name}"
- priority: abgeleitet aus Asset-Kritikalität
- sla_tier: vom Asset
- source: monitoring

Bei ok und aktivem auto_acknowledge_resolved_incidents: zugehöriges Ticket → Status resolved.

Webhook-Payload (Referenz)

Single Event

json

{
  "hostname": "prod-web-03",
  "service_name": "nginx",
  "state": "critical",
  "output": "HTTP 503 detected",
  "external_id": "prom_alert_12345"
}

Batch

json

[
  { "hostname": "prod-web-03", "service_name": "nginx", "state": "critical" },
  { "hostname": "prod-db-01", "service_name": "mysql", "state": "warning" }
]

curl

bash

curl -X POST https://opsweave.example.com/api/v1/monitoring/events/webhook/<source-id> \
  -H "Content-Type: application/json" \
  -H "X-Webhook-Secret: <secret>" \
  -d '{
    "hostname": "prod-api-01",
    "service_name": "http_endpoint",
    "state": "critical",
    "output": "Response time > 10s",
    "external_id": "grafana_alert_5678"
  }'

Antwort:

json

{
  "data": { "deduplicated": false, "event_id": "550e8400-e29b-41d4-a716-446655440000" },
  "meta": { "timestamp": "2026-04-15T14:32:00Z" }
}

REST-API

GET   /api/v1/monitoring/sources
POST  /api/v1/monitoring/sources
PUT   /api/v1/monitoring/sources/:id
POST  /api/v1/monitoring/events/webhook/:source-id   (Webhook-Endpoint)
GET   /api/v1/monitoring/events?state=critical&hostname=prod
GET   /api/v1/monitoring/events/:id

Was OpsWeave (noch) nicht macht

Native Prometheus / Grafana / Datadog / Zabbix Adapter: aktuell nur Webhook + Bridge. Native Adapter mit Label-Transformation kommen Q3.
Intelligente Flapping-Detection: kein automatisches Suppress flippender Services. Nutze dafür Alertmanagers group_wait und repeat_interval.
Pattern-basiertes Event-Grouping: kein In-OpsWeave Grouping über Label-Patterns. Auch hier ist Alertmanager das richtige Werkzeug.
Custom Alert-Korrelation: nicht out-of-the-box. Optionales AI-Modul (POST /api/v1/monitoring/events/correlate) experimentell.

Empfehlungen

Alertmanager / Grafana machen das Grouping, Silencing, Routing — OpsWeave ist Receiver, nicht Policy-Engine.
Custom Bridge-Endpoint bei dir halten, solange kein nativer Adapter da ist. Der Bridge ist 30 Zeilen Code.
Check_MK nutzt OpsWeaves nativen Pull-Adapter — kein Bridge nötig.
Webhook-Secret rotieren wenn Bridge-Code in einem Public-Repo lebt.

Debugging

Symptom	Check
Event landet nicht	`X-Webhook-Secret` korrekt? Source aktiv?
Event ohne Asset (`matched_asset_id = null`)	Hostname matcht den CMDB-Asset-Namen exakt?
Falscher State	Muss `ok
Doppelte Events fehlen	5-Minuten-Dedup aktiv — gleicher Service + State innerhalb des Fensters?

Backend-Logs:

[monitoring] Deduplicated event hostname=prod-db-01 state=critical
[monitoring] Asset matched: hostname=prod-db-01 → asset_id=xyz
[monitoring] Incident auto-created: ticket_id=abc source=monitoring

Monitoring-Integration ​

Unterstützte Quellen ​

Integration-Playbooks ​

Check_MK 2.x ​

Prometheus / Alertmanager ​

Grafana ​

Jira Service Management ​

Was passiert mit einem Event? ​

1. Validierung ​

2. Deduplizierung (5-Minuten-Fenster) ​

3. Asset-Matching ​

4. CMDB-Enrichment ​

5. Incident-Auto-Erstellung (optional) ​

Webhook-Payload (Referenz) ​

Single Event ​

Batch ​

curl ​

REST-API ​

Was OpsWeave (noch) nicht macht ​

Empfehlungen ​

Debugging ​

Monitoring-Integration

Unterstützte Quellen

Integration-Playbooks

Check_MK 2.x

Prometheus / Alertmanager

Grafana

Jira Service Management

Was passiert mit einem Event?

1. Validierung

2. Deduplizierung (5-Minuten-Fenster)

3. Asset-Matching

4. CMDB-Enrichment

5. Incident-Auto-Erstellung (optional)

Webhook-Payload (Referenz)

Single Event

Batch

curl

REST-API

Was OpsWeave (noch) nicht macht

Empfehlungen

Debugging