Skip to main content

Datadog-Warnmeldungen automatisch untersuchen

Leite PagerDuty- oder Datadog-Warnmeldungen an Devin weiter, um Incidents automatisch zu untersuchen.
AuthorCognition
CategoryIncident Response
FeaturesAPI, MCP
1

Datadog-MCP aktivieren

Devin benötigt Zugriff auf dein Datadog-Konto, um während einer Untersuchung Logs, Metriken und Monitore abzufragen.
  1. Gehe zu Settings > MCP Marketplace und suche nach Datadog
  2. Klicke auf Enable und gib deinen Datadog API key und Anwendungsschlüssel ein – generiere diese unter Datadog > Organization Settings > API Keys
  3. Klicke auf Test listing tools, um zu überprüfen, ob Devin eine Verbindung herstellen kann
Nach der Aktivierung kann Devin Fehler-Logs abfragen, Metrik-Zeitreihen abrufen, aktive Monitore auflisten und Traces durchsuchen – alles innerhalb einer Sitzung. Erfahre mehr über das Verbinden von MCP-Servern.
2

Richte die Alert-zu-Devin-Verbindung ein

Sie benötigen einen kleinen Service, der Alert-Webhooks empfängt und über die Devin API eine Devin-Session startet. Stellen Sie diesen als serverlose Funktion (AWS Lambda, Cloudflare Worker) oder als leichtgewichtigen Container bereit:
from flask import Flask, request, jsonify
import requests, os

app = Flask(__name__)

@app.route("/alert", methods=["POST"])
def handle_alert():
    payload = request.json

    # Datadog-Webhook-Payload-Felder
    alert_title = payload.get("title", "Unknown alert")
    tags_str = payload.get("tags", "")
    service = next(
        (t.split(":", 1)[1] for t in tags_str.split(",") if t.strip().startswith("service:")),
        "unknown-service"
    )
    alert_url = payload.get("link", "")

    org_id = os.environ["DEVIN_ORG_ID"]
    response = requests.post(
        f"https://api.devin.ai/v3/organizations/{org_id}/sessions",
        headers={"Authorization": f"Bearer {os.environ['DEVIN_API_KEY']}"},
        json={
            "prompt": (
                f"Datadog alert fired: '{alert_title}'\n"
                f"Service: {service}\n"
                f"Alert link: {alert_url}\n\n"
                "Using the Datadog MCP:\n"
                "1. Pull error logs for this service from the past 30 min\n"
                "2. Identify the top error messages and stack traces\n"
                "3. Check if this correlates with a recent deploy\n"
                "4. If the root cause is clear, open a hotfix PR\n"
                "5. Post your findings to #incidents on Slack"
            ),
            "playbook_id": "14fed18b89d44713a26e673cf258f548",
        }
    )
    return jsonify(response.json()), 200
Erstelle einen Service User unter Settings > Service Users auf app.devin.ai mit der Berechtigung ManageOrgSessions. Kopiere das nach der Erstellung angezeigte API-Token und speichere es als DEVIN_API_KEY in deinem Bridge-Service. Setze DEVIN_ORG_ID auf die ID deiner Organisation — rufe sie ab, indem du GET https://api.devin.ai/v3/enterprise/organizations mit deinem Token aufrufst.Der obige Code verwendet das !triage-Template-Playbook — dupliziere es, passe die Untersuchungsschritte für deinen Stack an und aktualisiere anschließend die playbook_id in deinem Bridge-Service.
3

Warnmeldungen an den Webhook weiterleiten

Direkt aus Datadog:
  1. Gehe in deinem Datadog-Dashboard zu Integrations > Webhooks
  2. Klicke auf New Webhook und setze die URL auf deinen Bridge-Endpunkt (z. B. https://your-bridge.example.com/alert)
  3. Füge in der Benachrichtigungsnachricht eines beliebigen Monitors @webhook-devin-bridge hinzu — Devin untersucht jedes Mal, wenn dieser Monitor ausgelöst wird
Aus PagerDuty:
  1. Gehe in PagerDuty zu Services > [your service] > Integrations
  2. Füge eine Generic Webhooks (v3)-Integration hinzu
  3. Setze die Webhook-URL auf deinen Bridge-Endpunkt und filtere nach Ereignistyp incident.triggered
Beginne mit Monitoren auf Warnstufe, um die Pipeline zu testen, bevor du kritische Alerts weiterleitest.
4

Was Devin prüft

Wenn ein Alert eine Session auslöst, verwendet Devin den Datadog-MCP, um eine strukturierte Untersuchung durchzuführen – Logs abzufragen, sie mit Deployments zu korrelieren und den Fehler bis zum Quellcode zurückzuverfolgen.Beispiel für eine Untersuchung, die Devin in Slack postet:
Alert-Untersuchung: Anstieg der Fehlerrate bei payments-service

Zeitverlauf:
- 14:28 UTC — Deploy #492 veröffentlicht (Commit abc123f)
- 14:31 UTC — Fehlerrate sprang von 0,3 % auf 5,2 %
- 14:32 UTC — Alert ausgelöst

Grundursache: Deploy #492 hat den Stripe-Webhook-Handler
(src/webhooks/stripe.ts) auf async/await umgestellt, dabei jedoch den try/catch-Block
um handlePaymentIntent() entfernt. Nicht behandelte Ablehnungen führen
bei ~4 % der Checkout-Anfragen zu 500-Fehlern.

Behebung: Error Boundary mit strukturiertem Logging und korrekten 4xx-Antworten
für Client-Fehler hinzugefügt.

Pull Request #493 geöffnet → https://github.com/acme/payments/pull/493
5

Pipeline erweitern

Sobald die grundlegende Analyse steht, fügen Sie mehr Automatisierung hinzu:Passen Sie das Triage-Playbook an. Der Bridge-Code verwendet bereits das !triage template playbook. Duplizieren Sie es und passen Sie die Checkliste für Analysen an den Stack Ihres Teams an — fügen Sie dienstspezifische Runbooks, Eskalationspfade und Konventionen für Hotfix-PRs hinzu.Nach Schweregrad steuern. Routen Sie P1-Alerts zur sofortigen Untersuchung und für Hotfixes. Routen Sie P3-Alerts ausschließlich für Root-Cause-Analysen. Verwenden Sie je nach Schweregrad unterschiedliche Prompts oder Playbooks.Fügen Sie Knowledge zu Ihren Services hinzu — normale Schwellenwerte, Architektur, On-Call-Runbooks — sodass Devin seine Untersuchung aus dem Kontext Ihres Teams heraus startet, statt bei null anzufangen.