DokumentationWorkflowsHTTP und Entwicklerwerkzeuge
PagerDuty Node
Löst einen Incident über die PagerDuty Events API v2 aus und listet bestehende Incidents über die REST-API auf. Hier findest du Einrichtung, Felder, Ein- und Ausgaben, Testablauf und Fehlerbehebung.
8 Min LesezeitAktualisiert am
Was PagerDuty macht
Löst einen Incident über die PagerDuty Events API v2 aus und listet bestehende Incidents über die REST-API auf.
- Verarbeitet einen Eingang.
- Stellt einen Ausgang für weitere Schritte bereit.
- Wird als normaler Schritt in den Ablauf eingebunden.
Node einrichten
- 01Öffne einen Workflow und füge „PagerDuty“ über Bausteine hinzu.
- 02Fülle die erforderlichen Felder aus. Werte aus vorherigen Schritten kannst du als Variable einsetzen.
- 03Nutze Testdaten oder starte einen Testlauf und prüfe die Ausgabe des Nodes.
- 04Verbinde den erfolgreichen Ausgang mit dem nächsten Schritt und aktiviere den Workflow erst nach einem vollständigen Probelauf.
Aktionen und Betriebsarten
Wähle im Feld „Aktion“ die gewünschte Funktion. Danach zeigt das Node-Panel nur die dafür relevanten Einstellungen.
- Incident auslösen
- Incidents auflisten
Einstellungen
| Feld | Bedeutung | Bereich |
|---|---|---|
| PagerDuty-Zugangsdaten | Wähle deine PagerDuty-Verbindung. Das Modal trennt den Events Routing Key für neue Incidents vom REST API Access Key zum Lesen und fragt die feste Region ab. | Standard |
| Aktion | Auswahl: Incident auslösen, Incidents auflisten | Standard |
| Zusammenfassung | Kurze Zusammenfassung des Vorfalls, wird als Titel des Incidents verwendet. | Standard |
| Schweregrad | Wie kritisch der Vorfall ist. | Standard |
| Quelle | Identifiziert, wo der Vorfall herkommt (z.B. Servername oder Systemname). Optional, Standard ist „anymize-workflow". | Standard |
| Dedup-Key | Optionaler eigener Schlüssel, um zusammengehörige Ereignisse zu einem Incident zu bündeln. Wenn leer, generiert PagerDuty automatisch einen. | Standard |
| Komponente | Optional: die betroffene Komponente des Systems. | Standard |
| Gruppe | Optional: logische Gruppierung (z.B. Umgebung oder Cluster). | Standard |
| Status-Filter | Kommagetrennte Liste von Status-Werten (triggered, acknowledged, resolved). Leer nutzt den ungefilterten PagerDuty-Standard. | Standard |
| Max. Anzahl | Wie viele Incidents maximal geladen werden sollen (1,100). | Standard |
| Für jedes Item einzeln ausführen | Aus (Standard): der Node läuft einmal für den gesamten Input. An: bekommt er mehrere Items (z. B. aus „Liste aufteilen“), läuft er einmal PRO Item, und {{ $json }} ist dabei jeweils genau dieses Item. So arbeitest du eine Dateiliste Eintrag für Eintrag ab. | Erweitert |
| Wenn ein Item fehlschlägt | „Überspringen“ schreibt für das fehlgeschlagene Item ein `error`-Feld und verarbeitet die übrigen weiter, statt den ganzen Lauf an einer einzigen unlesbaren Datei scheitern zu lassen. | Erweitert |
| Pause zwischen Items (Millisekunden) | Wartezeit vor jedem Durchlauf außer dem ersten. 1000 = 1 Sekunde pro Item. Nützlich, wenn die Gegenstelle sonst dichtmacht. Maximal 300000 (5 Minuten). | Erweitert |
Eingaben und Ausgaben
| Eingabe | Bedeutung | Typ |
|---|---|---|
| Standard | Der Node übernimmt das vollständige Ergebnis des vorherigen Schritts. | JSON |
| Ausgabe | Bedeutung | Typ |
|---|---|---|
| Standard | Das Ergebnis steht dem nächsten Schritt als JSON zur Verfügung. | JSON |
Dieser Node kann Listen Item für Item verarbeiten. Fehlerbehandlung und Pause zwischen Items findest du in den erweiterten Einstellungen.
Beispiel und Testlauf
Bei kritischem Fehler im Monitoring einen PagerDuty-Incident auslösen: Starte den Node zunächst mit einem kleinen, eindeutig erkennbaren Datensatz. Öffne danach die Ausgabe und verwende nur Felder, die dort tatsächlich vorhanden sind.
Beispiel für einen Testlauf
{
"summary": "API antwortet mit 500ern seit 5 Minuten",
"severity": "critical",
"source": "api-prod-01",
"component": "api-gateway"
}Zugriff und Sicherheit
Prüfe vor der Aktivierung, welche Daten in diesen Schritt gelangen und welche Daten seine Ausgabe enthält.
Schlüssel und Zugangsdaten gehören in die geschützte Verbindungsverwaltung. Trage sie nicht als normalen Text in Workflow-Felder, Testdaten oder Beschreibungen ein.
Häufige Fehler beheben
- Keine Ausgabe: Prüfe den letzten Testlauf und ob der vorherige Node die erwarteten Felder geliefert hat.
- Variable bleibt leer: Öffne die Ausgabe des vorherigen Schritts und übernimm den Feldnamen aus den echten Testdaten.
- Liste wird nur einmal verarbeitet: Aktiviere die Ausführung pro Item in den erweiterten Einstellungen.