Skip to main content

Enquêter automatiquement sur les alertes Datadog

Connectez les alertes PagerDuty ou Datadog à Devin pour l’analyse automatisée des incidents.
AuthorCognition
CategoryGestion des incidents
FeaturesAPI, MCP
1

Activer le MCP Datadog

Devin a besoin d’accéder à votre compte Datadog pour interroger les journaux, les métriques et les monitors lors d’investigations.
  1. Allez dans Settings > MCP Marketplace et recherchez Datadog
  2. Cliquez sur Enable et saisissez votre Datadog API key et votre application key — générez-les dans Datadog > Organization Settings > API Keys
  3. Cliquez sur Test listing tools pour vérifier que Devin peut se connecter
Une fois activé, Devin peut interroger les journaux d’erreurs, récupérer des séries temporelles de métriques, lister les monitors actifs et rechercher des traces — le tout dans une même session. En savoir plus sur la connexion de serveurs MCP.
2

Mettez en place la passerelle alertes-vers-Devin

Vous avez besoin d’un service léger qui reçoit les webhooks d’alerte et démarre une session Devin via la Devin API. Déployez-le sous forme de fonction serverless (AWS Lambda, Cloudflare Worker) ou de conteneur léger :
from flask import Flask, request, jsonify
import requests, os

app = Flask(__name__)

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

    # Champs du payload 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
Créez un service user dans Settings > Service Users sur app.devin.ai avec l’autorisation ManageOrgSessions. Copiez le jeton d’API affiché après la création et enregistrez-le comme DEVIN_API_KEY sur votre service passerelle. Définissez DEVIN_ORG_ID sur l’identifiant de votre organisation — obtenez-le en appelant GET https://api.devin.ai/v3/enterprise/organizations avec votre jeton.Le code ci-dessus utilise le playbook modèle !triage — dupliquez-le et personnalisez les étapes d’investigation pour votre stack, puis mettez à jour le playbook_id dans votre service passerelle.
3

Envoyer les alertes au webhook

Directement depuis Datadog :
  1. Dans votre tableau de bord Datadog, allez dans Integrations > Webhooks
  2. Cliquez sur New Webhook et définissez l’URL sur le point de terminaison de votre bridge (par ex. https://your-bridge.example.com/alert)
  3. Dans le message de notification de n’importe quel monitor, ajoutez @webhook-devin-bridge — Devin analyse chaque fois que ce monitor se déclenche
Depuis PagerDuty :
  1. Dans PagerDuty, allez dans Services > [your service] > Integrations
  2. Ajoutez une intégration Generic Webhooks (v3)
  3. Définissez l’URL du webhook sur le point de terminaison de votre bridge et filtrez par type d’événement incident.triggered
Commencez avec des monitors de niveau « warning » pour tester le pipeline avant de router les alertes critiques.
4

Ce que Devin analyse

Lorsqu’une alerte déclenche une session, Devin utilise le Datadog MCP pour mener une enquête structurée : interroger les logs, corréler avec les déploiements et remonter l’erreur jusqu’au code source.Exemple d’enquête que Devin publie sur Slack :
Analyse d'alerte : pic du taux d'erreur de payments-service

Chronologie :
- 14:28 UTC — Déploiement #492 publié (commit abc123f)
- 14:31 UTC — Taux d'erreur passé de 0,3 % à 5,2 %
- 14:32 UTC — Alerte déclenchée

Cause racine : le déploiement #492 a refactorisé le gestionnaire de webhook Stripe
(src/webhooks/stripe.ts) en async/await mais a supprimé le bloc try/catch
autour de handlePaymentIntent(). Les rejets non gérés renvoient
des erreurs 500 sur ~4 % des requêtes de paiement.

Correctif : ajout d'une barrière d'erreur avec journalisation structurée et réponses 4xx
appropriées pour les erreurs client.

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

Étendre le pipeline

Une fois les investigations de base en place, ajoutez davantage d’automatisation :Personnalisez le playbook de triage. Le code de bridge utilise déjà le playbook modèle !triage. Dupliquez-le et adaptez la checklist d’investigation à la stack de votre équipe — ajoutez des runbooks spécifiques à chaque service, des procédures d’escalade et des conventions pour les PR de correctif d’urgence (hotfix).Définissez le périmètre par sévérité. Acheminez les alertes P1 pour une investigation immédiate et un correctif d’urgence. Acheminez les alertes P3 uniquement pour l’analyse de la cause racine. Utilisez des prompts ou des playbooks différents selon le niveau de sévérité.Ajoutez du contenu dans Knowledge sur vos services — seuils normaux, architecture, runbooks d’astreinte — afin que l’investigation de Devin parte du contexte propre à votre équipe plutôt que de zéro.