Khi Prometheus chạm giới hạn tài nguyên
Bất kỳ ai từng quản lý một cụm Kubernetes đang phát triển đều biết đến khái niệm ‘Prometheus Wall’ (Bức tường Prometheus). Nó thường xuất hiện vào thời điểm tồi tệ nhất—chẳng hạn như 4 giờ chiều ngày thứ Sáu. Đột nhiên, Prometheus chạm giới hạn bộ nhớ, lỗi OOM (Out Of Memory) tăng vọt, và dung lượng ổ đĩa biến mất nhanh hơn cả tốc độ bạn kịp mở rộng các PVC. Tôi đã dành nhiều tháng để phân mảnh (sharding) các instance và điều chỉnh gắt gao các chính sách lưu trữ (retention policies) trước khi nhận ra mình cần một hướng đi bền vững hơn.
Prometheus là một ‘chú ngựa thồ’ đáng tin cậy, nhưng các lựa chọn về kiến trúc của nó có thể trở thành gánh nặng khi môi trường của bạn mở rộng. Độ phức tạp dữ liệu (High cardinality) và lưu trữ dài hạn thường trở thành những nút thắt cổ chai tốn kém. Sau khi chuyển sang VictoriaMetrics trong môi trường production, kết quả đến ngay lập tức. Chúng tôi thấy mức sử dụng CPU giảm 3 lần và IOPS của ổ đĩa giảm gần 90% so với thiết lập Prometheus nguyên bản trước đó.
Tại sao VictoriaMetrics lại vượt trội
Các hướng mở rộng truyền thống thường dẫn đến Thanos hoặc Cortex. Dù mạnh mẽ, nhưng chúng lại rất nặng nề về mặt vận hành. Bạn sẽ thấy mình phải quản lý lưu trữ đối tượng (object storage), các sidecar cho mọi instance Prometheus, và hàng tá microservices chỉ để duy trì hệ thống hoạt động. VictoriaMetrics chọn một con đường khác, ưu tiên sự đơn giản và hiệu quả cực cao.
Sự khác biệt về kiến trúc
Prometheus là một thực thể độc lập tự thu thập và lưu trữ dữ liệu cục bộ. Ngược lại, VictoriaMetrics hoạt động như một giải pháp thay thế hoàn hảo với hiệu suất cao. Nó có thể thu thập dữ liệu qua vmagent hoặc đóng vai trò là mục tiêu Remote Write. Điểm kỳ diệu thực sự nằm ở công cụ lưu trữ (storage engine). Nó sử dụng cấu trúc lưu trữ dựa trên cây LSM (Log-Structured Merge) tùy chỉnh, được tối ưu hóa riêng cho dữ liệu dạng chuỗi thời gian (time-series). Điều này mang lại khả năng nén dữ liệu tốt hơn đáng kể.
Triết lý ‘single binary’ (chỉ một tệp thực thi duy nhất) mang lại một làn gió mới. Nó thực sự hiệu quả. Bạn không cần bằng tiến sĩ về hệ thống phân tán để giữ cho nó chạy ổn định dưới áp lực lớn.
Ưu điểm và Sự đánh đổi
Điểm mạnh
- Hiệu quả tài nguyên: Trong các bài kiểm tra của tôi, VictoriaMetrics sử dụng RAM ít hơn 7 lần so với Prometheus cho cùng một lượng series hoạt động.
- Nén dữ liệu mạnh mẽ: Dữ liệu từng chiếm 200GB trong Prometheus đã giảm xuống chỉ còn 22GB trong VictoriaMetrics.
- Khả năng tương thích hoàn hảo: Nó hỗ trợ MetricsQL, một phiên bản mở rộng của PromQL. Các dashboard Grafana hiện có của bạn sẽ hoạt động ngay lập tức.
- Xử lý Cardinality: Nó xử lý hàng triệu tổ hợp nhãn (label) duy nhất mà không gặp phải các đợt trễ hệ thống (latency spikes) thường thấy.
Những điều cần lưu ý
- Push và Pull: Mặc dù hỗ trợ scraping, nó được thiết kế tối ưu cho luồng Remote Write. Điều này đòi hỏi một chút thay đổi trong tư duy khi bạn thiết kế đường dẫn dữ liệu (data pipelines).
- Quy mô hệ sinh thái: Cộng đồng đang phát triển nhanh chóng, nhưng thư viện các operator có sẵn vẫn nhỏ hơn so với hệ sinh thái khổng lồ của Prometheus.
Kiến trúc Production đã qua thử thách
Đối với các môi trường quy mô vừa đến lớn, tôi khuyên dùng thiết lập sử dụng vmagent và vmsingle. Nếu bạn đang quản lý quy mô hàng petabyte, hãy tìm hiểu phiên bản cluster.
Trong thiết kế này, vmagent nằm gần các workload của bạn để thực hiện scrape metrics. Nó sẽ đệm (buffer) dữ liệu cục bộ nếu kho lưu trữ chính bị ngoại tuyến, ngăn chặn việc mất dữ liệu khi mạng gặp sự cố. Dữ liệu sau đó được đẩy qua Remote Write đến một instance VictoriaMetrics trung tâm. Grafana chỉ đơn giản là trỏ đến instance này như nguồn dữ liệu chính.
Nếu bạn dùng Kubernetes, hãy sử dụng VictoriaMetrics Operator. Nó xử lý các công việc nặng nhọc về quản lý vòng đời, tương tự như cách Prometheus Operator thực hiện.
Thực hành: Triển khai với Docker Compose
Hãy chạy thử một bản mẫu. Thiết lập này bao gồm engine cốt lõi, một vmagent để thu thập dữ liệu và Grafana.
# docker-compose.yml
version: '3.8'
services:
victoriametrics:
container_name: victoriametrics
image: victoriametrics/victoria-metrics:v1.93.5
ports:
- "8428:8428"
volumes:
- vmdata:/storage
command:
- "--storageDataPath=/storage"
- "--retentionPeriod=1y"
restart: always
vmagent:
container_name: vmagent
image: victoriametrics/vmagent:v1.93.5
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
grafana:
container_name: grafana
image: grafana/grafana:10.0.3
ports:
- "3000:3000"
restart: always
volumes:
vmdata:
vmagentdata:Bạn sẽ cần một tệp prometheus.yml tiêu chuẩn để vmagent nhắm mục tiêu vào các dịch vụ của mình:
# prometheus.yml
global:
scrape_interval: 15s # Khoảng thời gian thu thập dữ liệu
scrape_configs:
- job_name: 'vmagent'
static_configs:
- targets: ['vmagent:8429']
- job_name: 'victoriametrics'
static_configs:
- targets: ['victoriametrics:8428']Thực thi lệnh docker-compose up -d. Bây giờ bạn đã có một backend cấp độ production sẵn sàng để thử nghiệm.
Kết nối với Grafana
VictoriaMetrics thực chất ‘giả dạng’ thành Prometheus, giúp việc tích hợp trở nên liền mạch. Để xem dữ liệu của bạn:
- Mở Grafana tại
localhost:3000. - Đi tới Connections > Data Sources.
- Thêm một nguồn Prometheus mới.
- Đặt URL thành
http://victoriametrics:8428. - Nhấn Save & Test.
Chỉ vậy thôi. Bây giờ bạn có thể sử dụng tất cả các dashboard hiện có của mình. Nếu bạn muốn tận dụng các tính năng của MetricsQL, như tính toán tỷ lệ (rate) nâng cao hoặc thao tác nhãn, bạn có thể bắt đầu sử dụng chúng trực tiếp trong các panel.
Thực tế về hiệu suất
Ban đầu tôi khá hoài nghi về những tuyên bỏ về khả năng lưu trữ cho đến khi tự mình kiểm chứng các con số. Trong một cụm production đẩy 150.000 mẫu (samples) mỗi giây, Prometheus tiêu tốn khoảng 220GB đĩa mỗi tuần. VictoriaMetrics xử lý cùng một khối lượng tải đó chỉ với 24GB.
Để đạt được những kết quả này, hãy chú ý đến cờ --retentionPeriod. Không giống như việc quản lý khối (block management) phức tạp trong Prometheus, VictoriaMetrics xử lý vòng đời dữ liệu theo cách tuyến tính. Nếu bạn đặt là 1y, hệ thống sẽ tự động quản lý việc xóa dữ liệu với chi phí vận hành gần như bằng không.
Nếu bạn gặp tình trạng sử dụng CPU cao—điều hiếm khi xảy ra—hãy điều chỉnh cờ --search.maxQueryDuration. Điều này ngăn các truy vấn khổng lồ, kém hiệu quả làm treo hệ thống. Tuy nhiên, đối với hầu hết người dùng, các giá trị mặc định đã được tinh chỉnh hoàn hảo.
Lời kết từ kinh nghiệm thực tế
Thay đổi cốt lõi hệ thống giám sát là một quyết định lớn. Tuy nhiên, sự đơn giản trong vận hành của một backend single-binary, vốn tương thích hoàn toàn với các công cụ hiện có của bạn, là điều khó có thể bỏ qua. Kể từ khi chuyển đổi, sự mệt mỏi khi trực ‘on-call’ liên quan đến hạ tầng giám sát của tôi đã biến mất.
Nếu bạn đã mệt mỏi với việc phải ‘trông chừng’ Prometheus hoặc xử lý lỗi hỏng TSDB, hãy thử VictoriaMetrics. Bắt đầu bằng cách thiết lập nó như một mục tiêu Remote Write song song với thiết lập hiện tại của bạn. Khi bạn thấy được sự tiết kiệm tài nguyên, việc chuyển đổi sẽ giống như một bước tiến hóa tự nhiên cho hệ thống của bạn.
