Khi Prometheus trở thành “nỗi ám ảnh” về tài nguyên
Nếu từng thức trắng đêm vì Prometheus bị OOM (Out of Memory) ngay lúc hệ thống cao điểm, bạn sẽ hiểu cảm giác bất lực này. Prometheus là tiêu chuẩn vàng trong giám sát, nhưng khi quy mô phình to, nó bộc lộ những hạn chế chết người.
Trong một dự án cũ, mình quản lý cụm monitor cho 200 microservices. Mọi thứ ổn cho đến khi số lượng active time series vượt ngưỡng 1 triệu. Grafana bắt đầu phản hồi chậm chạp, load dashboard mất hơn 15 giây. Đỉnh điểm là Prometheus bị OOM kill liên tục vì RAM không thể gánh nổi lượng index dữ liệu khổng lồ.
Vấn đề lưu trữ (retention) cũng đau đầu không kém. Để lưu dữ liệu trong 1 năm, ổ cứng cần tới vài Terabyte. Việc backup dữ liệu Prometheus giống như một canh bạc vì cấu trúc data phức tạp. Một lần disk lỗi đã khiến mình mất trắng 3 tháng dữ liệu, một bài học thực sự đắt giá.
Tại sao Prometheus lại ngốn tài nguyên đến vậy?
Để tối ưu, chúng ta cần hiểu rõ gốc rễ vấn đề của Prometheus TSDB:
- High Cardinality: Đây là sát thủ thầm lặng. Khi bạn gắn các label có giá trị thay đổi liên tục như
user_id, số lượng time series sẽ bùng nổ. Prometheus buộc phải giữ index của tất cả series này trong RAM để đảm bảo tốc độ truy vấn. - Cấu trúc ghi dữ liệu: Việc merge và nén các block dữ liệu cũ tiêu tốn lượng lớn CPU và I/O. Khi hệ thống có hàng nghìn target, disk I/O sẽ luôn ở trạng thái báo động đỏ.
- Khó khăn khi Scale ngang: Prometheus bản gốc thiết kế để chạy đơn lẻ. Muốn xử lý nhiều dữ liệu hơn, bạn chỉ có cách nâng cấp server (Vertical Scaling). Chi phí cho một con server 128GB RAM là không hề rẻ.
VictoriaMetrics: Kẻ thay thế hoàn hảo
Sau khi chật vật với Thanos và Cortex nhưng thấy quá phức tạp, mình đã chuyển sang VictoriaMetrics (VM). Kết quả thu được vượt xa mong đợi:
- Nén dữ liệu đỉnh cao: VM tiết kiệm khoảng 7-10 lần dung lượng ổ cứng. Một cụm dữ liệu 1TB trên Prometheus thường chỉ còn khoảng 100GB khi chuyển sang VM.
- Quản lý RAM thông minh: Thay vì ôm tất cả vào RAM, VM sử dụng cơ chế cache hiệu quả. Lượng RAM tiêu thụ thường chỉ bằng 1/5 so với Prometheus trên cùng một khối lượng công việc.
- Triển khai siêu tốc: Toàn bộ hệ thống gói gọn trong một file binary duy nhất. Không cần cài đặt thêm hàng tá component phụ trợ.
- Tương thích ngược: VM hỗ trợ PromQL và MetricsQL. Bạn có thể thay URL trong Grafana và mọi thứ hoạt động ngay lập tức mà không cần sửa dashboard.
Hướng dẫn cài đặt VictoriaMetrics (Single-node)
Dưới đây là cách triển khai bản Single-node bằng Docker Compose. Phương án này đủ sức cân được hệ thống có tới vài triệu metrics mỗi giây.
Bước 1: Thiết lập Docker Compose
Tạo file docker-compose.yml với cấu hình tối ưu sau:
version: '3.8'
services:
victoriametrics:
container_name: victoriametrics
image: victoriametrics/victoria-metrics:v1.94.0
ports:
- "8428:8428"
volumes:
- vmdata:/storage
command:
- "--storageDataPath=/storage"
- "--retentionPeriod=12" # Lưu trữ 12 tháng
restart: always
vmagent:
container_name: vmagent
image: victoriametrics/vmagent:v1.94.0
depends_on:
- victoriametrics
ports:
- "8429:8429"
volumes:
- vmagentdata:/vmagentdata
- ./prometheus.yml:/etc/prometheus/prometheus.yml
command:
- "--promscrape.config=/etc/prometheus/prometheus.yml"
- "--remoteWrite.url=http://victoriametrics:8428/api/v1/write"
restart: always
volumes:
vmdata:
vmagentdata:
Bước 2: Cấu hình Scraper
Dù dùng VM, chúng ta vẫn dùng file config chuẩn Prometheus để khai báo target. Tạo file prometheus.yml:
global:
scrape_interval: 15s
scrape_configs:
- job_name: 'vmagent'
static_configs:
- targets: ['localhost:8429']
- job_name: 'node-exporter'
static_configs:
- targets: ['192.168.1.10:9100']
Bước 3: Kích hoạt hệ thống
Chạy lệnh sau để khởi động toàn bộ stack:
docker-compose up -d
Lúc này, vmagent sẽ đi thu thập dữ liệu và đẩy về victoriametrics qua giao thức remote write. Tải trọng của việc scrape giờ đây đã được tách biệt hoàn toàn.
Kết nối Grafana và tối ưu hóa
Việc chuyển đổi cực kỳ đơn giản. Trong Grafana, bạn chỉ cần tạo Data Source loại Prometheus, điền URL là http://<your-ip>:8428 và nhấn Save. Tốc độ load biểu đồ sẽ nhanh hơn thấy rõ, đặc biệt là với các query có khoảng thời gian dài (Range query).
Lời khuyên từ thực tế: Khi nào nên chuyển đổi?
Đừng vội vã đập đi xây lại nếu hệ thống của bạn vẫn đang chạy tốt. Prometheus vẫn là lựa chọn tuyệt vời cho các cụm nhỏ, lưu trữ ngắn hạn dưới 30 ngày.
Tuy nhiên, hãy cân nhắc VictoriaMetrics ngay nếu bạn rơi vào các trường hợp:
- Server liên tục cảnh báo thiếu RAM hoặc bị OOM kill.
- Chi phí lưu trữ cloud (EBS/S3) tăng quá cao do dung lượng metrics.
- Cần lưu dữ liệu nhiều năm để làm báo cáo Compliance hoặc Audit.
Mẹo nhỏ: Bạn có thể chạy song song cả hai. Dùng Prometheus để xử lý cảnh báo (Alerting) tức thời và đẩy dữ liệu sang VM làm kho lưu trữ lâu dài. Cách tiếp cận hybrid này giúp bạn tận dụng được thế mạnh của cả hai bên.
Tóm lại, VictoriaMetrics là một bước nâng cấp đáng đồng tiền bát gạo cho bất kỳ DevOps Engineer nào đang đau đầu vì bài toán monitoring. Chúc bạn tối ưu hệ thống thành công!
