- Bộ sản phẩm Grafana thường xuyên loại bỏ hoặc thay thế các thành phần cốt lõi trong chu kỳ ngắn, khiến việc vận hành dài hạn trở nên khó khăn về mặt cấu trúc
- Mỗi lần đưa vào một giải pháp mới, cách cấu hình, DSL, Helm chart, Operator... lại liên tục thay đổi, tạo ra môi trường khó bảo trì ổn định
- Do không tương thích hoàn toàn với hệ sinh thái Prometheus Operator về mặt CRD,
ServiceMonitor và PodMonitor thì dùng được nhưng các tính năng cốt lõi như AlertmanagerConfig lại xuất hiện khoảng trống hỗ trợ
- Mimir 3.0 ép buộc bổ sung phụ thuộc Apache Kafka, làm tăng mạnh độ phức tạp của cụm và gánh nặng vận hành
- Trên toàn bộ Grafana Cloud cùng bộ sản phẩm Mimir, Loki và Grafana, vị trí cấu hình và endpoint rất dễ thay đổi, nên mô hình “xây một lần dùng lâu dài” liên tục bị phá vỡ
Những thay đổi cấu trúc diễn ra thường xuyên trong bộ sản phẩm Grafana
- Các chức năng cốt lõi như Grafana Agent, Flow Mode, OnCall... liên tục bị ngừng hỗ trợ hoặc thay thế chỉ trong vòng 1–3 năm
- Giao diện Grafana dựa trên Angular được chuyển sang React, khiến phần lớn bị hỏng
- Một số Helm chart không còn được bảo trì nữa
Độ phức tạp gia tăng do việc đưa Alloy vào sử dụng
- Grafana Alloy, được quảng bá là all-in-one, đã thay thế Agent trước đây nhưng từng tồn tại các vấn đề ổn định ban đầu
- Sử dụng DSL riêng (tương tự HCL), tách rời khỏi luồng dựa trên YAML trước đó
- Việc bổ sung thêm Alloy Operator còn khiến các thành phần trở nên phức tạp hơn
Mức độ đồng bộ chưa hoàn chỉnh với hệ sinh thái Prometheus Operator
- Hỗ trợ các chuẩn giám sát K8s là
ServiceMonitor, PodMonitor, nhưng
PrometheusRules cần cấu hình bổ sungAlertmanagerConfig không được hỗ trợ- Mimir dùng Alertmanager riêng nên phát sinh khác biệt phiên bản và các điểm không tương thích chi tiết
Việc đưa phụ thuộc Kafka vào Mimir 3.0
- Dù hướng tới khả năng mở rộng cao hơn trước, nhưng
- Kafka được thêm thành thành phần bắt buộc trong cấu hình cốt lõi, làm độ khó vận hành tăng mạnh
- Từ cài đặt Helm đơn lẻ chuyển sang điều phối nhiều thành phần, khiến độ phức tạp tăng theo cấp số nhân
Một hệ sinh thái khó sử dụng ổn định
- Grafana Cloud ingestion endpoint trở nên khó tìm hơn sau khi đưa vào hệ thống quản trị mới
- Chu kỳ nâng cấp và ngừng hỗ trợ của các thành phần chính quá nhanh, không phù hợp với các tổ chức muốn có “giám sát ổn định đến mức nhàm chán”
- Yếu tố làm suy giảm độ tin cậy cốt lõi không hẳn nằm ở công nghệ, mà ở cách quản lý sản phẩm và tốc độ thay đổi quá nhanh
5 bình luận
Dashboard được cung cấp sẵn trong influxdb cũng khá đơn giản nhưng vẫn dùng ổn.
Mình cũng đồng cảm với việc Grafana không ổn lắm, nhưng ngoài Grafana ra thì có giải pháp nào đáng để đề xuất mà hỗ trợ nhiều datasource như vậy không?
Đúng là hầu như không có lựa chọn thay thế nào đáng kể.
Có vẻ ngay cả ở Grafana cũng có khá nhiều người muốn thăng tiến hoặc tô điểm cho hồ sơ của mình.
Ý kiến trên Hacker News
Tôi cũng đang nghiêm túc cân nhắc bỏ hẳn Grafana vì đúng những lý do như tác giả nêu
Việc mỗi năm lại phải làm lại dashboard, đặt lại cảnh báo và chạy theo tính năng mới thật sự rất mệt mỏi
Tôi chỉ muốn được báo khi dịch vụ chết, và nếu datasource hay metric không thay đổi thì muốn giữ nguyên cùng một định nghĩa dashboard suốt 10 năm
Trước đây sidebar chỉ có 4–5 liên kết chính, còn bây giờ có quá nhiều submenu trong menu nên ngay cả các chức năng cơ bản như dashboard hay cảnh báo cũng khó tìm
Việc cứ phải học lại UI mỗi lần mở nó lên, dù chỉ khoảng một lần mỗi tháng, là cực kỳ kém hiệu quả
Trong bối cảnh vòng đời dịch vụ chỉ còn 2–3 năm mà cứ chồng thêm nhiều sản phẩm lên nhau thì cuối cùng chỉ thấy núi nợ kỹ thuật ngày càng cao hơn
Cái thực tế cứ mỗi quý lại phải thay một thứ lớn nào đó thật sự rất đau đầu
Mimir là hệ thống được thiết kế để xử lý metric ở quy mô hoàn toàn khác
Ở mức đó thì Kafka thực sự là cần thiết
Nhưng đa số người dùng không cần mức khả năng mở rộng như vậy
Nếu bạn không chạy Mimir trên một cụm Kubernetes chuyên dụng thì đó là thiết kế quá mức cần thiết
Cứ dùng Prometheus sẽ thực tế hơn
Ngay cả ở chế độ single-instance nó cũng hoạt động tốt đến bất ngờ, và mở rộng cũng rất dễ
Tôi đã dùng nó ở nhiều tổ chức và dự án cá nhân, và lúc nào cũng hài lòng
Nhưng Amazon Managed Prometheus của AWS dựa trên Cortex, và OpenObserve cũng đã vận hành ở quy mô petabyte rồi
Lý tưởng nhất là thứ gì đó triển khai đơn giản bằng một binary duy nhất, tương thích với OpenTelemetry, và sau này có thể chuyển sang nhà cung cấp OTEL khác
Nếu xây một giải pháp mới dựa trên OTEL thì đâu sẽ là lựa chọn hứa hẹn nhất để thay thế Prometheus/Grafana?
Muốn xử lý log và trace thì lại cần thêm nhiều thành phần phức tạp
Vì vậy chúng tôi tìm đến GreptimeDB, và nó có thể xử lý tích hợp metric, log và trace
Thu thập bằng OpenTelemetry và trực quan hóa bằng Grafana
Có thể làm dashboard bằng SQL nên rất hợp với năng lực của đội
Cấu trúc đơn giản như vậy khiến tôi khá hài lòng trên cương vị platform engineer
Nó được tạo ra để giải quyết sự phức tạp của Grafana và Elastic, và có thể xử lý log, metric, trace, dashboard và cảnh báo trong một container duy nhất
(người viết là maintainer của OpenObserve)
Nó là mã nguồn mở, được phát triển rất tích cực và đội ngũ giao tiếp cũng tốt
Rất nhiều người dùng đang chuyển sang vì muốn tránh sự phức tạp của Grafana, nơi phải tự xử lý nhiều backend khác nhau
(người viết là maintainer của SigNoz)
Tôi không hiểu vì sao các lập trình viên cứ phải chạy theo công nghệ mới nhất và thay đổi thiết lập mỗi tuần
Tôi đã dùng bộ Grafana + Prometheus từ năm 2017 và đến giờ nó vẫn hoạt động tốt
Chỉ cập nhật lên bản LTS khoảng 1–2 năm một lần
Dashboard vẫn hoàn hảo và không có vấn đề gì cả
Với đa số mọi người, bộ đôi nhàm chán nhưng ổn định này mới là lựa chọn tốt nhất
Hay là bạn vẫn đang giữ nguyên phiên bản cũ?
Liệu có trình dựng dashboard mã nguồn mở nào có thể thay thế Grafana không? Công ty tôi cũng đang dùng Grafana rất rộng rãi
Hoặc bạn cũng có thể dùng console template của Prometheus hay dashboard tích hợp sẵn của VictoriaMetrics, nhưng tính năng sẽ hạn chế hơn nhiều
Bản thân dashboard của Grafana vẫn khá dễ chịu nếu dùng cùng bộ VictoriaMetrics + ClickHouse
Tôi chỉ còn nhớ mang máng những cái tên như RRD hay Nagios
Chính sự thay đổi liên tục của Grafana lại khiến tôi thành quen
Mỗi major release thì dashboard lại hỏng hoặc UI lại đổi, nhưng giờ tôi chỉ biết chấp nhận vậy thôi
Vấn đề thật sự là PromQL lock-in của Prometheus
Chỉ cần đổi tên metric là phải sửa toàn bộ rule, cảnh báo và dashboard
PromQL hầu như không báo lỗi ngoài lỗi cú pháp, nên phải kiểm chứng bằng các công cụ như pint
Khi triển khai trên một máy chủ đơn lẻ, tôi thường dùng Prometheus Pushgateway + Grafana dưới dạng template docker-compose
Nó đơn giản và chạy tốt, nhưng khi lượng metric tăng lên thì độ phức tạp bùng nổ
Nếu Prometheus duy trì một định dạng truyền tải hiệu quả hơn thì có lẽ vấn đề này đã đỡ hơn
Nếu có một binary metric format gọn nhẹ thay cho định dạng văn bản, thì ngay cả hàng triệu label cũng có thể xử lý ổn thỏa
SigNoz là một lựa chọn tốt và đang được phát triển tích cực
Trước đây tôi tốn rất nhiều tiền cho nền tảng observability trên cloud, còn giờ chỉ cần chạy SigNoz self-hosted trên một máy Hetzner là giải quyết xong với 10 USD/tháng
Prometheus và Grafana từng đều hướng tới giải pháp full-stack, rồi OTEL xuất hiện làm cục diện trở nên phức tạp hơn
OTEL là giao thức cho metric, trace và log, nhưng không có một DB duy nhất nào hỗ trợ tất cả
Phần lớn vẫn kết hợp Prometheus (metric) + OpenSearch (log)
Cuối cùng thì OTEL dường như vẫn đòi hỏi thay collector và cấu hình lại