Giải pháp mở rộng Prometheus trong doanh nghiệp – Xu hướng giám sát hiện đại

Lời nói đầu

Chuyện là đợt này team mình làm lại hạ tầng monitoring, scale từ vài cluster lên hệ thống quy mô cực lớn thì ae cũng biết giới hạn chạm trần tài nguyên của Prometheus rồi.

Prometheus thì quá phổ biến ai cũng biết rồi, nhưng đến khi scale metric để control nhiều BUs thì đủ thứ vấn đề:

• OOM liên tục mỗi khi query range dài hoặc metric cardinality tăng đột biến.
• Disk tốn thì thôi rồi, retention recommend tối đa 30 ngày. Muốn lưu data vài tháng hay cả năm để tracking thì gần như bất khả thi.
• Multi-cluster nhưng Grafana phải config đủ loại data source, query chéo rất lỉnh kỉnh.

Thế là team lại phải ngồi đắn đo giữa mấy cái tên quen thuộc: Thanos, VictoriaMetrics hay Grafana Mimir. Con thì dễ cắm thêm vào cụm sẵn có, con thì nhẹ và query nhanh, con thì chuẩn hệ sinh thái nhưng tốn resource vận hành.

Sau khi làm rõ bài toán và test thực tế, mình có note lại thành một bài blog tổng hợp góc nhìn, ưu/nhược điểm cũng như kiến trúc scale Prometheus cho mô hình doanh nghiệp. Không có một công cụ duy nhất thắng tuyệt đối, mà lựa chọn dựa trên triết lý hạ tầng và ngân sách của doanh nghiệp.

1. So sánh thực tế triển khai ở các doanh nghiệp lớn

Thanos: Lựa chọn An toàn bên cạnh sự mở rộng

• Triết lý: Không can thiệp vào Prometheus. Thanos cắm thêm một sidecar ngay bên cạnh Prometheus pod để đẩy các file dữ liệu (block) đã đóng gói lên Object Storage (AWS S3, Google Cloud Storage, MinIO).
• Được dùng khi nào?
  • Doanh nghiệp đã có sẵn hạ tầng Prometheus rất chuẩn chỉnh và không muốn thay đổi cách vận hành hiện tại.
  • Ưu tiên các dự án nằm trong hệ sinh thái CNCF (Cloud Native Computing Foundation).
  • Muốn tận dụng chi phí siêu rẻ của Object Storage (S3/GCS) cho toàn bộ dữ liệu lịch sử.
• Doanh nghiệp tiêu biểu dùng: Red Hat, eBay, HelloFresh.

VictoriaMetrics: Tối ưu chi phí & Hiệu năng

• Triết lý: Thiết kế lại từ đầu một TSDB chuyên biệt, không dựa vào S3 làm storage chính (ở bản single-node) mà dùng đĩa SSD/EBS nén cực cao, hoặc hỗ trợ Object Storage (ở bản Cluster).
• Được dùng khi nào?
  • Doanh nghiệp gặp khủng hoảng về chi phí hạ tầng (Prometheus/Thanos tốn quá nhiều RAM/CPU).
  • Hạ tầng bị hiện tượng High Cardinality nghiêm trọng (hàng triệu pod/container sinh ra và mất đi liên tục khiến Prometheus bị tràn RAM).
  • Đội ngũ vận hành muốn sự đơn giản: dễ cài đặt, dễ debug, không muốn duy trì quá nhiều microservices phức tạp.
• Doanh nghiệp tiêu biểu dùng: Roblox, Grammarly, Wix, Abios, Adidas.

Grafana Mimir: Chuẩn mực cho Enterprise Multi-Tenancy

• Triết lý: Kiến trúc Microservices hoàn toàn, phân tách tuyệt đối giữa ghi (ingestion), lưu trữ (storage) và truy vấn (querying). Thiết kế để chịu tải hàng tỷ chuỗi thời gian (time-series).
• Được dùng khi nào?
  • Các tập đoàn tài chính, ngân hàng, hoặc nhà cung cấp dịch vụ SaaS cần phân quyền Multi-Tenancy cực kỳ khắt khe (mỗi phòng ban/khách hàng là một tenant cách ly hoàn toàn).
  • Doanh nghiệp dùng trọn bộ Grafana Stack (Grafana Enterprise, Tempo, Loki) và có ngân sách/đội ngũ SRE lớn để duy trì hệ thống phức tạp.
• Doanh nghiệp tiêu biểu dùng: Grafana Cloud, các ngân hàng lớn và tổng công ty viễn thông.

2. Bảng so sánh các chỉ số kỹ thuật chính

Note: Có thể tham khảo thêm về Benchmark giữa OpenTelemetry, Prometheus và victoriametrics

3. Best Practices, Xu hướng thiết kế Monitoring Stack

Trong các thiết kế kiến trúc monitoring hiện đại, các doanh nghiệp lớn thường áp dụng:

1. Bỏ mô hình “Full Prometheus” ở các cụm Edge/Spoke

Thay vì chạy một Server Prometheus đầy đủ tính năng ở từng cụm Kubernetes (tốn nhiều RAM/Disk), các doanh nghiệp chuyển sang dùng Agent siêu nhẹ:

• Dùng vmagent (của VictoriaMetrics) hoặc OpenTelemetry Collector hoặc Prometheus Agent mode.
• Các Agent này chỉ làm duy nhất việc Scrape metrics -> đệm vào bộ nhớ/đĩa -> Push về trung tâm (Remote Write).

2. Mô hình hybrid: VictoriaMetrics hoặc Thanos làm Central Hub

• Kịch bản 1 (Ưu tiên tiết kiệm & Đơn giản):

K8s Clusters (vmagent) -> VictoriaMetrics Cluster (Central) -> Grafana

Đánh giá: Đây là xu hướng đang tăng trưởng nhanh nhất trong vài năm qua nhờ chi phí AWS/GCP giảm rõ rệt.

• Kịch bản 2 (Ưu tiên CNCF Standard & Tận dụng S3):

K8s Clusters (Prometheus + Thanos Sidecar) -> S3/GCS Bucket -> Thanos Querier -> Grafana

Đánh giá: Rất phù hợp nếu doanh nghiệp có sẵn hạ tầng Cloud Native và muốn lưu dữ liệu dài hạn trên S3 với giá rất rẻ.

3. Xu hướng Unification (Nhất thể hóa với OpenTelemetry & ClickHouse)

Một số doanh nghiệp tiên phong hiện nay đang có xu hướng gộp chung việc lưu trữ Metrics, Logs, và Traces vào cùng một dạng Storage cơ sở (như ClickHouse hoặc hệ sinh thái VictoriaMetrics/VictoriaLogs) để giảm số lượng cơ sở dữ liệu phải quản lý trong doanh nghiệp.

Tóm lại: Doanh nghiệp nên chọn gì?

• Chọn VictoriaMetrics nếu: Doanh nghiệp muốn hiệu năng cao nhất, tốn ít tiền Server nhất, hệ thống nhiều metrics rác/High-Cardinality, và đội ngũ muốn vận hành nhàn nhất.
• Chọn Thanos nếu: Doanh nghiệp đã chạy ổn định với Prometheus, tôn thờ chuẩn CNCF, muốn lưu trữ hoàn toàn trên S3 và không muốn thay đổi luồng scraping hiện tại.
• Chọn Grafana Mimir nếu: Doanh nghiệp là tập đoàn lớn, cần phân quyền chia nhỏ dữ liệu cho hàng trăm team (Multi-tenancy) và chấp nhận tốn tài nguyên hạ tầng để có một hệ thống phân tán hoàn chỉnh.