Skip to main content

Analizzare automaticamente gli alert Datadog

Instrada gli alert PagerDuty o Datadog a Devin per l’analisi automatica degli incidenti.
AuthorCognition
CategoryGestione degli incidenti
FeaturesAPI, MCP
1

Abilita l’MCP di Datadog

Devin ha bisogno di accedere al tuo account Datadog per consultare log, metriche e monitor durante un’indagine.
  1. Vai su Settings > MCP Marketplace e trova Datadog
  2. Fai clic su Enable e inserisci la tua Datadog API key e application key — generali in Datadog > Organization Settings > API Keys
  3. Fai clic su Test listing tools per verificare che Devin possa connettersi
Una volta abilitato, Devin può interrogare i log di errore, recuperare serie temporali di metriche, elencare i monitor attivi e cercare le tracce — tutto all’interno di una sessione. Scopri di più su come connettere i server MCP.
2

Crea il collegamento dagli alert a Devin

Ti serve un piccolo servizio che riceva i webhook di alert e avvii una sessione Devin tramite la Devin API. Distribuiscilo come funzione serverless (AWS Lambda, Cloudflare Worker) o come container leggero:
from flask import Flask, request, jsonify
import requests, os

app = Flask(__name__)

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

    # Campi del payload del webhook Datadog
    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
Crea un utente di servizio in Settings > Service Users su app.devin.ai con l’autorizzazione ManageOrgSessions. Copia il token API mostrato dopo la creazione e salvalo come DEVIN_API_KEY sul tuo servizio bridge. Imposta DEVIN_ORG_ID sull’ID della tua organizzazione — recuperalo chiamando GET https://api.devin.ai/v3/enterprise/organizations con il tuo token.Il codice sopra utilizza il !triage template playbook — duplicalo e personalizza i passaggi di analisi per il tuo stack, quindi aggiorna il playbook_id nel tuo servizio bridge.
3

Instrada gli avvisi verso il webhook

Direttamente da Datadog:
  1. Nel dashboard di Datadog, vai su Integrations > Webhooks
  2. Fai clic su New Webhook e imposta l’URL sull’endpoint del tuo bridge (ad es. https://your-bridge.example.com/alert)
  3. Nel messaggio di notifica di qualsiasi monitor, aggiungi @webhook-devin-bridge — Devin esegue un’indagine ogni volta che quel monitor viene attivato
Da PagerDuty:
  1. In PagerDuty, vai su Services > [your service] > Integrations
  2. Aggiungi un’integrazione Generic Webhooks (v3)
  3. Imposta l’URL del webhook sull’endpoint del tuo bridge e filtra per tipo di evento incident.triggered
Inizia con monitor di livello warning per testare la pipeline prima di instradare gli avvisi critici.
4

Che cosa esamina Devin

Quando un alert attiva una sessione, Devin usa il Datadog MCP per eseguire un’indagine strutturata — interrogando i log, correlando con i deploy e tracciando l’errore fino al codice sorgente.Esempio di indagine che Devin pubblica su Slack:
Indagine sull'alert: picco del tasso di errore su payments-service

Cronologia:
- 14:28 UTC — Deploy #492 rilasciato (commit abc123f)
- 14:31 UTC — Tasso di errore aumentato dallo 0,3% al 5,2%
- 14:32 UTC — Alert attivato

Causa principale: il Deploy #492 ha eseguito il refactoring del gestore webhook di Stripe
(src/webhooks/stripe.ts) in async/await ma ha rimosso il try/catch
attorno a handlePaymentIntent(). Le rejection non gestite restituiscono
errori 500 su circa il 4% delle richieste di checkout.

Correzione: aggiunto un error boundary con logging strutturato e risposte 4xx
appropriate per gli errori client.

PR #493 aperta → https://github.com/acme/payments/pull/493
5

Estendi la pipeline

Quando le indagini di base sono a posto, aggiungi ulteriore automazione:Personalizza il playbook di triage. Il bridge code utilizza già il template di playbook !triage. Duplicalo e adatta la checklist di indagine allo stack del tuo team: aggiungi runbook specifici per servizio, percorsi di escalation e convenzioni per le PR di hotfix.Definisci l’ambito in base alla severità. Instrada gli alert P1 per un’indagine immediata e un hotfix. Instrada gli alert P3 solo per l’analisi della causa radice. Usa prompt o playbook diversi per ciascun livello di severità.Aggiungi Knowledge sui tuoi servizi — soglie normali, architettura, runbook di reperibilità — in modo che l’indagine di Devin parta dal contesto del tuo team invece che da zero.