Tiếng Việt: Sentry MCP With Gemini Cli

Nếu bạn đã quen với việc dùng Claude Code để làm việc với Sentry MCP (Model Context Protocol — giao thức kết nối AI với công cụ/dữ liệu bên ngoài), thì tin vui là Gemini CLI — công cụ AI agent chạy trên terminal do Google phát triển, dùng mã nguồn mở và chạy nền tảng model Gemini — cũng hỗ trợ MCP theo một cách gần như tương đương. Bài này sẽ đi sâu vào cách cài đặt, cấu hình, và sử dụng Sentry MCP bên trong Gemini CLI để triage (phân loại, ưu tiên xử lý) issue (lỗi được Sentry ghi nhận), phân tích root cause (nguyên nhân gốc rễ), và cuối bài sẽ so sánh trực tiếp trải nghiệm này với Claude Code.

Mục tiêu của bài là giúp bạn — dù là Engineer, QA, BA hay Product Manager — có thể tự tay cấu hình Gemini CLI để "nói chuyện" với Sentry, và biết cách đặt câu hỏi đúng để lấy được thông tin hữu ích nhất từ AI agent, thay vì phải tự tay đọc từng dòng log.

Installing and Connecting Sentry MCP to Gemini CLI

Gemini CLI đọc cấu hình MCP server từ file settings.json, có thể đặt ở hai cấp:

• Cấp user (áp dụng cho mọi project): ~/.gemini/settings.json
• Cấp project (chỉ áp dụng cho project hiện tại, nên ưu tiên dùng cấp này khi làm việc nhóm): .gemini/settings.json nằm ngay tại thư mục gốc repo.

Cấu trúc khai báo MCP server trong Gemini CLI khá giống với .mcp.json của Claude Code — cùng dùng khối mcpServers, cùng hỗ trợ kết nối qua HTTP URL hoặc chạy local qua command/args. Với Sentry MCP, cách đơn giản và được khuyến nghị nhất là dùng remote MCP server chính thức của Sentry qua HTTP:

{
  "mcpServers": {
    "sentry": {
      "httpUrl": "https://mcp.sentry.dev/mcp",
      "headers": {
        "Authorization": "Bearer $SENTRY_AUTH_TOKEN"
      }
    }
  }
}

Vài điểm cần lưu ý khi cấu hình:

• Biến môi trường (env var): Gemini CLI hỗ trợ cú pháp $VAR_NAME hoặc ${VAR_NAME} bên trong giá trị string của settings.json, và sẽ tự động thay thế bằng giá trị thực khi khởi động phiên làm việc. Bạn nên export SENTRY_AUTH_TOKEN (auth token — mã xác thực dùng để chứng minh quyền truy cập API) trong shell profile (.bashrc, .zshrc) hoặc dùng file .env ở project root thay vì hard-code token thẳng vào file JSON — vì file này thường được commit vào git.
• Auth token lấy ở đâu: vào Sentry → Settings → Auth Tokens, tạo token mới với scope tối thiểu cần thiết (thường là event:read, project:read, org:read). Một số bản Sentry MCP hosted server hỗ trợ luôn flow OAuth (giao thức ủy quyền chuẩn, cho phép cấp quyền mà không cần chia sẻ mật khẩu trực tiếp) — khi đó lần đầu gọi tool, Gemini CLI sẽ tự mở trình duyệt để bạn đăng nhập và cấp quyền, không cần tạo token thủ công.
• Kiểm tra kết nối bằng lệnh /mcp: sau khi cấu hình xong, chạy gemini để vào phiên làm việc, rồi gõ /mcp ngay trong CLI. Lệnh này liệt kê toàn bộ MCP server đã cấu hình, trạng thái kết nối (connected/failed), và danh sách tool mà server đó expose ra (ví dụ find_issues, get_issue_details, search_events...). Nếu thấy trạng thái lỗi, thường là do token sai, hết hạn, hoặc network/firewall chặn outbound HTTPS.
• Cờ trust: trong khai báo server, bạn có thể thêm "trust": true. Khi bật, Gemini CLI sẽ tự động approve (chấp thuận) mọi lời gọi tool từ server đó mà không hỏi lại bạn — tiện cho việc chạy nhanh, nhưng đánh đổi là rủi ro bảo mật: nếu Sentry MCP server (hoặc một prompt injection nào đó từ dữ liệu issue) cố gắng gọi tool có khả năng ghi dữ liệu (ví dụ update issue status, resolve issue), bạn sẽ không có cơ hội chặn lại theo thời gian thực. Với MCP server chỉ đọc dữ liệu (read-only) như hầu hết các tool triage của Sentry, bật trust tương đối an toàn; nhưng nếu server có tool ghi/xóa, nên để mặc định false để mỗi lời gọi đều cần bạn xác nhận thủ công.

{
  "mcpServers": {
    "sentry": {
      "httpUrl": "https://mcp.sentry.dev/mcp",
      "headers": {
        "Authorization": "Bearer $SENTRY_AUTH_TOKEN"
      },
      "trust": false
    }
  }
}

Mẹo: Nếu bạn làm việc trên nhiều project Sentry (nhiều org/project slug khác nhau), hãy đặt cấu hình MCP ở cấp project (.gemini/settings.json) thay vì cấp user, và ghi rõ default project trong system prompt hoặc file GEMINI.md ở root — tránh việc Gemini CLI hỏi lại "bạn muốn issue của project nào" mỗi lần bạn đặt câu hỏi.

Using Sentry MCP Tools for Error Triage and Analysis in Gemini CLI

Sau khi kết nối thành công, Gemini CLI có thể gọi trực tiếp các tool MCP mà Sentry expose để phục vụ triage — công việc lọc, phân loại, và ưu tiên xử lý issue mới phát sinh. Điểm mạnh của việc dùng agent ở đây là bạn không cần nhớ cú pháp query của Sentry Discover hay tự viết filter phức tạp — chỉ cần mô tả bằng ngôn ngữ tự nhiên.

Liệt kê issue theo tần suất và số user bị ảnh hưởng

Prompt ví dụ:

Liệt kê 10 issue chưa resolved có số lượng event nhiều nhất trong 7 ngày qua ở project "checkout-service", sắp xếp theo số user bị ảnh hưởng giảm dần.

Gemini CLI sẽ phân tích yêu cầu, quyết định gọi tool tương ứng (thường là find_issues hoặc search_issues tùy phiên bản Sentry MCP), truyền tham số project, khoảng thời gian, trạng thái is:unresolved, và sort order. Trước khi gọi, nếu trust chưa bật, CLI sẽ hiện khối xác nhận dạng:

Gemini muốn gọi tool: sentry.find_issues
Tham số: { "project": "checkout-service", "query": "is:unresolved", "sort": "user", "period": "7d", "limit": 10 }
Cho phép thực thi? (y/n/a)

Kết quả trả về thường được Gemini tóm tắt lại dạng bảng, kiểu:

Lọc theo environment (production vs staging)

Prompt ví dụ:

So sánh top 5 issue mới nhất giữa environment production và staging của project "checkout-service" trong 24 giờ qua. Issue nào chỉ xuất hiện ở production mà không có ở staging thì đánh dấu riêng.

Ở đây Gemini CLI thường gọi tool tìm issue hai lần (một lần với filter environment:production, một lần environment:staging), rồi tự làm phép so sánh tập hợp (set diff) trong phần suy luận của model, không cần thêm tool riêng cho việc so sánh. Đây là điểm mạnh của cách tiếp cận "agent + tool" — logic so sánh nằm ở tầng reasoning (suy luận) của LLM (mô hình ngôn ngữ lớn), tool chỉ đóng vai trò lấy dữ liệu thô.

Tóm tắt issue mới sau một đợt deploy

Đây là workflow rất thực tế cho các đội DevOps/QA sau mỗi lần release:

Vừa deploy release v2.14.0 lên production cách đây 2 giờ. Tóm tắt tất cả issue mới xuất hiện lần đầu (first seen) sau thời điểm deploy, nhóm theo mức độ nghiêm trọng (level: error/warning), và chỉ ra issue nào có khả năng liên quan trực tiếp đến release này.

Gemini CLI sẽ gọi tool lấy danh sách issue với filter firstSeen sau mốc thời gian deploy, đối chiếu với tag release gắn trên từng issue, rồi tổng hợp lại thành báo cáo dạng gạch đầu dòng — ví dụ liệt kê 3 issue mới, mô tả ngắn gọn nguyên nhân nghi ngờ dựa trên message lỗi và breadcrumb (dấu vết các bước hành động của user/hệ thống trước khi lỗi xảy ra) đi kèm.

Mẹo: Khi hỏi Gemini CLI về "issue liên quan đến release", hãy luôn nêu rõ version/tag của release trong prompt — Sentry gắn tag release theo string chính xác, nếu bạn chỉ nói chung chung "bản mới nhất", model có thể chọn nhầm release trước đó do dữ liệu trả về từ tool không tự nó biết version nào là "mới nhất" theo ngữ cảnh business của bạn.

Practical Example: Root Cause Analysis with Gemini CLI and Sentry MCP

Hãy đi qua một tình huống thực tế từ đầu đến cuối: một error tăng đột biến (spike) ngay sau khi release, và bạn cần xác định root cause analysis (phân tích nguyên nhân gốc rễ) rồi đề xuất fix.

Bối cảnh: Team vừa deploy release v3.8.2 lúc 14:00. Đến 14:45, dashboard Sentry báo OrderValidationError tăng từ trung bình 5 event/giờ lên 480 event/giờ.

Bước 1 — Yêu cầu Gemini CLI lấy chi tiết issue kèm stack trace:

Lấy chi tiết issue "OrderValidationError" trong project "order-service", bao gồm stack trace (dấu vết ngăn xếp gọi hàm khi lỗi xảy ra) đầy đủ, breadcrumb, và tag release của 5 event gần nhất.

Gemini CLI gọi tool get_issue_details (hoặc tương đương), trả về dữ liệu thô, sau đó tóm tắt:

Issue: OrderValidationError
Xuất hiện lần đầu: 14:03 (3 phút sau khi release v3.8.2 lên production)
Stack trace (rút gọn):

  File "order_service/validators.py", line 88, in validate_discount_code
    discount_value = promo["value"] * item.quantity
  KeyError: 'value'

Breadcrumb gần nhất trước lỗi: gọi API GET /promotions/{code}, response trả về object promo
không có field "value" đối với mã khuyến mãi loại "percentage".

Bước 2 — Yêu cầu so sánh diff giữa release cũ và mới:

So sánh code diff của file validators.py giữa release v3.8.1 và v3.8.2. Có thay đổi nào liên quan đến cách xử lý field "value" trong object promo không?

Nếu Gemini CLI có quyền truy cập repo local (qua file system tool đi kèm, không phải MCP của Sentry) hoặc bạn dán trực tiếp đoạn diff vào, Gemini có thể đối chiếu và trả lời kiểu:

Trong v3.8.2, hàm validate_discount_code() được refactor để hỗ trợ thêm loại mã giảm giá
theo phần trăm ("percentage"). Đoạn code cũ luôn giả định object promo có field "value"
(áp dụng cho loại giảm giá cố định "fixed_amount"), nhưng logic mới chưa cập nhật field
tương ứng cho loại "percentage" — API trả về field "percent_off" thay vì "value" trong
trường hợp này, dẫn tới KeyError.

Bước 3 — Yêu cầu đề xuất fix:

Đề xuất cách sửa lỗi này, ưu tiên fix an toàn, không phá vỡ logic đã áp dụng cho loại "fixed_amount".

Gemini CLI phân tích logic và đề xuất, ví dụ:

def validate_discount_code(promo, item):
    if promo["type"] == "percentage":
        discount_value = (promo["percent_off"] / 100) * item.price * item.quantity
    else:
        discount_value = promo["value"] * item.quantity
    return discount_value

Kèm giải thích: dùng promo["type"] để rẽ nhánh xử lý đúng field tương ứng, tránh việc code giả định cấu trúc dữ liệu cố định trong khi API đã mở rộng thêm loại mã giảm giá mới. Đồng thời gợi ý thêm: nên viết unit test cho cả hai loại discount, và cân nhắc validate schema của response từ API /promotions ở tầng gọi API thay vì để lỗi rơi xuống tầng business logic.

Toàn bộ luồng trên — từ lấy issue, đọc stack trace, đối chiếu code diff, đến đề xuất fix — chỉ cần 3 prompt tự nhiên, không cần bạn tự tay vào Sentry dashboard hay tự đọc từng dòng log.

Mẹo: Khi phân tích root cause với AI agent, luôn yêu cầu model trích dẫn đúng dòng code/stack trace cụ thể trong câu trả lời (thay vì chỉ nói chung chung "có lỗi logic ở validator"). Việc này vừa giúp bạn verify lại nhanh, vừa giảm rủi ro model "bịa" (hallucinate) nguyên nhân không khớp với dữ liệu thực tế.

Comparing Sentry MCP Output Between Gemini CLI and Claude Code

Cả Gemini CLI và Claude Code đều hỗ trợ MCP theo chuẩn chung, và về mặt lý thuyết có thể gọi đúng cùng một bộ tool từ Sentry MCP server. Nhưng trải nghiệm thực tế khi dùng có một số khác biệt đáng chú ý mà bạn nên biết trước khi chọn công cụ cho workflow triage của team.

Nhìn chung, nếu team bạn cần một công cụ nhanh, gọn, chạy tốt cho các câu hỏi triage lặp đi lặp lại hằng ngày (kiểm tra issue mới, so sánh environment), Gemini CLI là lựa chọn hợp lý và tiết kiệm. Nếu công việc đòi hỏi phân tích sâu, nhiều bước, cần giải thích rõ ràng cho một báo cáo root cause analysis chính thức để gửi cho stakeholder, Claude Code hiện tại cho trải nghiệm ổn định và chi tiết hơn một chút, nhất là với các phiên làm việc dài cần giữ nguyên ngữ cảnh stack trace phức tạp.

Mẹo: Không nhất thiết phải chọn một trong hai. Nhiều team dùng Gemini CLI cho việc triage nhanh hằng ngày (chi phí thấp, tốc độ cao), rồi chuyển sang Claude Code khi cần đào sâu root cause cho một incident nghiêm trọng — tận dụng đúng điểm mạnh của từng công cụ thay vì ép cả team dùng một công cụ duy nhất cho mọi tình huống.