VictoriaMetrics: kho số liệu theo thời gian cho giám sát, thử ở công ty môi giới bảo hiểm
Đăng ngày 12/10/2026
Mục lục bài nghiên cứu
Kết luận ngắn: một máy chủ số liệu đáng thử trước khi nghĩ đến cụm lớn
VictoriaMetrics là cơ sở dữ liệu chuỗi thời gian (time series database, nơi lưu các con số đo theo mốc thời gian như tải CPU hay số yêu cầu mỗi giây) dành cho giám sát hạ tầng và ứng dụng. README định vị nó là lưu trữ dài hạn cho Prometheus hoặc thay thế trực tiếp Prometheus và Graphite trong Grafana; cả bản một nút (single-node) lẫn bản cụm (cluster) đều công bố dưới Apache 2.0. [1][2]
Điểm đáng chú ý với doanh nghiệp vừa và nhỏ nằm ở lời khuyên của chính tài liệu cụm: nên dùng single-node khi tốc độ nạp dưới một triệu điểm dữ liệu mỗi giây, vì bản này dễ cấu hình và vận hành hơn, và tài liệu yêu cầu người đọc "nghĩ kỹ hai lần" trước khi chọn cụm. [6] Phần lớn đội kỹ thuật có thể khởi đầu bằng một tiến trình và tác tử thu thập vmagent.
Nên cân nhắc khi đã có Prometheus và Grafana, khi số chuỗi số liệu tăng nhanh làm bộ nhớ thành nút thắt, hoặc cần gom nhiều giao thức vào một chỗ. Không nên chọn chỉ vì các con số so sánh trong README, vì chúng dẫn tới bài viết do chính tác giả dự án công bố. [1] Đây là nghiên cứu tại bàn, chưa cài đặt hay đo đạc gì.
Vì sao số liệu vận hành cần một kho riêng
Mỗi máy chủ, container và dịch vụ phát ra hàng chục chỉ số mỗi vài giây. Tài liệu khái niệm định nghĩa metric là một thước đo số học kèm các nhãn (label) như đường dẫn hay mã trạng thái, dùng để xem hệ thống hành xử ra sao, dự báo xu hướng và kích hoạt cảnh báo khi vượt ngưỡng. [8]
Loại dữ liệu này được ghi liên tục, gần như không sửa và thường truy vấn theo khoảng thời gian. Khi số giá trị nhãn tăng, số chuỗi riêng biệt tăng theo. Tài liệu vmagent nhắc hai khái niệm: cardinality cao (nhiều chuỗi duy nhất) và churn rate cao (chuỗi cũ liên tục bị thay bằng chuỗi mới), kèm bộ giới hạn số chuỗi ngay lúc thu thập. [9]
Với doanh nghiệp nhỏ, bài toán thường là giữ số liệu đủ lâu để so sánh theo mùa vụ, không để RAM và ổ đĩa máy giám sát phình ra, và có một nơi duy nhất cho Grafana truy vấn. README cho phép nhiều Prometheus cùng ghi vào VictoriaMetrics để truy vấn chung. [1] Kho số liệu không thay thế nhật ký hay vết giao dịch; VictoriaLogs là sản phẩm tách biệt. [6]
Hai hình hài của một sản phẩm: một tiến trình hay ba dịch vụ
Bản single-node là tệp nhị phân nhỏ, không phụ thuộc ngoài, cấu hình bằng tham số dòng lệnh. [1] Hướng dẫn kiến trúc gọi đó là mức "Basic": một instance lưu, đọc và phục vụ mọi số liệu, hợp cho thử nghiệm hay hệ thống không quan trọng, nhược điểm là điểm lỗi duy nhất. [3]
Bản cụm gồm ba dịch vụ. vmstorage lưu dữ liệu thô; vminsert nhận dữ liệu và rải sang các nút vmstorage bằng băm nhất quán (consistent hashing) trên tên số liệu cùng nhãn; vmselect truy vấn bằng cách lấy dữ liệu từ mọi vmstorage đã cấu hình. Các vmstorage không biết nhau và không chia sẻ dữ liệu, tức mô hình không chia sẻ gì (shared nothing). [6]
Hướng dẫn kiến trúc xếp phương án theo "bán kính ảnh hưởng" (blast radius): single-node, cụm trong một vùng khả dụng, nhiều cụm nhiều vùng cho khôi phục thảm họa, hyperscale theo ô, và lớp logic để cô lập giữa các nhóm hoặc khách hàng. [3] Tài liệu cụm không khuyến khích trải một cụm qua nhiều vùng; nên chạy cụm độc lập mỗi vùng và dùng vmagent nhân bản dữ liệu vào tất cả. [6]
Một mẫu số liệu đi từ ứng dụng tới biểu đồ như thế nào
Dự án hỗ trợ cả đẩy (push), khi ứng dụng chủ động gửi số liệu, lẫn kéo (pull), khi hệ thống giám sát đi thu thập từ các mục tiêu đã khai báo. Đẩy giúp cấu hình phía kho đơn giản; kéo dễ gỡ lỗi vì kho biết mọi mục tiêu nhưng cần quyền truy cập tới từng ứng dụng. [8]
Cách phổ biến theo tài liệu là dùng cả hai với vmagent làm trạm trung gian: thu thập, lọc, gán lại nhãn rồi chuyển sang kho qua giao thức remote_write. Khi kho đích mất liên lạc, số liệu được đệm tại remoteWrite.tmpDataPath, dung lượng đĩa tối đa chỉnh bằng remoteWrite.maxDiskUsagePerURL. [8][9]
Người dùng truy vấn bằng PromQL hoặc MetricsQL và Grafana làm nguồn dữ liệu. Môi trường docker-compose mẫu ở bản single-node cho thấy bố cục đó: vmagent gửi vào VictoriaMetrics, Grafana trỏ vào, vmalert đánh giá luật cảnh báo và Alertmanager nhận thông báo. [1][5]
Ở bản cụm, vmagent gửi vào vminsert, vminsert chia mẫu sang vmstorage, còn đường đọc đi qua vmauth cân bằng tải tới các vmselect. [5] Cổng mặc định là 8480 cho ghi và 8481 cho đọc, định tuyến theo tiền tố /insert và /select. [6]
Những gì tài liệu xác nhận về bản cộng đồng
README liệt kê nhiều giao thức nạp: Prometheus remote write, định dạng exposition của Prometheus, InfluxDB line protocol, Graphite, OpenTSDB, dòng JSON, CSV, DataDog agent, NewRelic agent và OpenTelemetry. [1] Điều này cho thấy khả năng gom về một nơi mà chưa cần thay toàn bộ công cụ thu thập.
README cũng nêu PromQL và MetricsQL, gán lại nhãn, bộ giới hạn cardinality, tổng hợp luồng (stream aggregation) và lưu trữ trên hệ thống tệp mạng như Amazon EFS. [1] Tài liệu vmagent bổ sung nhân bản sang nhiều kho từ xa, tải cấu hình từ nhiều tệp và chia mục tiêu cho nhiều vmagent. [9]
Bản cụm hỗ trợ mọi tính năng của single-node cộng mở rộng ngang, đa người thuê (multitenancy) và nhân bản. Mỗi người thuê nhận diện bằng accountID hoặc accountID:projectID là số nguyên 32 bit, và được tạo tự động khi điểm dữ liệu đầu tiên được ghi. [6]
Mục "Benchmarks" và các case study trong README không được tái tạo hay kiểm chứng ở đây, nên không làm cơ sở cho khuyến nghị nào. [1]
Ai nên đọc kỹ, ai có thể bỏ qua
Nhóm hợp nhất là đội vận hành hoặc DevOps đã quen Prometheus và Grafana: giao thức, ngôn ngữ truy vấn và bảng điều khiển đã quen, còn lợi ích kỳ vọng nằm ở bộ nhớ, dung lượng và thời gian lưu giữ. Đó là giả thuyết cần thử nghiệm riêng. [1][8]
Nhóm thứ hai là đội sản phẩm có nhiều chuỗi số liệu như IoT hay nền tảng nhiều khách hàng, và nhà cung cấp dịch vụ cần tách dữ liệu từng khách. Cơ chế đa người thuê và lớp logic trong hướng dẫn kiến trúc phản ánh nhu cầu cô lập này. [3][6]
Nếu tổ chức chỉ có vài máy chủ và hài lòng với một Prometheus, hoặc nhu cầu thật là phân tích nhật ký, VictoriaMetrics không phải điểm xuất phát. Tài liệu chủ yếu bằng tiếng Anh và xoay quanh cờ dòng lệnh, nên đội cần người đọc được tài liệu và theo dõi changelog, vì README nói dự án phát triển nhanh. [1]
Tình huống đề xuất: giám sát cổng báo giá của một công ty môi giới bảo hiểm
Đây là tình huống giả định, chưa từng triển khai. Một công ty môi giới bảo hiểm ở TP. Hồ Chí Minh vận hành cổng so sánh và báo giá bảo hiểm xe cơ giới và sức khỏe. Cổng gọi API liên thông sang nhiều nhà bảo hiểm đối tác, phát hành hợp đồng điện tử, nhận thanh toán qua cổng bên thứ ba và có ứng dụng nội bộ cho tư vấn viên. Đội kỹ thuật vài người, chạy vài máy ảo và một cụm Kubernetes nhỏ.
Khi khách phàn nàn báo giá chậm, đội cần biết đối tác nào trả lời chậm, vào giờ nào, so với tuần trước ra sao. Đề xuất gắn nhãn theo tên đối tác, loại sản phẩm và kênh bán, nhưng tuyệt đối không dùng mã khách, số hợp đồng hay biển số xe làm nhãn, vì mỗi giá trị riêng sinh một chuỗi mới và kéo dữ liệu cá nhân vào kho giám sát. Giới hạn cardinality của vmagent là lưới bảo vệ thứ hai. [9]
Kiến trúc khởi đầu gọn: một VictoriaMetrics single-node, một vmagent, Grafana và vmalert, đúng bố cục docker-compose của dự án. [5] Nếu cần chịu mất một máy mà vẫn đọc được số liệu, hướng dẫn kiến trúc gợi ý sao lưu hoặc nhân bản qua vmagent trước khi nghĩ tới cụm. [3]
Chỉ số nên theo dõi gồm độ trễ và tỷ lệ lỗi từng API đối tác, độ dài hàng đợi phát hành hợp đồng, tỷ lệ thanh toán thất bại và dung lượng đĩa của chính kho. Ngưỡng cụ thể phải lấy từ dữ liệu thực của công ty. Nếu muốn lưu hồ sơ nghiên cứu nội bộ, phamvanthu.com có thể là nơi tham chiếu, còn dữ liệu giám sát thuộc hệ thống vận hành.
Dựng, nâng cấp và sao lưu: việc đội vận hành phải tự gánh
Cách thử nhanh nhất trong kho là docker-compose: make docker-vm-single-up dựng single-node cùng vmagent, vmalert, Alertmanager và Grafana, còn make docker-vm-cluster-up dựng bản cụm. Tài liệu ghi cả tài khoản mặc định của môi trường mẫu, nên nó chỉ hợp cho thử nghiệm cục bộ. [5]
Với bản cụm, tài liệu đưa hướng dẫn dung lượng làm giả thuyết ban đầu: khởi đầu 20 đến 30 phân mảnh vmstorage nhỏ, khoảng một vminsert cho mỗi 3 đến 5 vmstorage, khoảng 2 GiB RAM mỗi vCPU, chừa 50% RAM, 50% CPU và ít nhất 20% đĩa trống. Tài liệu cũng khuyên nhiều nút vmstorage nhỏ và lưu ý vmstorage có trạng thái nên khó co giãn. [6]
Về độ bền, mặc định VictoriaMetrics dựa vào đĩa bền vững có nhân bản; nhân bản cấp ứng dụng bằng replicationFactor làm tài nguyên tăng tới N lần. Tài liệu nhấn mạnh nhân bản không thay thế sao lưu. [6] Tự động sao lưu (vmbackupmanager) thuộc bản Enterprise. [7]
Về đệm của vmagent, bộ đệm đĩa giúp số liệu chưa gửi sống sót qua khởi động lại; bộ đệm RAM (tmpfs) nhanh hơn nhưng mất dữ liệu khi khởi động lại. [3]
Giữ kho ở mạng nội bộ và đặt cổng xác thực phía trước
Tài liệu cụm khuyến nghị: mọi thành phần chạy trong mạng riêng, không lộ trực tiếp ra Internet; client ngoài đi qua proxy xác thực như vmauth hoặc vmgateway; token chỉ đi qua HTTPS; dùng token riêng cho từng người thuê; ưu tiên danh sách cho phép các điểm cuối API. [6]
SECURITY.md rất ngắn và chỉ trỏ sang mục bảo mật của tài liệu để biết chính sách báo lỗ hổng và phiên bản được hỗ trợ; nghiên cứu này chưa đọc trang đích đó. [4]
Rủi ro quyền riêng tư chủ yếu đến từ thiết kế nhãn. Nhãn chứa định danh khách hàng biến kho giám sát thành nơi chứa dữ liệu cá nhân ngoài các quy trình bảo vệ thông thường. Nên lập quy tắc nhãn bằng văn bản, rà soát trước khi bật thu thập và dùng gán lại nhãn để loại nhãn không mong muốn tại vmagent. [9] Với ngành bảo hiểm, nên nhờ tư vấn pháp lý đối chiếu quy định bảo vệ dữ liệu cá nhân hiện hành.
mTLS giữa các thành phần, tự cấp chứng chỉ TLS, lọc IP ở vmauth và bản dựng FIPS 140-3 được liệt kê là tính năng Enterprise, không nên mặc định có ở bản cộng đồng. [7]
Apache 2.0 cho bản cộng đồng, giấy phép riêng cho Enterprise
LICENSE ở thư mục gốc là văn bản Apache License 2.0 đầy đủ, bản quyền 2019 đến 2026 thuộc VictoriaMetrics, Inc.; README xác nhận cả single-node và cluster theo giấy phép này. [1][2] Giấy phép cho phép sao chép, tạo tác phẩm phái sinh và phân phối kèm điều kiện giữ thông báo bản quyền; bộ phận pháp chế nên đọc văn bản chính thức.
Ranh giới quan trọng là bản Enterprise. Tài liệu nói thành phần có hai loại, Community (mã nguồn mở, miễn phí) và Enterprise; tệp thực thi và ảnh Docker Enterprise có hậu tố enterprise. Dùng Enterprise được phép khi đánh giá ở môi trường không sản xuất với giấy phép dùng thử, hoặc dùng sản xuất khi có hợp đồng hợp lệ; VictoriaMetrics Cloud xây trên nền Enterprise. [7]
Người tải bản phát hành cần kiểm tra kỹ tên tệp để không dùng nhầm bản enterprise vào sản xuất. Các tính năng Enterprise gồm downsampling, nhiều chính sách lưu giữ, tự phát hiện nút vmstorage, phát hiện bất thường, tự sao lưu, tích hợp Kafka và Google PubSub. [1][7]
Kết luận chỉ áp dụng cho mã tại commit đã ghim, không bao trùm dịch vụ đám mây, hợp đồng hỗ trợ, nhãn hiệu hay giấy phép của thư viện phụ thuộc. Cây tệp ở commit này có thư mục vendor chứa giấy phép riêng của thư viện bên thứ ba, và tệp giấy phép trong thư mục triển khai vmanomaly chưa được đọc.
Chi phí tính bằng giờ người và loại tài nguyên, không bằng bảng giá
Bản cộng đồng không thu phí giấy phép nhưng tổng chi phí khác không. Khoản đầu là giờ công vận hành: dựng, thiết kế nhãn, viết bảng điều khiển và luật cảnh báo, nâng cấp, theo dõi changelog, xử lý sự cố. Với đội nhỏ, thứ khan hiếm nhất thường là thời gian của người hiểu hệ thống.
Khoản thứ hai là tài nguyên theo loại: CPU, RAM, đĩa bền vững và băng thông. Nhân bản ứng dụng hệ số N làm tài nguyên tăng tới N lần, còn kiến trúc hai vùng làm vmstorage mỗi vùng chỉ tận dụng khoảng một nửa vì phải sẵn sàng gánh toàn tải khi vùng kia hỏng. [3][6]
Khoản thứ ba là Enterprise nếu cần. Nguồn đã đọc không có thông tin giá nên bài này không suy đoán; quyết định nên dựa trên tính năng thực sự cần như downsampling hay mTLS. [7] Để ước lượng đĩa, tài liệu đề xuất chạy thử với tải thật, đo mức dùng sau một ngày rồi nhân với số ngày lưu giữ, cộng khoảng trống cho khâu hợp nhất hằng tháng. [6]
So với giữ Prometheus, thuê dịch vụ ngoài hay chọn kho khác
Giữ nguyên một Prometheus là lựa chọn đơn giản nhất ở quy mô nhỏ. Lý do cân nhắc VictoriaMetrics là cần lưu lâu hơn, gom nhiều Prometheus hoặc giảm áp lực tài nguyên; đó là giả thuyết cần đo. Vì có thể làm kho dài hạn qua remote write, việc chuyển có thể làm dần. [1]
Các hệ thống lưu trữ dài hạn khác cho Prometheus như Thanos, Cortex hay Mimir đi theo hướng nhiều thành phần dùng kho đối tượng. README so sánh với một số tên trong nhóm này nhưng đó là phát biểu của dự án. [1] Cách công bằng là chạy cùng tải đại diện trên mỗi ứng viên và đo cùng bộ chỉ số.
Dịch vụ giám sát thuê ngoài, trong đó có VictoriaMetrics Cloud, giảm gánh vận hành nhưng đưa số liệu ra ngoài hạ tầng công ty. [7] Cơ sở dữ liệu chuỗi thời gian đa dụng như InfluxDB hay TimescaleDB hợp hơn khi dữ liệu thời gian là một phần nghiệp vụ và cần SQL; VictoriaMetrics nhận được giao thức InfluxDB nên thử di chuyển bớt phải sửa agent. [1]
Khi nào không nên dùng, và chỗ nguồn chưa cho phép kết luận
Trong cụm, kiến trúc ưu tiên tính sẵn sàng hơn nhất quán: khi một số vmstorage không phản hồi, vmselect vẫn trả kết quả nhưng đánh dấu isPartial. Nếu không để ý cờ này, người xem có thể đọc biểu đồ thiếu dữ liệu mà tưởng đầy đủ. Cờ denyPartialResponse buộc trả lỗi, đổi lấy tính sẵn sàng thấp hơn. [3][6]
vmstorage có trạng thái và khó co giãn, nên ước lượng ban đầu sai có thể kéo theo di dời dữ liệu. Bản cộng đồng không có downsampling hay nhiều chính sách lưu giữ, nên ai cần giữ nhiều năm dữ liệu độ phân giải giảm dần sẽ chạm ranh giới thương mại. [7]
Hệ thống không thay sổ cái nghiệp vụ hay hồ sơ hợp đồng bảo hiểm cần lưu theo quy định. Các mẫu docker-compose có tài khoản mặc định, không dùng nguyên trạng ngoài môi trường thử. [5]
Về giới hạn nghiên cứu: không có số đo hiệu năng riêng, chưa kiểm tra tương thích phiên bản Grafana hay Kubernetes cụ thể, chưa đọc trang bảo mật ngoài kho mã, và nguồn chỉ bằng tiếng Anh.
Thử nghiệm sáu tuần với tải đại diện và tiêu chí thoát rõ ràng
Tuần 1 và 2: dựng single-node và một vmagent ở môi trường thử, chạy song song hệ thống hiện có, nạp số liệu của một nhóm dịch vụ như cổng báo giá. Tiêu chí hoàn thành: các bảng điều khiển trọng yếu dựng lại được và truy vấn cốt lõi cho cùng kết luận với hệ thống cũ trong ngưỡng sai khác đội tự định trước.
Tuần 3 và 4: đo trên tải thật. Theo dõi CPU, RAM, đĩa của kho, tốc độ tăng dung lượng theo ngày và độ trễ của một bộ truy vấn chuẩn; dùng phép ngoại suy dung lượng của tài liệu để dự báo thời hạn lưu giữ. [6] Ngắt kết nối kho ngắn hạn để thử hai chế độ đệm của vmagent và ghi lại lượng dữ liệu thiếu sau khi khôi phục. [3][9]
Tuần 5: thử sự cố có kiểm soát. Dừng tiến trình kho, khôi phục từ bản sao lưu và so thời gian khôi phục thực tế với mục tiêu. Rà soát toàn bộ nhãn để bảo đảm không có định danh khách hàng. [6][9]
Tuần 6: quyết định. Đạt khi mất dữ liệu trong ngưỡng cho phép lúc kho ngừng ngắn, thời gian khôi phục đạt mục tiêu, không có nhãn dữ liệu cá nhân và công vận hành nằm trong mức thống nhất. Dừng khi cần tính năng Enterprise chưa có ngân sách hoặc chi phí vận hành vượt lợi ích. Mọi ngưỡng do đội định trước.
Điều đọng lại: bắt đầu nhỏ, đo thật, đọc kỹ tên tệp tải về
VictoriaMetrics đáng vào danh sách rút gọn khi doanh nghiệp xây hoặc mở rộng giám sát theo hướng Prometheus. Điểm mạnh được tài liệu xác nhận là đa dạng giao thức nạp, bản một nút đơn giản và bộ công cụ vmagent, vmalert, vmauth. Điểm cần cẩn trọng là nhân bản không thay sao lưu, cụm có trạng thái khó co giãn và ranh giới giữa bản cộng đồng với Enterprise. [1][3][6][7]
Với công ty môi giới bảo hiểm giả định, lộ trình hợp lý là đi từ single-node, giữ nhãn sạch dữ liệu cá nhân, đo bằng tải thật và chỉ nghĩ tới cụm hay Enterprise khi có bằng chứng từ chính hệ thống của mình, đúng tinh thần tài liệu cụm. [6]
Phát biểu về ưu thế hiệu năng trong README nên xem là khẳng định của nhà phát triển cho tới khi đội tự kiểm chứng. Dự án thay đổi nhanh, nên bài chỉ là một lát cắt tại một commit.
Nguồn, commit và giới hạn của nghiên cứu
VictoriaMetrics được chọn từ kho lưu trữ danh sách GitHub Trending của một dự án bên thứ ba: 11 lần xuất hiện từ 7/1/2026 đến 19/7/2026 ở danh sách Go, trang đầu tiên ghi vị trí 20 ngày 7/1/2026. [10] Kho lưu trữ đó chỉ gồm danh sách Python, Go, JavaScript và Swift, thiếu ngày 3/9/2026 và 12/10/2026, nên không phải top 100 chính thức của GitHub.
Mã được ghim ở commit 2dcf2265734e00e0f6f4e42a3d0a6beedec0e5b6 (9/10/2026), kiểm tra ngày 12/10/2026. Đã đọc README, LICENSE, SECURITY.md, hướng dẫn vm-architectures, README docker, và bốn tài liệu bổ sung ở cùng commit: cluster, Enterprise, khái niệm chính, vmagent. [1][2][3][4][5][6][7][8][9] Dữ liệu GitHub API cho thấy kho chưa bị lưu trữ và bản phát hành mới nhất lúc thu thập là v1.153.0.
Đây là nghiên cứu tại bàn, không phải công bố khoa học bình duyệt. Không cài, chạy hay đo phần mềm; tình huống ở Việt Nam là đề xuất giả định. Nội dung kho mã được coi là dữ liệu tham khảo, không phải chỉ dẫn.
Xem mã nguồn VictoriaMetrics trên GitHub