·

Datadog MCP với Claude Code CLI and VS Code

Cài đặt Datadog MCP trong Claude Code CLI and VS Code để AI agent có thể truy vấn metric, log và monitor ngay trong trình soạn thảo.

Claude Code là một trong những MCP client trưởng thành nhất hiện nay, và khi kết hợp với Datadog MCP server, bạn có một workflow điều tra incident (sự cố) chạy ngay trong terminal hoặc extension VS Code — không cần rời khỏi ngữ cảnh code để mở dashboard. Bài này hướng dẫn từ cài đặt, cách đặt câu hỏi hiệu quả bằng ngôn ngữ tự nhiên, đến việc liên kết trace với code thật trong VS Code, và dùng AI để dựng timeline incident hoàn chỉnh.

Cài Đặt và Kết Nối Datadog MCP Với Claude Code

Claude Code hỗ trợ MCP server qua cả CLI command và file cấu hình. Cách nhanh nhất để thêm Datadog MCP:

claude mcp add datadog -- npx -y @datadog/mcp-server

Sau đó set biến môi trường cần thiết. Bạn có thể set trực tiếp trong shell profile, hoặc — cách khuyến nghị hơn cho team — khai báo trong file .claude/settings.json ở project root:

{
  "mcpServers": {
    "datadog": {
      "command": "npx",
      "args": ["-y", "@datadog/mcp-server"],
      "env": {
        "DD_API_KEY": "${DD_API_KEY}",
        "DD_APP_KEY": "${DD_APP_KEY}",
        "DD_SITE": "datadoghq.com"
      }
    }
  }
}

Với extension VS Code của Claude Code, MCP server được kế thừa từ cùng file config này — không cần setup riêng. Sau khi lưu file, restart Claude Code (CLI: gõ lại claude; VS Code: reload window) và verify bằng:

claude mcp list

Bạn sẽ thấy datadog với status "connected". Nếu status là "failed", 90% nguyên nhân là thiếu DD_APP_KEY hoặc sai DD_SITE.

Mẹo: Chạy thử một câu lệnh đơn giản ngay sau khi kết nối, ví dụ "liệt kê 5 monitor đang ở trạng thái Alert", để xác nhận kết nối hoạt động thật trước khi bắt đầu một phiên điều tra dài — tránh mất thời gian giữa chừng phát hiện ra key sai.

Xây Dựng Query Logs và Metrics Từ Câu Hỏi Ngôn Ngữ Tự Nhiên

Điểm mạnh của Claude Code khi kết hợp Datadog MCP là khả năng lặp lại (iterate) câu hỏi trong một phiên hội thoại liên tục — bạn hỏi, xem kết quả, rồi hỏi tiếp dựa trên kết quả đó, giống hệt cách bạn debug cùng một đồng nghiệp senior.

Ví dụ một phiên điều tra thực tế:

Tôi > Service checkout-api có đang có tỷ lệ lỗi bất thường trong 1 giờ qua không?

Claude > [gọi tool query_metrics với avg:trace.checkout.request.errors{service:checkout-api}]
Error rate hiện tại là 4.2%, so với baseline thường ngày là 0.3%. Spike bắt đầu
từ khoảng 13:45 UTC.

Tôi > Log lỗi phổ biến nhất trong khoảng thời gian đó là gì?

Claude > [gọi tool aggregate_logs group by error.message, filter service:checkout-api
status:error, time range 13:40-14:00]
90% log lỗi có message "PaymentGatewayTimeoutError", tất cả đều liên quan đến
downstream service "payment-gateway".

Chuỗi hội thoại này minh hoạ đúng cách dùng: mỗi câu hỏi thu hẹp phạm vi dựa trên câu trả lời trước, thay vì cố gắng hỏi một câu "tìm hết mọi vấn đề" quá rộng khiến agent phải quét dữ liệu khổng lồ.

Một pattern hữu ích khác là yêu cầu agent tự viết ra query DQL nó dùng, để bạn học dần cú pháp và có thể tái sử dụng trực tiếp trên Datadog UI sau này:

Sau mỗi lần bạn gọi tool truy vấn, hãy hiển thị luôn câu query DQL tương ứng
để tôi có thể copy dùng lại trên dashboard.

Mẹo: Đặt câu hỏi theo dạng "so sánh với baseline" thay vì hỏi số tuyệt đối (ví dụ "error rate hiện tại là bao nhiêu, so với 24 giờ trước cùng giờ") — cách này giúp agent tự phát hiện bất thường chính xác hơn nhiều so với việc bạn phải tự đánh giá con số có "cao" hay không.

Liên Kết APM Traces Với Code Ứng Dụng Trong VS Code

Đây là phần khiến Claude Code trong VS Code khác biệt rõ so với việc dùng Datadog UI thuần: agent có quyền truy cập cả trace data và source code cùng lúc, nên nó có thể nối trực tiếp một APM span (đoạn trace) với đúng dòng code gây ra latency.

Ví dụ workflow thực tế:

Trace ID abc123def456 có một span "db.query" kéo dài 2.3 giây trong service
order-service. Tìm đoạn code trong repo hiện tại đang thực thi query này,
và cho biết có N+1 query pattern hay thiếu index nào không.

Agent sẽ: gọi get_trace để lấy chi tiết span (bao gồm resource name, thường là tên function hoặc SQL query rút gọn) → dùng resource name đó để grep/search trong codebase mở trong VS Code → đọc code liên quan → đối chiếu với thông tin span (số lượng query lặp lại, thời gian mỗi query) để đưa ra chẩn đoán.

Kết quả thực tế thường trông như:

Span "db.query" tương ứng với hàm `OrderService.getOrderItems()` tại
src/services/order_service.py:142. Đây là vòng lặp gọi query riêng cho mỗi
order item — chính là N+1 query pattern. Đề xuất: dùng eager loading (JOIN
hoặc prefetch_related) để giảm từ N query xuống 1.

Đây chính là giá trị cốt lõi của việc chạy MCP ngay trong IDE: agent không chỉ nói "có N+1 query" một cách trừu tượng, mà chỉ đúng file, đúng dòng, đúng hàm.

Mẹo: Mở đúng repo/branch tương ứng với version đang chạy production khi làm bước này. Nếu code trong workspace đã khác xa version deploy thực tế (do đã có commit mới chưa release), agent có thể chỉ sai vị trí — luôn hỏi thêm "code này có khớp với deploy hiện tại của service không" nếu bạn không chắc.

Prompt AI Để Tạo Incident Timeline Từ Dữ Liệu Telemetry

Sau khi thu thập đủ dữ kiện rời rạc (log, trace, metric, deploy event), bước cuối là tổng hợp thành một timeline mạch lạc — phần việc mà AI làm nhanh và chính xác hơn con người vì nó không bị bias khi sắp xếp thứ tự thời gian của nhiều nguồn khác nhau.

Prompt mẫu cho bước tổng hợp:

Dựa trên tất cả dữ liệu chúng ta đã thu thập trong phiên này (log lỗi, trace,
metric error rate, và deploy marker), hãy viết một incident timeline theo
định dạng:
- Thời điểm (UTC) | Sự kiện | Nguồn dữ liệu (log/trace/metric/deploy)
Sắp xếp theo thứ tự thời gian tăng dần, và đánh dấu rõ thời điểm nghi vấn
là root cause.

Kết quả điển hình:

13:40 UTC | Deploy checkout-api v2.14.0 lên production | deploy marker
13:45 UTC | Error rate checkout-api tăng từ 0.3% lên 4.2% | metric
13:46 UTC | Log lỗi PaymentGatewayTimeoutError xuất hiện lần đầu | log
13:46-14:00 UTC | 340 request checkout thất bại với timeout tới payment-gateway | log
14:02 UTC | Trace cho thấy connection pool tới payment-gateway bị exhausted | APM trace

=> Nghi vấn root cause: deploy v2.14.0 giảm connection pool size của
payment-gateway client từ 50 xuống 10, gây exhausted dưới tải cao điểm.

Timeline dạng này có thể copy trực tiếp vào postmortem document hoặc incident channel, tiết kiệm đáng kể thời gian viết báo cáo sau khi đã giải quyết xong sự cố.

Mẹo: Luôn yêu cầu agent phân biệt rõ "sự kiện xác nhận từ dữ liệu" và "suy luận/giả thuyết" trong timeline — ví dụ dùng label "[Giả thuyết]" cho các dòng chưa được kiểm chứng 100%. Việc trộn lẫn hai loại này là nguyên nhân phổ biến khiến postmortem đưa ra kết luận vội vàng và sai root cause thật.

Mẹo Sử Dụng Hiệu Quả

Ngoài các mẹo đã nêu theo từng phần, đây là vài nguyên tắc chung khi dùng Datadog MCP với Claude Code CLI và VS Code:

  • Luôn bắt đầu phiên điều tra bằng một câu hỏi hẹp (một service, một time range ngắn), rồi mở rộng dần dựa trên kết quả, thay vì hỏi một câu quá rộng ngay từ đầu.
  • Yêu cầu agent hiển thị query DQL gốc bên cạnh kết quả, để bạn vừa học vừa verify.
  • Khi liên kết trace với code, luôn xác nhận version code đang mở khớp với version đã deploy.
  • Dùng file rule project (.claude/settings.json hoặc CLAUDE.md) để lưu sẵn quy ước về service name, env name của tổ chức bạn — giúp agent build query đúng ngay từ lần hỏi đầu tiên, không cần bạn giải thích lại mỗi phiên.

Mẹo: Lưu lại các prompt điều tra hiệu quả nhất của bạn thành một file "playbook" trong repo (ví dụ docs/incident-playbook.md), rồi tham chiếu file này trong CLAUDE.md. Qua thời gian, đây trở thành tài sản tri thức chung cho cả team, không phụ thuộc vào một cá nhân "biết cách hỏi AI đúng".

Tiếp Datadog MCP với OpenCode