·

Datadog MCP với Gemini CLI

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

Gemini CLI là công cụ agentic coding chính thức của Google, hỗ trợ MCP như một cơ chế mở rộng tool tiêu chuẩn. Với những team đã dùng Google Cloud và muốn giữ toolchain thống nhất trong hệ sinh thái Google nhưng vẫn cần observability qua Datadog, việc kết nối Datadog MCP vào Gemini CLI mở ra một luồng làm việc phân tích telemetry (dữ liệu viễn trắc — log, metric, trace) khá mạnh, dù có vài điểm khác biệt so với các client khác mà bạn cần biết.

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

Gemini CLI đọc cấu hình MCP từ file ~/.gemini/settings.json (global) hoặc .gemini/settings.json trong project root (ưu tiên cao hơn khi có xung đột). Khai báo Datadog MCP server:

{
  "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"
      },
      "timeout": 30000
    }
  }
}

Lưu ý field timeout (đơn vị milliseconds) — Gemini CLI có xu hướng đặt timeout mặc định cho MCP tool call ngắn hơn một số client khác, và các query Datadog trên dataset lớn (ví dụ aggregate log qua hàng triệu record) có thể mất hơn 10 giây. Nếu bạn thấy lỗi timeout với query phức tạp, tăng giá trị này trước khi nghi ngờ config sai.

Khởi động và kiểm tra:

gemini

Trong session, gõ:

/mcp list

để xem trạng thái server. Muốn xem chi tiết tool nào đã được expose:

/mcp desc datadog

Lệnh này in ra toàn bộ schema tool (tên, tham số, mô tả) mà Datadog MCP server cung cấp cho phiên hiện tại — rất hữu ích để biết chính xác agent có thể/không thể làm gì trước khi bắt đầu hỏi.

Mẹo: Luôn chạy /mcp desc datadog sau mỗi lần update package @datadog/mcp-server, vì danh sách tool và tham số có thể thay đổi giữa các version — biết trước sự thay đổi giúp bạn điều chỉnh prompt kịp thời, tránh trường hợp agent báo lỗi "tool không tồn tại" giữa buổi làm việc.

Chạy Log Search và Metric Aggregation Từ Gemini CLI

Với Gemini CLI, cách đặt câu hỏi hiệu quả nhất là nêu rõ mục tiêu phân tích trước khi liệt kê chi tiết kỹ thuật — model của Google có xu hướng phản hồi tốt với prompt có cấu trúc rõ ràng về "mục tiêu → ràng buộc → định dạng đầu ra".

Ví dụ log search:

Mục tiêu: tìm nguyên nhân tại sao job "daily-report-generator" thất bại đêm qua.
Ràng buộc: chỉ tìm trong service report-worker, time range 00:00-06:00 UTC hôm nay.
Định dạng: liệt kê tối đa 3 log lỗi khác nhau, mỗi log kèm timestamp và message đầy đủ.

Ví dụ metric aggregation — tổng hợp một metric theo nhiều dimension để tìm outlier:

Mục tiêu: tìm pod nào trong service report-worker tiêu tốn CPU nhiều bất thường.
Ràng buộc: query metric avg:kubernetes.cpu.usage.total{service:report-worker},
group by pod_name, time range 6 giờ qua.
Định dạng: xếp hạng top 5 pod theo CPU trung bình, kèm % chênh lệch so với
trung bình toàn service.

Gemini CLI sẽ gọi query_metrics với tham số group_by: ["pod_name"], rồi tự tính phần trăm chênh lệch trong câu trả lời — một việc tốn thời gian nếu bạn phải tự export data và tính bằng tay.

Mẹo: Với các câu hỏi cần group-by nhiều chiều, luôn nêu rõ chiều group trong phần "Ràng buộc" của prompt — nếu để agent tự chọn, nó có thể group theo chiều mặc định (thường là service) thay vì chiều bạn thực sự cần (như pod_name hay availability_zone), dẫn đến kết quả không trả lời đúng câu hỏi gốc.

Ví Dụ Thực Tế: Xác Định Service Gây Ra Error Rate Spike

Đây là kịch bản điều tra kinh điển: một spike error rate xuất hiện ở tầng gateway, nhưng root cause thực sự nằm ở một service downstream sâu hơn.

Gateway API có error rate 5xx tăng từ 0.1% lên 6% trong 20 phút qua. Điều tra
theo các bước: (1) lấy top 10 trace chậm nhất hoặc lỗi nhất đi qua gateway
trong khoảng thời gian này, (2) với mỗi trace, xác định service downstream
cuối cùng trả lỗi (không phải service đầu tiên nhận request), (3) tổng hợp
xem service downstream nào xuất hiện nhiều nhất trong các trace lỗi.

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

Trong 10 trace lỗi được phân tích:
- 8/10 trace có lỗi cuối cùng xảy ra tại service "recommendation-engine"
  (lỗi: "upstream connect error, timeout")
- 2/10 trace lỗi tại service "user-profile-service" (không liên quan)

=> recommendation-engine gần như chắc chắn là root cause. Gateway chỉ đang
"phản chiếu" lỗi 5xx từ service này lên phía client.

Gợi ý tiếp theo: kiểm tra CPU/memory hoặc connection pool của
recommendation-engine trong cùng khoảng thời gian.

Điểm quan trọng ở đây là agent phân biệt được "service đầu tiên nhận request" (gateway — nơi bạn thấy alert) và "service thực sự gây lỗi" (recommendation-engine, nằm sâu trong chuỗi gọi) — đây chính xác là việc con người dễ mất thời gian nhất khi debug hệ thống microservices nhiều tầng.

Mẹo: Khi hỏi về root cause trong hệ thống nhiều tầng, luôn yêu cầu agent phân tích ở mức trace/span (chi tiết từng lời gọi downstream) thay vì chỉ ở mức service metric tổng hợp — metric tổng hợp dễ khiến bạn kết luận nhầm service đang hiển thị lỗi nhiều nhất chính là nguồn gốc vấn đề.

So Sánh Kết Quả Datadog MCP Giữa Gemini CLI và Claude Code

Nếu team bạn dùng song song cả hai client (điều khá phổ biến khi các thành viên có sở thích khác nhau), có vài khác biệt thực tế đáng lưu ý khi cùng làm việc với Datadog MCP:

  • Độ chi tiết khi trình bày kết quả trace. Claude Code có xu hướng trình bày span breakdown dạng cây phân cấp rõ ràng theo mặc định; Gemini CLI thường cần bạn yêu cầu rõ định dạng ("trình bày dạng cây, thụt lề theo parent-child span") mới cho kết quả tương đương.
  • Cách xử lý khi tool trả lỗi. Với lỗi 429 (rate limit), Claude Code thường tự đề xuất chờ và retry với backoff; Gemini CLI có xu hướng báo lỗi trực tiếp cho bạn và chờ chỉ dẫn tiếp theo — không tự động retry.
  • Độ dài context giữ được trong phiên dài. Với phiên điều tra kéo dài nhiều bước (10+ lượt hỏi-đáp), cả hai đều có thể "quên" chi tiết dữ liệu thô ở đầu phiên; nhưng thời điểm bắt đầu suy giảm khác nhau tuỳ giới hạn context window của model đang dùng.
  • Cách diễn giải timestamp. Cần verify cả hai client đều hiểu đúng timezone bạn ngụ ý — mặc định Datadog trả timestamp theo UTC, nhưng cách agent "làm tròn" hoặc diễn giải "1 giờ qua" có thể lệch nhẹ giữa hai client.

Không có client nào "tốt hơn" tuyệt đối — sự khác biệt chủ yếu nằm ở model nền tảng và cách mỗi client xử lý tool-calling loop. Với team dùng cả hai, khuyến nghị thực tế là chuẩn hoá prompt template chung (ràng buộc rõ time range, service, định dạng output) để giảm sự khác biệt do "phong cách" trả lời riêng của từng model.

Mẹo: Nếu một điều tra quan trọng cho kết luận trái ngược giữa hai client, đừng vội tin bên nào — hãy tự verify trực tiếp trên Datadog UI với đúng query DQL mà cả hai đã dùng. Sự khác biệt thường xuất phát từ cách model diễn giải phạm vi câu hỏi, không phải do dữ liệu Datadog trả về sai.

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

Đúc kết lại các thực hành hiệu quả khi dùng Datadog MCP với Gemini CLI:

  • Tăng timeout trong config MCP server nếu bạn thường query dataset lớn, để tránh lỗi timeout giả (không phải do key/config sai).
  • Chạy /mcp desc datadog sau mỗi lần update package để nắm rõ tool schema hiện tại.
  • Dùng cấu trúc prompt "Mục tiêu → Ràng buộc → Định dạng" để tận dụng tốt khả năng theo chỉ dẫn có cấu trúc của model.
  • Luôn nêu rõ chiều group-by mong muốn khi phân tích metric đa chiều.
  • Khi so sánh kết quả với client khác, luôn verify lại bằng query DQL gốc trên Datadog UI trước khi đưa ra quyết định quan trọng.

Mẹo: Với các tổ chức dùng Google Workspace/Google Cloud làm hạ tầng chính, việc chuẩn hoá Gemini CLI cho các phiên phân tích quan sát hệ thống (observability) giúp giảm số lượng credential/tool cần quản lý — nhưng đừng ngại dùng thêm một client khác cho các case điều tra phức tạp cần khả năng reasoning mạnh hơn nếu bạn thấy Gemini CLI chưa đủ chính xác với case đó.

Tiếp Datadog MCP với Cursor