Grafana ra mắt Kubernetes Monitoring Helm Chart v4: Bản cập nhật lớn nhất với nhiều sửa lỗi quan trọng

Grafana Labs đã phát hành phiên bản 4 của Kubernetes Monitoring Helm chart, mô tả đây là bản cập nhật quan trọng nhất mà biểu đồ này từng nhận được kể từ khi giới thiệu. Bản phát hành, được công bố vào tháng 4 năm 2026 bởi Pete Wall và Beverly Buchanan, giải quyết một loạt các vấn đề cấu hình đã tích tụ khi người người dùng mở rộng quy mô lên các triển khai lớn hơn và phức tạp hơn.

Kubernetes Monitoring Helm chart cung cấp cơ chế gửi chỉ số (metrics), nhật ký (logs), dấu vết (traces) và hồ sơ (profiles) từ các cụm Kubernetes đến Grafana Cloud hoặc ngăn xếp Grafana tự lưu trữ (self-hosted). Theo Wall và Buchanan, phiên bản 4 đại diện cho gần sáu tháng lập kế hoạch và phát triển, được thiết kế để giải quyết các vấn đề thực tế mà người dùng gặp phải khi thiết lập giám sát của họ phát triển. Các tác giả viết rằng biểu đồ giờ đây "dễ dự đoán hơn, linh hoạt hơn và dễ bảo trì hơn nhiều, dù bạn quản lý một cụm hay một trăm cụm."

"Đại diện cho gần sáu tháng lập kế hoạch và phát triển, nó được thiết kế để giải quyết các điểm đau thực tế mà người dùng gặp phải khi thiết lập giám sát của họ phát triển." — Pete Wall và Beverly Buchanan

Một trong những thay đổi cấu trúc có tác động lớn nhất là việc chuyển đổi đích (destinations) từ danh sách (list) sang bản đồ (map). Trong phiên bản 3, các đích được định nghĩa là danh sách các đối tượng. Điều này gây ra vấn đề cho các nhóm quản lý nhiều cụm với các tệp cấu hình dùng chung và cho những người sử dụng công cụ GitOps như Argo CD, Terraform hoặc Flux. Việc ghi đè một thuộc tính duy nhất, chẳng hạn như mật khẩu, yêu cầu tham chiếu đích theo vị trí của nó trong danh sách. Nếu thứ tự của các đích thay đổi, các ghi đè đó sẽ âm thầm áp dụng cho sai mục tiêu. Trong phiên bản 4, mỗi đích có một tên ổn định, vì vậy destinations.prometheus.auth.password luôn tham chiếu đến đích Prometheus bất kể thứ tự. Khả năng hợp nhất cấu hình dựa trên bản đồ của Helm qua các tệp cũng giúp quy trình làm việc GitOps đa cụm đáng tin cậy hơn.

Các bộ thu thập (collectors) cũng có sự tái cấu trúc tương tự. Phiên bản 3 đi kèm với các tên bộ thu thập được mã hóa cứng như alloy-metrics, alloy-logs và alloy-singleton, mỗi cái được gắn với một loại triển khai cụ thể. Việc định tuyến tính năng cho các bộ thu thập được chôn sâu trong mã nội bộ của biểu đồ, có nghĩa là việc hiểu tính năng nào chạy trên bộ thu thập nào yêu cầu đọc mã nguồn thay vì tệp cấu hình. Phiên bản 4 loại bỏ hoàn toàn các tên mã hóa cứng này. Người dùng giờ đây định nghĩa các bộ thu thập dưới dạng bản đồ và gán một hoặc nhiều preset mô tả hình dạng triển khai, chẳng hạn như clustered, statefulset hoặc daemonset. Sau đó, các tính năng được gán rõ ràng cho một bộ thu thập được đặt tên, loại bỏ logic định tuyến ẩn khỏi nội bộ của biểu đồ.

"Nếu bạn quên chỉ định, nó sẽ cung cấp cho bạn một thông báo cho biết tính năng nào vẫn cần được gán cho một bộ thu thập thay vì âm thầm chọn một cái cho bạn." — Pete Wall và Beverly Buchanan

Bản phát hành này cũng tách biệt việc triển khai các dịch vụ hỗ trợ (backing services) khỏi các tính năng tiêu thụ dữ liệu của chúng. Trong phiên bản 3, việc bật một tính năng như clusterMetrics sẽ âm thầm triển khai các dịch vụ như Node Exporter, kube-state-metrics và OpenCost phía sau hậu trường. Điều này gây ra vấn đề cho các nhóm mà cụm của họ đã chạy các dịch vụ này, vì các triển khai trùng lặp sẽ xuất hiện mà không có cảnh báo. Phiên bản 4 giới thiệu một khóa telemetryServices biến việc triển khai dịch vụ thành một bước rõ ràng. Các nhóm đã chạy Node Exporter có thể hướng dẫn biểu đồ bỏ qua việc triển khai và trỏ tính năng đến phiên bản hiện có thay thế. Như Wall và Buchanan lưu ý, cách tiếp cận này có nghĩa là "không còn các triển khai bất ngờ nào nữa."

Việc xử lý các chỉ số của cụm (cluster metrics) đã được tổ chức lại thành ba tính năng riêng biệt. Tính năng clusterMetrics trong phiên bản 3 bao gồm các chỉ số cụm Kubernetes, chỉ số máy chủ chủ Linux và Windows, chỉ số năng lượng qua Kepler và chỉ số chi phí qua OpenCost, tất cả trong một khối cấu hình duy nhất. Phiên bản 4 chia nhỏ chúng thành clusterMetrics, hostMetrics và costMetrics, mỗi cái có tệp giá trị (values file) riêng. Cấu hình của mỗi tính năng chỉ hiển thị các tùy chọn liên quan đến mối quan tâm của chính nó.

Một thay đổi nữa giải quyết việc sử dụng bộ nhớ trong pipeline nhật ký pod. Trong phiên bản 3, biểu đồ áp dụng tất cả các nhãn (labels) và chú thích (annotations) pod của Kubernetes dưới dạng nhãn nhật ký, sau đó sử dụng danh sách labelsToKeep để lọc chúng lại. Điều này yêu cầu Alloy cấp phát bộ nhớ cho hàng trăm nhãn tiềm năng chỉ để loại bỏ hầu hết chúng. Một số người dùng báo cáo các vấn đề bộ nhớ trong các phiên bản Alloy thu thập nhật ký được truy nguyên trực tiếp đến hành vi này. Phiên bản 4 loại bỏ hoàn toàn labelsToKeep; các nhãn và chú thích pod không được áp dụng hàng loạt. Thay vào đó, người dùng khai báo rõ ràng những nhãn nào họ muốn thăng cấp. Theo tài liệu Grafana, việc thêm một nhãn giờ đây là một thay đổi một dòng thay vì định nghĩa lại toàn bộ danh sách mặc định.

Grafana Kubernetes Monitoring Helm chart không phải là cách tiếp cận duy nhất để giám sát cấp cụm. kube-prometheus-stack, được duy trì bởi tổ chức prometheus-community, đóng gói Prometheus, Grafana, Alertmanager, Node Exporter, kube-state-metrics và Prometheus Operator vào một cài đặt Helm duy nhất. Biểu đồ đó sử dụng các tài nguyên tùy chỉnh của Prometheus Operator, chẳng hạn như ServiceMonitors và PrometheusRules, để cung cấp cấu hình thu thập (scrape) khai báo. Đây là lựa chọn phổ biến cho các nhóm xây dựng ngăn xếp quan sát được (observability stack) tự lưu trữ độc lập với Grafana Cloud. Ngược lại, biểu đồ của Grafana nhắm đến các nhóm gửi dữ liệu viễn thông (telemetry) đến Grafana Cloud hoặc ngăn xếp Grafana được quản lý, và thêm hỗ trợ cho hồ sơ và chỉ số chi phí ngay lập tức. Hai biểu đồ này phục vụ các trường hợp sử dụng liên quan nhưng riêng biệt.

Grafana Labs đã cung cấp một công cụ di chuyển chấp nhận tệp giá trị phiên bản 3 và tạo ra đầu ra tương thích phiên bản 4. Công cụ này xử lý các chuyển đổi cấu trúc, bao gồm chuyển đổi danh sách sang bản đồ và chia nhỏ các tính năng quá tải. Tất cả các ví dụ biểu đồ trong tài liệu Grafana và kho lưu trữ đã được cập nhật để phản ánh định dạng phiên bản 4.

Bản phát hành này đã thu hút sự bình luận trong cộng đồng Kubernetes. Kubesimplify viết trên LinkedIn rằng "gần như mọi mô hình mong manh từ v3 đã được thay thế", chỉ ra cụ thể sự chuyển đổi từ danh sách sang bản đồ và cách tiếp cận chọn tham gia (opt-in) đối với nhãn nhật ký pod là những thay đổi mang lại lợi ích thực tế tức thì nhất. Kubesimplify cũng lưu ý rằng việc giảm bộ nhớ trong Alloy là "kết quả trực tiếp" của việc thay đổi nhãn.