MCP: Giao diện Quan sát Mới Kết nối AI Agents với Kernel Tracepoints

Trong tuần đầu tiên của tháng 3 năm 2026, ba sự kiện quan trọng đã định hình lại tương lai của khả năng quan sát (observability) trong ngành công nghệ. Datadog đã tung ra một MCP Server, Qualys đã đưa ra phân tích bảo mật về các máy chủ này, và Cloud Native Now đã bàn về eBPF cho mạng Kubernetes. Điểm mấu chốt kết nối tất cả các sự kiện này là: các tác nhân AI cần quyền truy cập trực tiếp vào dữ liệu hạ tầng, và MCP (Model Context Protocol) đang trở thành phương thức tiêu chuẩn để họ đạt được điều đó.

Hai cách tiếp cận với MCP Observability

Hiện tại, có hai hướng đi chính để kết nối dữ liệu quan sát với các tác nhân AI thông qua MCP.

Cách tiếp cận 1: Bao bọc các nền tảng hiện có. Đây là chiến lược mà Datadog đang áp dụng. Nó lấy các chỉ số (metrics), nhật ký (logs) và dấu vết (traces) đã được thu thập và tổng hợp, sau đó phơi bày chúng thông qua các công cụ của MCP. Tác nhân AI truy vấn API của bảng điều khiển (dashboard), nhận dữ liệu đã được xử lý trước và hành động dựa trên đó. Cách tiếp cận này phù hợp với các nhóm đã có một hệ thống quan sát trưởng thành và muốn thêm tính tự động hóa dựa trên AI lên trên.

Cách tiếp cận 2: Xây dựng khả năng quan sát tự nhiên (Native) cho MCP. Đây là hướng đi táo bạo hơn mà chúng tôi đã triển khai với công cụ truy xuất (tracer). Thay vì bao bọc một nền tảng hiện có, chúng tôi xây dựng một tác nhân eBPF để truy xuất trực tiếp các API CUDA Runtime và Driver thông qua uprobes, lưu trữ kết quả trong SQLite và phơi bày mọi thứ qua 7 công cụ MCP. Trong trường hợp này, giao diện MCP không phải là một lớp chuyển đổi (adapter), mà chính là giao diện chính.

Cách tiếp cận bao bọc hoạt động tốt cho phân tích tổng hợp, ví dụ: "Độ trễ p99 của dịch vụ X trong giờ qua là bao nhiêu?". Tuy nhiên, cách tiếp cận tự nhiên hiệu quả hơn trong việc điều tra nguyên nhân gốc rễ (root-cause investigation), ví dụ: "Tại sao yêu cầu GPU cụ thể này lại chậm hơn 14,5 lần so với dự kiến?". Điều này yêu cầu các sự kiện kernel thô, call stacks CUDA và chuỗi nhân quả – những thứ mà dữ liệu tổng hợp không thể cung cấp.

MCP Observability trong thực tế

Hãy xem xét một ví dụ cụ thể. Chúng tôi đã truy xuất một sự cố hồi quy TTFT (Time to First Token) của vLLM, nơi token đầu tiên mất nhiều thời gian hơn mức cơ sở. Cơ sở dữ liệu truy xuất đã ghi lại từng lệnh gọi API CUDA, từng lần chuyển đổi ngữ cảnh kernel và từng lần cấp phát bộ nhớ.

Khi Claude kết nối với MCP server và tải cơ sở dữ liệu này, nó có thể thực hiện các thao tác như:

• get_trace_stats: Xem tóm tắt truy xuất đầy đủ.
• get_causal_chains: Đọc các chuỗi nhân quả giải thích tại sao độ trễ tăng vọt.
• run_sql: Chạy truy vấn tùy chỉnh trên dữ liệu sự kiện thô.
• get_stacks: Kiểm tra call stacks cho bất kỳ sự kiện nào được gắn cờ.

Claude đã xác định nguyên nhân gốc rễ trong vòng dưới 30 giây: tính toán logprobs đang chặn vòng giải mã (decode loop), tạo ra sự chậm 256 lần trên đường dẫn quan trọng. Nguyên nhân gốc rễ này không hiển thị trong bất kỳ chỉ số tổng hợp nào; nó chỉ xuất hiện trong chuỗi nhân quả thô giữa các lệnh gọi API CUDA cụ thể. Một bộ điều hợp MCP dashboard thông thường sẽ không thể tìm thấy điều này.

Góc độ bảo mật

Qualys đã đưa ra những lo ngại chính đáng về bảo mật của MCP server. Họ phát hiện rằng hơn 53% máy chủ dựa vào các bí mật tĩnh (static secrets) để xác thực, một con số đáng báo động. Khuyến nghị của họ về việc ghi log các sự kiện khám phá và giám sát các mẫu gọi (invocation patterns) là hoàn toàn chính xác.

Đối với các MCP server tiếp xúc với hạ tầng GPU, bề mặt tấn công sẽ khác biệt. Một MCP server có quyền truy cập vào các dấu vết CUDA có thể phơi bày thông tin về thời gian, bố cục bộ nhớ và chi tiết kiến trúc mô hình. Mô hình bảo mật cần tính đến yếu tố này.

Trong dự án của chúng tôi, mọi lần gọi công cụ MCP đều được truy xuất. Cùng hạ tầng eBPF bắt các sự kiện GPU cũng bắt được chính sự tương tác MCP. Đây không phải là một lớp ghi log riêng biệt; nó là cùng một đường ống quan sát. Khi đó, khuyến nghị của Qualys về việc "thêm khả năng quan sát cho MCP servers" trở nên đơn giản vì chính máy chủ MCP đã là một công cụ quan sát.

Tương lai của mô hình này

Chúng tôi tin rằng mô hình MCP tự nhiên sẽ mở rộng ra ngoài khả năng quan sát GPU. Hãy cân nhắc các trường hợp sau:

• Quan sát mạng: Thay vì bao bọc Prometheus trong một lớp MCP, hãy xây dựng một tác nhân mạng dựa trên eBPF phơi bày dữ liệu cấp gói tin trực tiếp cho AI.
• Quan sát bảo mật: Thay vì bao bọc một SIEM, hãy xây dựng một MCP server truy xuất các syscalls và phơi bày sự kiện bảo mật theo thời gian thực.
• Quan sát chi phí: Thay vì truy vấn API tính tiền đám mây thông qua MCP, hãy đo lường việc cấp phát tài nguyên thực tế và phơi bày trực tiếp.

Mô hình chung ở đây là: bỏ qua bảng điều khiển, bỏ qua tổng hợp, hãy cấp cho tác nhân AI quyền truy cập trực tiếp vào dữ liệu đo đạc (telemetry) thô. Hãy để tác nhân quyết định những gì cần tổng hợp và cách thức thực hiện.

Thử nghiệm ngay

Dự án này là mã nguồn mở. Bạn có thể tải xuống cơ sở dữ liệu điều tra từ bài viết này và để Claude (hoặc bất kỳ máy khách MCP nào) kết nối để thực hiện điều tra.

Để bắt đầu, bạn có thể sử dụng Ollama hoặc Claude Desktop với cấu hình MCP phù hợp. MCP server phơi bày 7 công cụ và Claude sẽ tự động tìm ra cách sử dụng chúng để trả lời các câu hỏi như "Nguyên nhân gây ra sự cố hiệu suất GPU trong dấu vết này là gì?".

Đây là một bước tiến thú vị trong việc kết hợp AI với hạ tầng hệ thống sâu sắc, mang lại khả năng tự chẩn đoán và khắc phục sự cố ở cấp độ hạt nhân mà trước đây khó có thể thực hiện tự động.