·

Datadog MCP với OpenCode

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

OpenCode là một AI coding agent mã nguồn mở, chạy được trên nhiều LLM provider khác nhau (Anthropic, OpenAI, local model qua Ollama...), và cũng hỗ trợ MCP đầy đủ. Nếu team bạn đang dùng OpenCode làm coding agent chính vì tính linh hoạt về model, bài này sẽ hướng dẫn cách kết nối Datadog MCP, các pattern truy vấn hiệu quả, một ví dụ điều tra latency thực tế, và những hạn chế bạn cần biết trước khi tin tưởng hoàn toàn vào kết quả.

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

OpenCode quản lý MCP server qua file opencode.json ở project root hoặc file config global tại ~/.config/opencode/config.json. Cấu trúc khai báo MCP server trong OpenCode có phần khác Claude Code — dùng key mcp thay vì mcpServers:

{
  "mcp": {
    "datadog": {
      "type": "local",
      "command": ["npx", "-y", "@datadog/mcp-server"],
      "environment": {
        "DD_API_KEY": "{env:DD_API_KEY}",
        "DD_APP_KEY": "{env:DD_APP_KEY}",
        "DD_SITE": "datadoghq.com"
      },
      "enabled": true
    }
  }
}

Lưu ý cú pháp {env:DD_API_KEY} — đây là cách OpenCode tham chiếu biến môi trường từ shell hiện tại vào config, tránh hardcode giá trị thật. Set biến trước khi chạy:

export DD_API_KEY="your-api-key"
export DD_APP_KEY="your-app-key"
opencode

Sau khi khởi động, kiểm tra kết nối bằng lệnh trong session:

/mcp

Lệnh này liệt kê toàn bộ MCP server đã đăng ký cùng trạng thái kết nối. Nếu datadog hiện "error", thường do thiếu quyền execute với npx, hoặc set sai tên biến môi trường trong environment.

Mẹo: Nếu tổ chức bạn dùng self-hosted npm registry hoặc proxy công ty, npx -y có thể timeout khi cố tải package lần đầu. Cân nhắc cài package cố định trước (npm install -g @datadog/mcp-server) rồi đổi command thành đường dẫn binary trực tiếp, giúp khởi động nhanh và ổn định hơn trong CI hoặc môi trường mạng hạn chế.

Truy Vấn Logs, Metrics và Trạng Thái Monitor Từ OpenCode

OpenCode xử lý tool calling theo cách hiển thị rõ từng bước gọi tool trong terminal — điều này thực ra là một lợi thế cho việc học và audit, vì bạn thấy chính xác agent đang gọi tool nào với tham số gì, không phải "hộp đen".

Ví dụ một phiên truy vấn:

> Có monitor nào đang ở trạng thái Alert hoặc Warn cho service inventory-service không?

[tool call: search_monitors query="service:inventory-service" status:["Alert","Warn"]]

Có 1 monitor đang Alert: "Inventory sync queue depth > 1000", đã trigger từ
22 phút trước, giá trị hiện tại là 1,842.

Bạn có thể tiếp tục thu hẹp điều tra:

> Metric queue depth này tăng dần hay tăng đột ngột? Cho tôi xem xu hướng 2 giờ qua.

[tool call: query_metrics query="avg:inventory.sync.queue.depth{service:inventory-service}" from="2h"]

Xu hướng tăng dần và tuyến tính, không có bước nhảy đột ngột — bắt đầu tăng
từ khoảng 20:15 UTC, tốc độ tăng ổn định ~15 item/phút, cho thấy consumer
đang xử lý chậm hơn tốc độ producer đưa vào, thay vì một sự kiện đột biến.

Việc phân biệt "tăng dần" và "tăng đột ngột" rất quan trọng vì nó gợi ý hai loại nguyên nhân hoàn toàn khác nhau: tăng dần thường là capacity issue (thiếu tài nguyên xử lý), còn tăng đột ngột thường là do một thay đổi cụ thể (deploy, traffic spike, dependency down).

Mẹo: Yêu cầu OpenCode trả kết quả metric dưới dạng mô tả xu hướng bằng lời (tăng dần/đột ngột/dao động) thay vì chỉ đưa số thô — với time series dài, việc "đọc" hình dạng đường biểu diễn qua text từ agent nhanh hơn nhiều so với bạn tự mở dashboard và nhìn chart.

Ví Dụ Thực Tế: Điều Tra Latency Regression Trong OpenCode

Latency regression (suy giảm hiệu năng, độ trễ tăng so với trước) là một trong những loại vấn đề Datadog MCP xử lý tốt nhất, vì nó cần correlation giữa nhiều nguồn dữ liệu mà con người thường bỏ sót một trong số đó.

Kịch bản thực tế: team nhận báo cáo p95 latency của API /api/v1/search tăng gấp 3 lần so với tuần trước.

> API /api/v1/search có p95 latency tăng gấp 3 lần so với tuần trước. Điều tra
nguyên nhân bằng cách: (1) so sánh p95 hiện tại với 7 ngày trước, (2) kiểm tra
có deploy nào gần đây ảnh hưởng service search-api không, (3) lấy 5 trace
chậm nhất trong 1 giờ qua và phân tích span nào chiếm nhiều thời gian nhất.

OpenCode sẽ tuần tự thực hiện ba bước, và kết quả tổng hợp thường như sau:

1. p95 latency: hiện tại 850ms, cùng kỳ tuần trước 280ms (tăng 3.03x) — xác nhận.
2. Có 1 deploy search-api v3.2.0 vào 3 ngày trước, thêm tính năng "typo
   correction" cho search query.
3. Trong 5 trace chậm nhất, span "typo_correction.suggest" chiếm trung bình
   620ms/850ms tổng thời gian (73%) — đây là span mới xuất hiện, không có
   trong trace của tuần trước.

=> Nghi vấn cao: tính năng typo correction mới thêm trong v3.2.0 là nguyên
nhân latency regression.

Đây là ví dụ điển hình cho thấy sức mạnh của correlation tự động — nếu làm tay, bạn phải tự nhớ có deploy gần đây, tự mở APM để so sánh trace trước/sau, và tự tính tỷ lệ phần trăm thời gian mỗi span chiếm dụng.

Mẹo: Khi nghi ngờ một feature mới là nguyên nhân, luôn yêu cầu agent so sánh trace "trước và sau" deploy đó cụ thể (không chỉ so sánh metric trung bình), vì trace-level comparison cho thấy chính xác span nào mới xuất hiện hoặc tăng thời gian — điều mà metric tổng hợp không thể hiện rõ.

Những Hạn Chế Đã Biết Của Datadog MCP Trong OpenCode

Trước khi tin tưởng hoàn toàn vào workflow này, cần hiểu rõ một số hạn chế thực tế:

  • Không có session caching giữa các lần gọi tool. Mỗi câu hỏi mới trong OpenCode có thể khiến agent gọi lại tool từ đầu dù dữ liệu chưa thay đổi, gây tốn API quota không cần thiết nếu bạn hỏi lại câu tương tự nhiều lần trong thời gian ngắn.
  • Model nhỏ hơn build query DQL kém chính xác hơn. Vì OpenCode hỗ trợ nhiều model, nếu bạn chọn một model nhỏ/nhanh (để tiết kiệm chi phí) cho tác vụ observability phức tạp, khả năng agent build sai cú pháp query hoặc chọn sai tool cao hơn so với dùng model lớn.
  • Không tự động phân trang (pagination) tốt với dataset lớn. Với log query trả về hàng chục nghìn kết quả, một số version MCP server chỉ lấy trang đầu và agent có thể đưa ra kết luận dựa trên dữ liệu không đầy đủ mà không cảnh báo rõ.
  • Giới hạn context window khi dữ liệu trace quá lớn. Một trace phức tạp với hàng trăm span có thể vượt quá khả năng agent phân tích trọn vẹn trong một lần gọi, dẫn đến agent chỉ tóm tắt phần đầu.

Cách giảm thiểu: luôn dùng model có khả năng reasoning tốt (ví dụ Claude Sonnet hoặc tương đương) cho các phiên điều tra quan trọng, và luôn hỏi thêm "kết quả này có bị cắt/giới hạn không" khi nghi ngờ dataset lớn.

Mẹo: Với các case điều tra phức tạp có nhiều bước correlation, chia nhỏ thành từng câu hỏi tuần tự thay vì gộp vào một prompt dài duy nhất — điều này giúp bạn kiểm tra được từng bước trung gian và phát hiện sớm nếu agent bị giới hạn dữ liệu ở đâu đó giữa chuỗi suy luận.

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

Tổng hợp lại các thực hành tốt nhất khi dùng Datadog MCP với OpenCode:

  • Cài cố định package MCP server thay vì luôn dùng npx -y trong môi trường mạng công ty bị giới hạn.
  • Ưu tiên model có reasoning mạnh cho các phiên điều tra observability quan trọng, không chỉ chọn theo tốc độ/chi phí.
  • Luôn yêu cầu agent mô tả xu hướng metric bằng lời, không chỉ đưa số.
  • Chia nhỏ điều tra phức tạp thành nhiều câu hỏi tuần tự để dễ kiểm tra từng bước.
  • Hỏi rõ "dữ liệu này có bị cắt do giới hạn phân trang không" khi nghi ngờ dataset lớn.

Mẹo: Ghi lại các câu lệnh /mcp và cấu hình đã hoạt động tốt vào README của project, vì OpenCode vẫn đang phát triển nhanh — cú pháp config mcp có thể thay đổi giữa các version, và có tài liệu nội bộ giúp team không phải debug lại từ đầu sau mỗi lần upgrade.

Tiếp Datadog MCP với Gemini CLI