Incident-Alerts deduplizieren und nach Schwere priorisieren
Viele IT-Teams stehen vor der Herausforderung, eine Flut von Incident-Alerts aus unterschiedlichen Quellen übersichtlich zu bündeln und sinnvoll zu priorisieren. Dieser Workflow nimmt strukturierte Alerts per Webhook entgegen, prüft die Eingabedaten, gruppiert sie nach Service und Fehlercode, zählt die Vorkommen, ermittelt die höchste Schwere sowie das aktuellste Ereignis pro Gruppe und berechnet daraus eine Priorität. Das Resultat ist eine konsolidierte, nach Priorität sortierte Incident-Liste im JSON-Format – ideal für Teams, die zahlreiche Alerts effizient zusammenfassen und priorisieren möchten.
IT-Teams und Betreiber von Monitoring- oder Incident-Management-Systemen profitieren von diesem Workflow, wenn sie zahlreiche Alerts aus verschiedenen Quellen erhalten und diese effizient konsolidieren wollen. Über einen POST-Webhook werden strukturierte Alerts im JSON-Format entgegengenommen. Der Workflow prüft, ob die Eingabedaten ein nicht-leeres Array von Alerts mit den Feldern service, errorCode, severity (1-5) und timestamp sind. Bei ungültigen Eingaben wird eine klare Fehlermeldung mit Index ausgegeben. Gültige Alerts werden nach Service und Fehlercode gruppiert, die Anzahl je Gruppe gezählt, die höchste Schwere (severity) und das aktuellste Ereignis (timestamp) bestimmt. Für jede Gruppe erfolgt eine Prioritätsberechnung (maxSeverity*100 + count). Das Ergebnis ist eine nach Priorität sortierte Liste von Incidents mit allen relevanten Feldern, die als JSON zurückgegeben wird. Um unbefugten Zugriff zu verhindern, muss die Webhook-Authentifizierung in n8n separat aktiviert werden. Ausführungsdaten werden in n8n gespeichert und sollten gemäß Datenschutzanforderungen verwaltet werden. Der Workflow kann als Grundlage für weitere Automatisierungen wie Benachrichtigungen oder Ticket-Erstellung dienen. Die Anpassung an eigene Alert-Schemata ist möglich, erfordert aber gegebenenfalls Änderungen im Code-Node.
KI-generiertes Bild
Geschätzte Zeitersparnis: 5–15 Minuten je AnwendungSchätzung im Detail
Mögliche monatliche Ersparnis
50–1500 Minuten
Angenommene Nutzung
10–100 Mal pro Monat
Einmaliger Einrichtungsaufwand
20 Minuten
Geschätzter monatlicher Wartungsaufwand
10 Minuten
Unverbindliche Schätzung auf Grundlage des analysierten Arbeitsablaufs. Die tatsächliche Ersparnis hängt von Aufgabe, Eingaben, Erfahrung und Arbeitsweise ab.
Installation
1. Workflow in n8n importieren.
2. Webhook-Node prüfen und Webhook-Authentifizierung in n8n aktivieren.
3. Workflow speichern.
4. Test-Listener starten und die angezeigte Test-URL aus dem Webhook-Node kopieren.
5. Mit einem Tool wie curl oder Postman einen POST-Request mit Content-Type application/json und folgendem Beispiel-Body an die Test-URL senden:
```json
{
"alerts": [
{"service": "DB", "errorCode": "E1", "severity": 3, "timestamp": "2024-06-01T10:00:00Z"},
{"service": "DB", "errorCode": "E1", "severity": 5, "timestamp": "2024-06-01T11:00:00Z"},
{"service": "API", "errorCode": "E2", "severity": 2, "timestamp": "2024-06-01T09:00:00Z"}
]
}
```
6. Die Antwort prüfen (siehe Nutzungsanleitung). Erst nach erfolgreichem Test den Workflow veröffentlichen/aktivieren und die Produktions-URL aus dem Webhook-Node verwenden.
Nutzung
1. Senden Sie einen POST-Request mit Content-Type application/json und einem Body wie im Import-Guide beschrieben an die Webhook-URL.
2. Erwartete Erfolgsantwort (HTTP 200):
```json
{
"status": "success",
"incidents": [
{
"fingerprint": "DB|E1",
"service": "DB",
"errorCode": "E1",
"count": 2,
"maxSeverity": 5,
"latestTimestamp": "2024-06-01T11:00:00Z",
"priority": 502
},
{
"fingerprint": "API|E2",
"service": "API",
"errorCode": "E2",
"count": 1,
"maxSeverity": 2,
"latestTimestamp": "2024-06-01T09:00:00Z",
"priority": 201
}
],
"inputCount": 3,
"incidentCount": 2
}
```
3. Fehlerfall (z.B. fehlendes Feld, HTTP 200):
```json
{
"status": "error",
"message": "alerts muss ein nicht-leeres Array sein."
}
```
Oder bei ungültigem Alert:
```json
{
"status": "error",
"message": "Ungültiger Alert.",
"invalidIndex": 1
}
```
4. Die tatsächlichen Ausgaben und Fehler werden als JSON zurückgegeben. Prüfen Sie die Felder status, incidents, inputCount und incidentCount.
5. Die Webhook-Authentifizierung muss in n8n separat aktiviert werden. Produktions-URL erst nach erfolgreichem Test verwenden.
6. Die Ausführungsdaten werden in n8n gespeichert. Konfigurieren Sie die Aufbewahrung und Zugriffsrechte nach Bedarf.
Benötigte Verbindungen und APIs
API-Verbindungen
Im Workflow-JSON wurden keine gespeicherten API-Zugangsdaten erkannt. Prüfe vor der Aktivierung trotzdem Webhooks, Zielsysteme, Zugangsdaten und Datenschutz.
Nodes
WebhookCodeRespond to Webhook
Isolierter Funktionstest bestanden
Optionaler isolierter Funktionstest
Geprüft wurde der isolierte Datenfluss ohne externe Dienste oder Zugangsdaten.
✓ Normalfall mit vollständigen DatenPrüft den vollständigen Standardablauf mit gültigen Beispieldaten.Isolierter Funktionstest bestanden✓ Variante oder GrenzfallPrüft eine zulässige Variante oder einen wichtigen Grenzfall.Isolierter Funktionstest bestanden✓ Zusätzliche VerarbeitungsregelPrüft die zusätzliche fachliche Verarbeitungsregel dieses Workflows.Isolierter Funktionstest bestanden✓ Ungültige oder unvollständige EingabePrüft, ob ungültige oder unvollständige Daten kontrolliert abgewiesen werden.Isolierter Funktionstest bestanden✓ Leere EingabePrüft, ob eine leere Anfrage kontrolliert beantwortet wird.Isolierter Funktionstest bestanden
