Skip to main content

Investigación automática de alertas de Datadog

Conecta las alertas de PagerDuty o Datadog con Devin para investigar automáticamente los incidentes.
AuthorCognition
CategoryRespuesta ante incidentes
FeaturesAPI, MCP
1

Activa el MCP de Datadog

Devin necesita acceso a tu cuenta de Datadog para consultar logs, métricas y monitores durante una investigación.
  1. Ve a Settings > MCP Marketplace y busca Datadog
  2. Haz clic en Enable e introduce tu Datadog API key y tu application key; genéralas en Datadog > Organization Settings > API Keys
  3. Haz clic en Test listing tools para verificar que Devin puede conectarse
Una vez habilitado, Devin puede consultar logs de errores, obtener series temporales de métricas, listar monitores activos y buscar trazas, todo dentro de una sesión. Obtén más información sobre cómo conectar servidores MCP.
2

Cree el puente de alertas hacia Devin

Necesitas un servicio pequeño que reciba webhooks de alerta e inicie una sesión de Devin a través de la Devin API. Despliega esto como una función serverless (AWS Lambda, Cloudflare Worker) o un contenedor ligero:
from flask import Flask, request, jsonify
import requests, os

app = Flask(__name__)

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

    # Campos del payload del webhook de 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 service user en Settings > Service Users en app.devin.ai con el permiso ManageOrgSessions. Copia el token de API que se muestra después de crearlo y guárdalo como DEVIN_API_KEY en tu servicio puente. Configura DEVIN_ORG_ID con el ID de tu organización: puedes obtenerlo llamando a GET https://api.devin.ai/v3/enterprise/organizations con tu token.El código anterior usa el playbook de plantilla !triage: duplícalo y personaliza los pasos de investigación para tu stack, luego actualiza el playbook_id en tu servicio puente.
3

Envía las alertas al webhook

Directamente desde Datadog:
  1. En tu panel de Datadog, ve a Integrations > Webhooks
  2. Haz clic en New Webhook y establece la URL a tu endpoint del bridge (por ejemplo, https://your-bridge.example.com/alert)
  3. En el mensaje de notificación de cualquier monitor, agrega @webhook-devin-bridge — Devin investigará siempre que se active ese monitor
Desde PagerDuty:
  1. En PagerDuty, ve a Services > [your service] > Integrations
  2. Agrega una integración Generic Webhooks (v3)
  3. Establece la URL del webhook en tu endpoint del bridge y filtra por tipo de evento incident.triggered
Comienza con monitores con nivel de advertencia para probar el flujo antes de enrutar alertas críticas.
4

Qué investiga Devin

Cuando una alerta inicia una sesión, Devin usa Datadog MCP para llevar a cabo una investigación estructurada: consultar logs, correlacionarlos con despliegues y rastrear el error hasta el código fuente.Ejemplo de investigación que Devin publica en Slack:
Investigación de alerta: pico en la tasa de errores de payments-service

Cronología:
- 14:28 UTC — Deploy #492 publicado (commit abc123f)
- 14:31 UTC — La tasa de errores aumentó de 0.3% a 5.2%
- 14:32 UTC — Alerta activada

Causa raíz: El Deploy #492 refactorizó el manejador de webhooks de Stripe
(src/webhooks/stripe.ts) a async/await pero eliminó el try/catch
alrededor de handlePaymentIntent(). Los rechazos no controlados están devolviendo
errores 500 en ~4% de las solicitudes de pago.

Corrección: Se añadió un límite de error con registro estructurado y respuestas
4xx adecuadas para errores del cliente.

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

Ampliar el pipeline

Una vez que la investigación básica esté funcionando, añade más automatización:Personaliza el playbook de triaje. El código de bridge ya usa el !triage template playbook. Duplícalo y adapta la lista de verificación de investigación al stack de tu equipo: añade runbooks específicos por servicio, rutas de escalamiento y convenciones para PRs de hotfix.Acota según la gravedad. Canaliza las alertas P1 para investigación inmediata y hotfix. Canaliza las alertas P3 solo para análisis de causa raíz. Usa diferentes prompts o playbooks según el nivel de gravedad.Añade Knowledge sobre tus servicios — umbrales normales, arquitectura, runbooks de guardia — para que la investigación de Devin empiece desde el contexto de tu equipo en lugar de desde cero.