Giới thiệu

Trong bài viết trước, chúng ta đã khám phá lý do tại sao việc quan sát Kubernetes yêu cầu cả OpenTelemetry (OTel) và Prometheus. Cả hai tạo thành một nền tảng mạnh mẽ cho việc giám sát các khối lượng công việc hiện đại, nhưng chỉ khi những khối lượng công việc đó cung cấp telemetry. Vậy điều gì xảy ra khi chúng không làm được điều đó?

Đó chính xác là trường hợp của nhiều máy chủ Model Context Protocol (MCP). Những máy chủ này chạy các khối lượng công việc quan trọng nhưng hiếm khi cung cấp các chỉ số hoặc tích hợp với các khung quan sát. Đối với các nhóm vận hành, chúng hoạt động như những chiếc hộp đen; bạn thấy yêu cầu đi vào và phản hồi ra ngoài, nhưng không có thông tin gì về những gì đang xảy ra bên trong.

ToolHive đã được xây dựng để giảm thiểu khoảng trống này. Chạy natively bên trong Kubernetes, ToolHive hoạt động như một proxy thông minh thu thập các thống kê sử dụng từ các máy chủ MCP mà không cần phải sửa đổi các máy chủ đó. Sau đó, nó liên tục cung cấp dữ liệu đó vào ngăn xếp OTel + Prometheus hiện tại của bạn, cho bạn các bảng điều khiển, cảnh báo và thông tin đáng tin cậy giống như những gì bạn phụ thuộc vào cho các khối lượng công việc khác.

Tóm tắt: Vấn Đề Quan Sát MCP

Vấn đề cốt lõi là sự không khớp giữa các tiêu chuẩn quan sát hiện đại và thực tế vận hành của nhiều máy chủ MCP. Trong khi Prometheus mong đợi thu thập từ một điểm cuối /metrics và OTel mong đợi dữ liệu được đẩy từ các ứng dụng đã được instrumented, nhiều máy chủ MCP không làm cả hai điều này. Chúng được thiết kế cho một mục đích duy nhất: cung cấp khả năng chuyên biệt cho các hệ thống AI bằng cách kết nối các mô hình với thế giới thực. Telemetry vận hành thường là một suy nghĩ phụ, nếu nó được xem xét một cách nào đó.

Việc thiếu các chỉ số khiến bạn không thể trả lời những câu hỏi cơ bản nhưng rất quan trọng: Máy chủ MCP của tôi xử lý bao nhiêu yêu cầu mỗi giây? Thời gian trễ trung bình của các cuộc gọi công cụ là bao nhiêu? Máy chủ có gặp lỗi hoặc thời gian chờ không? Máy chủ đang tiêu tốn bao nhiêu CPU và bộ nhớ?

Không có dữ liệu này, bạn đang hoạt động trong tình trạng mù mờ, không thể tối ưu hóa hiệu suất, khắc phục sự cố hoặc đảm bảo tính đáng tin cậy của các ứng dụng AI của mình.

Cách ToolHive Thu Thập Chỉ Số

Cách tiếp cận của ToolHive rất đơn giản: thay vì dựa vào các máy chủ MCP để cung cấp các chỉ số của chúng, nó bọc chúng lại và hoạt động như một trung gian cho tất cả các yêu cầu từ khách hàng. ToolHive chạy cùng với các máy chủ MCP trong Kubernetes và quan sát hoạt động của chúng trực tiếp tại lớp tổ chức.

Khi các yêu cầu và phản hồi chảy qua ToolHive, nó quan sát và ghi lại các điểm dữ liệu vận hành quan trọng: số lượng yêu cầu và tỷ lệ, thời gian trễ và thời gian phản hồi, mã lỗi và trạng thái, cũng như thống kê sử dụng công cụ. Nó cũng tạo ra các trace phân tán cho mỗi tương tác MCP, cung cấp khả năng quan sát toàn diện vào các luồng yêu cầu. Bằng cách chặn dữ liệu yêu cầu và sử dụng, ToolHive có thể đo lường khối lượng yêu cầu, thời gian trễ và tỷ lệ lỗi trong khi gán các chỉ số cho các máy chủ hoặc khối lượng công việc MCP cụ thể.

Cách tiếp cận này tách biệt quan sát khỏi chính máy chủ MCP. Việc không cần sửa đổi máy chủ có nghĩa là các máy chủ MCP hiện tại hoạt động ngay lập tức mà không cần thay đổi mã hoặc phụ thuộc thêm. Nhận thức về giao thức cho phép ToolHive hiểu các hoạt động cụ thể của MCP như các cuộc gọi công cụ và yêu cầu tài nguyên, cung cấp các chỉ số mà các proxy chung không thể ghi nhận. Việc triển khai native trên Kubernetes có nghĩa là nó tích hợp một cách tự nhiên với dịch vụ phát hiện và các mẫu mở rộng.

Vì ToolHive được xây dựng với OTel và Prometheus trong tâm trí, nó tạo ra và cung cấp cả chỉ số và trace trong các định dạng mà ngăn xếp giám sát hiện tại của bạn có thể tiêu thụ ngay lập tức, chuẩn hóa dữ liệu vào các định dạng OTel và Prometheus tiêu chuẩn.

Bốn Kiến Trúc Hỗ Trợ

ToolHive được thiết kế để linh hoạt và có thể tích hợp vào nhiều thiết lập quan sát khác nhau. Nó hỗ trợ bốn kiến trúc chính để cung cấp dữ liệu cho pipeline của bạn:

Kiến Trúc 1 (Được Khuyến Nghị): ToolHive → OTel Collector ← Prometheus ToolHive đẩy cả chỉ số và trace đến một bộ thu thập OpenTelemetry bằng cách sử dụng OTLP (Giao thức OpenTelemetry). Bộ thu thập này cung cấp một điểm cuối /metrics mà Prometheus thu thập dữ liệu chỉ số, trong khi các trace được xuất đến backend tracing của bạn (như Jaeger hoặc Tempo). Đây là một kiến trúc mạnh mẽ và có thể mở rộng, tập trung hóa việc thu thập và xử lý dữ liệu trong khi tận dụng độ tin cậy dựa trên pull của Prometheus.

Kiến Trúc 2: ToolHive → OTel Collector → Prometheus (RemoteWrite) Tương tự như Kiến trúc 1, ToolHive đẩy chỉ số và trace đến bộ thu thập OTel. Bộ thu thập xuất các trace đến backend tracing của bạn và sử dụng bộ xuất Prometheus RemoteWrite để đẩy chỉ số trực tiếp đến máy chủ Prometheus. Điều này giảm thiểu gánh nặng thu thập nhưng có thể mất dữ liệu nếu Prometheus không khả dụng khi xảy ra đẩy.

Kiến Trúc 3: ToolHive ← Prometheus (Thu Thập Trực Tiếp) ToolHive cung cấp một điểm cuối /metrics riêng cho Prometheus thu thập, trong khi các trace vẫn được đẩy đến bộ thu thập OTel để xuất đến các backend tracing. Đây là thiết lập đơn giản nhất để thu thập chỉ số nhưng yêu cầu cấu hình riêng cho việc xuất trace.

Kiến Trúc 4: Kết Hợp Cách tiếp cận này tối đa hóa tính linh hoạt: ToolHive đẩy trace đến bộ thu thập OTel (mà xuất đến các backend tracing) trong khi cung cấp một điểm cuối /metrics mà Prometheus thu thập trực tiếp. Điều này cung cấp khả năng quan sát toàn diện nhưng tăng thêm độ phức tạp vận hành.

Tại Sao Chúng Tôi Khuyến Nghị Kiến Trúc 1

Mặc dù cả bốn kiến trúc đều hợp lệ, Kiến trúc 1 đại diện cho thực hành tốt nhất cho hầu hết các môi trường Kubernetes hiện đại. Nó đạt được sự cân bằng đúng đắn cho hầu hết các triển khai Kubernetes bằng cách cung cấp một số lợi ích chính:

Tập Trung và Chuẩn Hóa: Nó tập trung cả chỉ số và trace trong một pipeline duy nhất, làm cho việc quản lý, làm giàu và chuyển hướng đến các backend khác dễ dàng hơn. Đối với các tổ chức đã sử dụng bộ thu thập OTel cho các dịch vụ khác, kiến trúc này duy trì tính nhất quán trong toàn bộ ngăn xếp giám sát.

Độ Tin Cậy: Mô hình dựa trên pull của Prometheus vốn đã đáng tin cậy cho các chỉ số. Bộ thu thập OTel hoạt động như một bộ đệm đáng tin cậy giữa ToolHive và cả Prometheus cũng như các backend tracing, xử lý các vấn đề mạng tạm thời hoặc tính không khả dụng một cách nhẹ nhàng. Nếu Prometheus đang tạm ngừng bảo trì, nó có thể bắt kịp bằng cách thu thập khi nó trở lại trực tuyến, thay vì mất dữ liệu mà lẽ ra đã được đẩy trong thời gian ngừng hoạt động.

Tính Linh Hoạt: Bộ thu thập OTel có thể xử lý và xuất cả chỉ số và trace đến bất kỳ số lượng đích nào. Đối với chỉ số, điều này bao gồm Prometheus, lưu trữ lâu dài hoặc các nền tảng phân tích. Đối với trace, nó có thể chuyển hướng đến Jaeger, Tempo hoặc các backend tracing khác. Nó có thể thêm nhãn, thực hiện các biến đổi và chuyển hướng dữ liệu đến nhiều backend nếu cần, tránh việc bị lock-in vào nhà cung cấp.

ToolHive Trong Thực Tế: Chỉ Số và Trace Thực Tế Từ Các Máy Chủ MCP

Khi bạn đã triển khai ToolHive và cấu hình nó để làm việc với ngăn xếp OTel + Prometheus của bạn, các bảng điều khiển của bạn sẽ được cập nhật với cả chỉ số và trace cung cấp cái nhìn ngay lập tức về hoạt động của máy chủ MCP:

Chỉ Số Yêu Cầu bao gồm các bộ đếm (toolhive_mcp_requests_total) cho tổng số yêu cầu và toolhive_mcp_request_duration_seconds_* histogram hiển thị độ trễ p95 và p99, phân loại theo máy chủ MCP và loại hoạt động. Điều này giúp xác định các mẫu sử dụng và xu hướng hiệu suất trên cơ sở hạ tầng MCP của bạn.

Thống Kê Sử Dụng Công Cụ theo dõi các công cụ MCP nào đang được gọi thường xuyên nhất với toolhive_mcp_tool_calls_total (bộ đếm cho các lần gọi công cụ cụ thể), tỷ lệ thành công cho các loại công cụ khác nhau, và mẫu sử dụng theo thời gian. Dữ liệu này vô cùng quý giá cho việc hiểu cách các hệ thống AI tương tác với các máy chủ MCP của bạn và những khả năng nào là quan trọng nhất.

Trace Phân Tán cho thấy hành trình hoàn chỉnh của các yêu cầu MCP, từ khởi tạo khách hàng qua xử lý ToolHive đến phản hồi máy chủ. Mỗi trace bao gồm thông tin thời gian cho các giai đoạn khác nhau của tương tác MCP, giúp xác định các nút thắt cổ chai và hiểu được các mẫu luồng yêu cầu. Các trace được liên kết với các chỉ số thông qua các ID trace và span, cho phép quy trình khắc phục sự cố mạnh mẽ.

Tất cả các chỉ số đều bao gồm các nhãn Kubernetes chuẩn cho namespace, pod và dịch vụ, giúp dễ dàng tổng hợp và lọc dữ liệu trong các bảng điều khiển hiện có. Đây là các chỉ số và trace bạn cần để xây dựng các bảng điều khiển có ý nghĩa, thiết lập các cảnh báo quan trọng và thực sự hiểu sức khỏe và hiệu suất của các khối lượng công việc MCP của bạn. Dữ liệu quan sát tích hợp một cách liền mạch với các quy tắc cảnh báo, cho phép các nhóm thiết lập thông báo cho các vấn đề cụ thể của MCP như tỷ lệ lỗi công cụ hoặc các mẫu sử dụng bất thường.

Kêu Gọi Hành Động: Thử ToolHive / Tham Gia Cộng Đồng

Khoảng trống quan sát MCP không cần phải là điều hiển nhiên. Với ToolHive, các nhóm vận hành có thể có được cái nhìn quan trọng vào các khối lượng công việc AI của bạn mà không phải chờ đợi các thay đổi phía máy chủ hoặc hỗ trợ telemetry từ upstream. Bằng cách hỗ trợ nhiều kiến trúc - và khuyến nghị một cách tiếp cận thực hành tốt nhất - ToolHive giúp việc giám sát các máy chủ MCP trở thành một phần của một pipeline OTel + Prometheus tiêu chuẩn.

Dự án đang được phát triển tích cực và chào đón ý kiến đóng góp từ cộng đồng. Dù bạn đang chạy một máy chủ MCP đơn lẻ hay quản lý hàng chục máy chủ trên nhiều cụm, ToolHive có thể cung cấp cái nhìn mà bạn cần để hoạt động một cách tự tin. Hãy kiểm tra ToolHive và kết nối với chúng tôi trên Discord.

Sẵn sàng để thấy nó hoạt động không? Trong bài viết tiếp theo, chúng tôi sẽ hướng dẫn bạn cách triển khai ToolHive trong Kubernetes, bao gồm các biểu đồ Helm, các bước kubectl và một bảng điều khiển Grafana khởi động.

Nếu bạn đã bỏ lỡ các bài viết trước trong chuỗi này, hãy chắc chắn kiểm tra: Bài viết 1: Thách Thức Quan Sát Tiếp Theo: OTel, Prometheus và Các Máy Chủ MCP Trong Kubernetes