Überblick
Einrichtung
Einen Webhook-Bridge-Service bereitstellen
Erstellen Sie einen kleinen Handler, der PagerDuty-Incident-Payloads empfängt und die Devin API aufruft, um Sitzungen zur Untersuchung zu starten.Erstellen Sie einen Service-Benutzer in Settings > Service Users mit der Berechtigung Stellen Sie dies an einem Ort bereit, der HTTPS-Traffic empfangen kann — etwa in einem Cloudflare Worker, AWS Lambda oder einem kleinen Container.
ManageOrgSessions. Speichern Sie das API-Token als DEVIN_API_KEY, Ihre Organisations-ID als DEVIN_ORG_ID und ein gemeinsames Secret als WEBHOOK_SECRET auf Ihrem Bridge-Service. Im nächsten Schritt konfigurieren Sie dieses Secret auch in den PagerDuty-Webhooks unter Custom Headers.Eine Webhook-Integration in PagerDuty hinzufügen
- Gehen Sie in PagerDuty zu Services > [your service] > Integrations
- Klicken Sie auf Add Integration und wählen Sie Generic Webhooks (v3) aus
- Setzen Sie die Webhook URL auf den Endpunkt Ihres Bridge-Service (z. B.
https://your-bridge.example.com/pagerduty-alert) - Fügen Sie unter Custom Headers
X-Webhook-Secretmit demselben Wert hinzu, den Sie auf Ihrem Bridge-Service alsWEBHOOK_SECRETgespeichert haben - Filtern Sie unter Event Subscription nach dem Ereignistyp
incident.triggered, damit der Webhook nur bei neuen Incidents ausgelöst wird
Die Pipeline überprüfen
Lösen Sie in PagerDuty einen Test-Incident aus (oder verwenden Sie einen Test-Service) und bestätigen Sie, dass:
- Ihr Bridge-Service die Webhook-Payload empfängt
- Eine neue Devin-Sitzung unter app.devin.ai erstellt wird
- Devin mit der Untersuchung des Incidents beginnt
Best Practices
- Beginnen Sie mit Monitoren auf Warnstufe. Testen Sie die Pipeline mit unkritischen Incidents, bevor Sie P1-Produktions-Alerts an Devin weiterleiten.
- Filtern Sie nach Service oder Schweregrad. Verwenden Sie die Webhook-Ereignisabonnements von PagerDuty oder fügen Sie Logik in Ihrer Bridge hinzu, um Services mit niedriger Priorität oder hohem Alert-Aufkommen zu überspringen. So verhindern Sie, dass Devin von Alerts mit geringem Mehrwert überlastet wird.
- Verwenden Sie je nach Schweregrad unterschiedliche Playbooks. Leiten Sie P1-Alerts zur sofortigen Untersuchung und für Hotfixes weiter. Leiten Sie P3-Alerts nur zur Root-Cause-Analyse weiter. Übergeben Sie je nach Dringlichkeit unterschiedliche
playbook_id-Werte in der Devin-API-Anfrage. - Taggen Sie Sitzungen zur Nachverfolgung. Der Beispielcode versieht jede Sitzung mit
pagerduty-triageund dem Servicenamen, sodass sie sich im Devin-Dashboard leicht filtern und prüfen lassen.
Kombination mit Datadog
- PagerDuty leitet den Alert an Devin weiter (wodurch die Untersuchungssitzung gestartet wird)
- Devin verwendet Datadog MCP, um Logs, Metriken und Traces für den betroffenen Service abzufragen
