Các hướng tiếp cận khi Prometheus bắt đầu quá tải
Làm monitoring thực tế, cảnh Prometheus phình to đã quá quen thuộc. RAM cắn cứng ngắc 85-90%. Ổ NVMe 500GB đầy nghẹt chỉ sau 3 tuần gom metrics. Mỗi lần ai đó trên Grafana kéo time range 30 ngày để xem báo cáo, dashboard lập tức xoay vòng rồi time-out.
Hạ tầng chạm mốc 2-3 triệu active time series là lúc bạn phải ra quyết định. Thông thường, anh em có 3 lựa chọn:
- Scale dọc Prometheus: Nâng cấp RAM máy chủ từ 32GB lên 64GB hay 128GB. Gắn thêm ổ đĩa SSD đắt đỏ. Đồng thời, chấp nhận giảm retention từ 30 ngày xuống còn vỏn vẹn 7-14 ngày.
- Ghép nối Thanos hoặc Cortex / Mimir: Đẩy metrics sang Object Storage như AWS S3 hoặc MinIO. Hệ thống lúc này cần thêm cả cụm Sidecar, Store Gateway, Compactor và Querier.
- Chuyển sang VictoriaMetrics: Dùng VictoriaMetrics làm backend long-term storage qua cơ chế
remote_write. Nếu muốn tinh gọn hơn nữa, bạn có thể thay thế luôn scrape engine bằngvmagent.
So sánh chi tiết 3 phương án scale
Mỗi giải pháp đều có sự đánh đổi rõ ràng giữa chi phí phần cứng và công sức vận hành:
1. Prometheus thuần (Vertical Scale)
- Ưu điểm: Dễ dựng, không có thành phần trung gian, cấu hình quen thuộc.
- Nhược điểm: Không scale ngang được. Chi phí server đội lên rất nhanh khi metric tăng. Prometheus dính lỗi OOM (Out-of-Memory) như cơm bữa khi compact dữ liệu hoặc gặp query nặng.
2. Hệ sinh thái Thanos / Cortex / Mimir
- Ưu điểm: Mở rộng gần như vô hạn nhờ Object Storage giá rẻ. Cho phép gom dữ liệu từ nhiều cụm Kubernetes về một nơi (Global Query View).
- Nhược điểm: Kiến trúc phức tạp với hàng tá microservices. Đội infra phải gánh thêm chi phí bảo trì Sidecar, Store, Querier, Compactor. Tốc độ query metrics cũ qua mạng S3 thường khá trễ nếu thiếu tầng memcached.
3. VictoriaMetrics (Single-node & Cluster)
- Ưu điểm: Khả năng nén dữ liệu cực kỳ đáng nể, thường gấp 5-7 lần Prometheus. Lượng RAM và CPU tiêu thụ chỉ bằng khoảng 1/4 khi xử lý cùng tải. Tương thích hoàn toàn với cú pháp PromQL và Prometheus API.
- Nhược điểm: Bản Single-node vẫn gắn chặt với dung lượng ổ cứng của một máy. Bản Cluster yêu cầu quản lý 3 component riêng rẽ:
vmstorage,vminsertvàvmselect.
Khi nào nên chọn VictoriaMetrics Single-node?
Nếu hệ thống dưới 2 triệu active time series và tốc độ ghi dưới 500k samples/giây, bản VictoriaMetrics Single-node là ứng viên số một. Bạn chỉ cần chạy đúng một file binary hoặc một container Docker độc lập. Không cần MySQL/Postgres đi kèm. Không cần cấu hình S3 bucket phức tạp. Vận hành cực kỳ nhàn đầu.
Kinh nghiệm thực tế: Đừng bao giờ đập bỏ hệ thống cũ ngay lập tức. Hãy giữ nguyên cụm Prometheus hiện tại, sau đó bật remote_write để đẩy song song một bản sao sang VictoriaMetrics. Cho hệ thống chạy thử nghiệm 1-2 tuần. Khi so sánh thấy RAM giảm rõ rệt và query Grafana phản hồi dưới 500ms, lúc đó switch hẳn vẫn chưa muộn.
Hướng dẫn triển khai VictoriaMetrics thực tế
Bước 1: Chạy VictoriaMetrics bằng Docker Compose
Dựng service trên Ubuntu thông qua Docker Compose là phương án nhanh và an toàn nhất. Tạo file docker-compose.yml:
version: '3.8'
services:
victoriametrics:
image: victoriametrics/victoria-metrics:v1.99.0
container_name: victoriametrics
ports:
- "8428:8428"
volumes:
- vmdata:/storage-data
command:
- "--storageDataPath=/storage-data"
- "--retentionPeriod=12m"
- "--httpListenAddr=:8428"
restart: always
volumes:
vmdata:
driver: local
Các tham số cốt lõi cần lưu ý:
--retentionPeriod=12m: Thời gian lưu trữ dữ liệu là 12 tháng. Bạn có thể đổi thành30dhoặc2ytùy nhu cầu.--storageDataPath: Thư mục chứa toàn bộ dữ liệu time-series trên disk.- Cổng lắng nghe mặc định:
8428.
Khởi chạy container và kiểm tra trạng thái dịch vụ:
docker compose up -d
curl http://localhost:8428/health
Đầu ra trả về OK nghĩa là VictoriaMetrics đã sẵn sàng ghi nhận dữ liệu.
Bước 2: Cấu hình Prometheus đẩy dữ liệu sang VictoriaMetrics
Nếu bạn đã có Prometheus đang scrape các Node Exporter, chỉ cần bổ sung block remote_write vào file prometheus.yml:
remote_write:
- url: "http://10.0.0.10:8428/api/v1/write"
queue_config:
max_samples_per_send: 10000
capacity: 20000
max_shards: 30
Reload cấu hình Prometheus không cần restart process:
curl -X POST http://localhost:9090/-/reload
Dữ liệu mới sẽ được ghi đồng thời vào VictoriaMetrics. Lúc này, bạn có thể tự tin hạ retention của Prometheus xuống 2d hoặc 3d để giải phóng ngay hàng chục GB đĩa.
Bước 3: Thu thập metrics không cần Prometheus (Dùng vmagent)
Muốn giải phóng triệt để RAM, hãy thay thế Prometheus scrape worker bằng vmagent. Tạo file cấu hình prometheus-scrape.yml:
global:
scrape_interval: 15s
scrape_configs:
- job_name: 'node_exporter'
static_configs:
- targets: ['10.0.0.1:9100', '10.0.0.2:9100']
- job_name: 'victoriametrics'
static_configs:
- targets: ['localhost:8428']
Khởi chạy container vmagent:
docker run -d \
--name vmagent \
-v $(pwd)/prometheus-scrape.yml:/etc/prometheus/scrape.yml \
victoriametrics/vmagent:v1.99.0 \
-promscrape.config=/etc/prometheus/scrape.yml \
-remoteWrite.url=http://victoriametrics:8428/api/v1/write
Trong thực tế, vmagent chỉ tốn khoảng 35-50MB RAM để scrape hàng chục node. Con số này nhẹ hơn gấp nhiều lần so với mức 1-2GB RAM thông thường của Prometheus.
Bước 4: Kết nối Grafana và truy vấn
VictoriaMetrics giả lập chuẩn xác Prometheus API. Các bước kết nối trên Grafana:
- Vào Grafana > Administration > Data sources > Add data source.
- Chọn type Prometheus.
- Tại ô Prometheus server URL, nhập:
http://<IP_SERVER>:8428/prometheus. - Bấm Save & test. Grafana báo thông báo xanh: Data source is working.
Toàn bộ dashboard cũ giữ nguyên, không cần sửa query. VictoriaMetrics còn cung cấp MetricsQL với nhiều hàm tiện lợi, chẳng hạn như rate_over_time giúp xử lý dữ liệu ngắt quãng mượt mà hơn hẳn PromQL gốc.
Kiểm tra hiệu quả nén đĩa thực tế
Giao diện UI có sẵn giúp bạn tra cứu nhanh metrics và dung lượng:
http://<IP_SERVER>:8428/vmui
Hoặc bạn có thể kiểm tra trực tiếp volume trên host Linux:
du -sh /var/lib/docker/volumes/vmdata/_data
Hiệu quả nén thể hiện rất rõ qua số liệu. Với tập dữ liệu mẫu 100 triệu datapoints, Prometheus TSDB thường ngốn từ 15 đến 18GB ổ cứng. Trong khi đó, VictoriaMetrics chỉ chiếm khoảng 2.5 đến 3.8GB nhờ thuật toán nén ZSTD tối ưu riêng cho float64 và timestamp. Bạn vừa giữ được log theo dõi cả năm, vừa cắt giảm trực tiếp 60-70% chi phí lưu trữ hạ tầng.

