Như đã đề cập ở Phần 5, lỗ hổng MCP08 (Thiếu Audit & Telemetry) là một trong những rủi ro lớn nhất của hệ thống Agentic. Trong AI Driven Playbook, chúng ta đã thống nhất rằng: Khi AI tự động hóa các tác vụ thay con người, yêu cầu về khả năng quan sát (Observability) và truy vết (Auditing) trở nên khắt khe hơn bao giờ hết, đặc biệt dưới sức ép của các đạo luật như EU AI Act.

Bài viết này hướng dẫn cách thiết lập một hệ thống Observability chuẩn mực cho MCP Server.

1. Ba Trụ Cột Telemetry Cho MCP

Chúng ta không dùng fmt.Println() để debug MCP (điều này sẽ phá vỡ giao thức nếu chạy qua stdio như đã nói ở Phần 2). Thay vào đó, mọi dữ liệu telemetry phải được cấu trúc hóa (structured) và xuất qua OpenTelemetry (OTel). Tư duy này rất quen thuộc nếu bạn đã học qua AI Driven Engineer.

A. Structured Logging (Log có cấu trúc)

Logs không chỉ là chuỗi văn bản. Chúng phải là JSON chứa metadata (siêu dữ liệu). Mỗi dòng log của MCP Server phải trả lời được:

  • Ai gọi? (agent_id, client_name)
  • Gọi công cụ gì? (tool_name)
  • ID của request là gì? (mcp_request_id)
  • Trạng thái? (status: success/failed/rate_limited)

B. Metrics (Chỉ số đo lường)

Metrics giúp bạn phát hiện sự bất thường về hành vi (Behavioral Anomalies) của Agent. Các metrics quan trọng cần theo dõi:

  • mcp_tool_invocation_total: Số lần gọi một tool. Nếu tool delete_database tự nhiên tăng vọt, bạn có một Prompt Injection đang diễn ra.
  • mcp_request_duration_seconds: Thời gian xử lý.
  • mcp_payload_size_bytes: Kích thước payload. Context Window bị phình to thường bắt nguồn từ việc một Tool trả về quá nhiều dữ liệu rác.

C. Distributed Tracing (Truy vết phân tán)

Đây là phần khó nhất nhưng giá trị nhất. Một “suy nghĩ” (thought) của LLM có thể dẫn đến 5 lời gọi MCP Tool liên tiếp, phân tán trên 3 MCP Server khác nhau. Nếu không có Correlation ID (ID tương quan), bạn sẽ thấy các log rời rạc và không thể biết chúng thuộc về cùng một luồng suy luận của Agent. Gateway phải inject trace_id vào header của mọi request gửi xuống MCP Server.

sequenceDiagram
    participant Agent as AI Agent
    participant Gateway as MCP Gateway
    participant S1 as Server 1 (Jira)
    participant S2 as Server 2 (GitHub)

    Agent->>Gateway: 1. Request: "Review bug #123"
    Note over Gateway: Sinh Trace_ID = XYZ-123
    Gateway->>S1: 2. Gọi Jira Tool [Trace_ID=XYZ-123]
    S1-->>Gateway: 3. Trả kết quả Issue
    Gateway->>S2: 4. Gọi GitHub Tool [Trace_ID=XYZ-123]
    S2-->>Gateway: 5. Trả PR diff
    Note over Gateway,S2: Toàn bộ logs trong hệ thống đều đính kèm Trace_ID XYZ-123

2. Tích Hợp SIEM và Audit Trail

Với các tổ chức Enterprise, việc đẩy logs lên Kibana hay Grafana là chưa đủ. Các log liên quan đến hành vi thay đổi hệ thống (như provision_server hay modify_user_role) phải được xem là Security Events (Sự kiện bảo mật).

Chúng cần được xuất thẳng vào các hệ thống SIEM (Security Information and Event Management) như Splunk, Datadog Security, hoặc Microsoft Sentinel.

Cấu trúc một Audit Log chuẩn:

{
  "timestamp": "2026-05-15T14:30:00Z",
  "event_type": "mcp_tool_execution",
  "actor": {
    "identity_type": "spiffe",
    "agent_id": "spiffe://example.com/agent/finance-bot/uuid-abc123",
    "user_context": "john.doe@company.com"
  },
  "action": {
    "server_name": "billing-mcp-server",
    "tool_name": "refund_customer",
    "arguments_hash": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"
  },
  "outcome": "success",
  "trace_id": "5b8aa5a2-c941-4775-b66f-3c6eb2d6a695"
}

Lưu ý: Không in log các tham số nhạy cảm (PII/Secrets) ở dạng plain text, hãy dùng arguments_hash.

3. Semantic Validation tại Gateway

Observability không chỉ để “nhìn lại quá khứ”. Nó có thể dùng để block request trong thời gian thực (Real-time).

Gateway của bạn có thể áp dụng Semantic Validation: Dựa trên metrics, nếu Gateway thấy một Agent đang liên tục gọi tool search_logs với các từ khóa thay đổi rất nhanh nhưng không ra kết quả, nó có thể nhận diện Agent đang bị mắc kẹt trong một vòng lặp suy luận vô tận (Infinite reasoning loop) và tự động cắt kết nối (Circuit Breaker) để tiết kiệm token cost.

Lời Kết

Observability biến “hộp đen” của AI thành một hệ thống minh bạch, có thể kiểm chứng (verifiable). Khi bạn đã có Gateway vững chắc, Security chặt chẽ và Observability đầy đủ, bước cuối cùng là mở rộng hệ thống này ra cho toàn bộ tập đoàn sử dụng.

Next up: Phần 7: Enterprise Scaling & Governance