Skip to main content

Investigue Alertas do Datadog Automaticamente

Conecte alertas do PagerDuty ou Datadog ao Devin para investigação automática de incidentes.
AuthorCognition
CategoryResposta a Incidentes
FeaturesAPI, MCP
1

Ativar o MCP do Datadog

Devin precisa de acesso à sua conta no Datadog para consultar logs, métricas e monitores durante uma investigação.
  1. Vá para Settings > MCP Marketplace e encontre Datadog
  2. Clique em Enable e insira sua Chave de API do Datadog e sua application key — gere essas chaves em Datadog > Organization Settings > API Keys
  3. Clique em Test listing tools para verificar se Devin consegue se conectar
Depois de habilitado, Devin pode consultar logs de erro, extrair séries temporais de métricas, listar monitores ativos e pesquisar traces — tudo dentro de uma sessão. Saiba mais sobre como conectar servidores MCP.
2

Crie a ponte entre alertas e o Devin

Você precisa de um pequeno serviço que receba webhooks de alerta e inicie uma sessão do Devin via Devin API. Faça o deploy disso como uma função serverless (AWS Lambda, Cloudflare Worker) ou como um container leve:
from flask import Flask, request, jsonify
import requests, os

app = Flask(__name__)

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

    # Campos do payload do webhook do 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
Crie um usuário de serviço em Settings > Service Users em app.devin.ai com a permissão ManageOrgSessions. Copie o token de API exibido após a criação e armazene-o como DEVIN_API_KEY no seu serviço de ponte. Defina DEVIN_ORG_ID como o ID da sua organização — obtenha-o chamando GET https://api.devin.ai/v3/enterprise/organizations com o seu token.O código acima usa o !triage template playbook — duplique-o e personalize as etapas de investigação para o seu stack e, em seguida, atualize o playbook_id no seu serviço de ponte.
3

Encaminhar alertas para o webhook

Diretamente no Datadog:
  1. No painel do Datadog, vá para Integrations > Webhooks
  2. Clique em New Webhook e defina a URL para o endpoint da sua bridge (por exemplo, https://your-bridge.example.com/alert)
  3. Na mensagem de notificação de qualquer monitor, adicione @webhook-devin-bridge — Devin investiga sempre que esse monitor for acionado
No PagerDuty:
  1. No PagerDuty, vá para Services > [your service] > Integrations
  2. Adicione uma integração Generic Webhooks (v3)
  3. Defina a URL do webhook para o endpoint da sua bridge e filtre pelo tipo de evento incident.triggered
Comece com monitores de nível de aviso para testar o pipeline antes de rotear alertas críticos.
4

O que o Devin analisa

When an alert triggers a session, Devin uses the Datadog MCP to run a structured investigation — querying logs, correlating with deploys, and tracing the error to source code.Example investigation Devin posts to Slack:
Investigação de Alerta: pico na taxa de erros do payments-service

Linha do tempo:
- 14:28 UTC — Deploy #492 publicado (commit abc123f)
- 14:31 UTC — Taxa de erros saltou de 0,3% para 5,2%
- 14:32 UTC — Alerta disparado

Causa raiz: O Deploy #492 refatorou o handler de webhook do Stripe
(src/webhooks/stripe.ts) para async/await, mas removeu o try/catch
ao redor de handlePaymentIntent(). Rejeições não tratadas estão retornando
erros 500 em ~4% das requisições de checkout.

Correção: Adicionado um error boundary com logging estruturado e respostas
4xx adequadas para erros do cliente.

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

Expandir o pipeline

Depois que a investigação básica estiver funcionando, adicione mais automação:Personalize o playbook de triagem. O código de integração já usa o !triage template playbook. Duplique-o e adapte a checklist de investigação ao stack da sua equipe — adicione runbooks específicos por serviço, fluxos de escalonamento e convenções para PRs de hotfix.Defina o escopo por severidade. Direcione alertas P1 para investigação imediata e hotfix. Direcione alertas P3 apenas para análise de causa raiz. Use prompts ou playbooks diferentes para cada nível de severidade.Adicione Knowledge sobre seus serviços — limites normais, arquitetura, runbooks de plantão — para que a investigação do Devin comece a partir do contexto da sua equipe em vez de do zero.