Access Hub Collector
Đồng bộ từ mã nguồn lúc 10:57, 03/10/2026
Access HubDeveloper

Giao diện

accesshub.vnMở Access Hub
Sửa trang nàyBáo lỗi tài liệuLên đầu trang
ADR 0017Đề xuất

ADR 0017: Cụm VictoriaMetrics cho hệ thống Cloud ​

Hệ thống Cloud lưu số liệu giám sát trên cụm VictoriaMetrics (vminsert, vmstorage, vmselect, -replicationFactor=2), mỗi vùng một collector logic, mở rộng bằng cách thêm node trong cụm. Một node đơn vẫn hợp lệ cho dev và on-prem nhỏ (dưới khoảng 10.000 máy).

Ngày quyết định
02/10/2026
Chấp nhận
Chưa
Phạm vi
Collector
Người chấp nhận
Chưa có
  1. Đề xuất02/10/2026
  2. Chấp nhậnĐang chờ

1. Tiêu đề quyết định (Title) ​

Hệ thống Cloud lưu số liệu giám sát trên cụm VictoriaMetrics (vminsert, vmstorage, vmselect, -replicationFactor=2), mỗi vùng một collector logic, mở rộng bằng cách thêm node trong cụm. Một node đơn vẫn hợp lệ cho dev và on-prem nhỏ (dưới khoảng 10.000 máy).

2. Trạng thái (Status) ​

Đề xuất (Proposed) ngày 02/10/2026, hướng đi do Product Owner (Thiện Phan Ngọc) quyết định ngày 02/10/2026. Phần kỹ thuật chờ Enterprise Architect và Solution Architect duyệt, và chờ đo trên cụm thật (COL-15). Mọi điểm đánh dấu "cần kiểm chứng" dưới đây chưa được thử với mã hoặc cụm thật, chỉ dựa trên tài liệu chính thức của VictoriaMetrics: https://docs.victoriametrics.com/victoriametrics/cluster-victoriametrics/ .

3. Ngữ cảnh (Context) ​

  • docs/08-scaling-ha.md: một node VM chịu đến khoảng 10.000 máy, trên đó cần cụm. ADR 0014 giữ VictoriaMetrics, ADR 0016 thêm nhãn ah_day và janitor xóa theo ngày.
  • Nhãn ah_day làm số series lịch sử tăng theo số ngày lưu: series = máy x series mỗi máy x số ngày lưu. Ví dụ 10.000 máy x 70 series x 90 ngày = 63 triệu series-ngày (một công ty Business 2.000 máy: 12,6 triệu). Đo trên dev (ADR 0016 mục 7): 4.002 series x 7 ngày = 28.014 series-ngày tốn 1.440 KiB chỉ mục, tức khoảng 50 byte mỗi series-ngày. Ngoại suy: khoảng 3 GB chỉ mục cho 63 triệu series-ngày, nhân hai khi nhân bản. Con số này chỉ là bậc độ lớn, cần kiểm chứng ở quy mô lớn.
  • Mỗi nửa đêm UTC mọi series "xoay" sang series mới (ADR 0016: 700.000 series ở 10.000 máy mất khoảng 5 giây trên một node). Cụm phải chịu được đợt này.
  • Chủ sở hữu quyết định (02/10/2026): không tách collector theo nhóm khách hàng (cá nhân hay tổ chức). Nâng gói giữ nguyên company_id, nên không có di chuyển dữ liệu khi đổi gói.
  • Retention theo gói do collector tự áp (đọc cắt, ghi khóa, janitor xóa theo ngày), không cần retention theo tenant của VictoriaMetrics Enterprise.

4. Quyết định (Decision) ​

  1. Hai cụm riêng cho hai kho. vm-raw (mẫu thô, 30 ngày) và vm-long (rollup, 400 ngày) là hai cụm độc lập, vì -retentionPeriod đặt trên từng vmstorage và mỗi cụm cần một retention (tài liệu cụm không nói rõ giá trị này là toàn cụm, cần kiểm chứng). Hai cụm cùng kiểu, khác dung lượng và retention.
  2. Thành phần mỗi cụm. Tối thiểu 3 vmstorage (-replicationFactor=2 cần ít nhất 2N-1 = 3 node để chịu mất 1 node mà vẫn đủ bản sao), 2 vminsert và 2 vmselect sau bộ cân tải. vminsert và vmselect không trạng thái, thêm node tùy ý.
  3. Tenant của VictoriaMetrics. Dùng một accountID cố định (0) cho toàn bộ dữ liệu. Cô lập giữa các công ty vẫn bằng nhãn company_id do collector gắn và cắt ở mọi truy vấn (không đổi so với ADR 0016). Không ánh xạ công ty sang accountID: không thêm được retention theo tenant (chỉ Enterprise) và làm thao tác janitor phức tạp hơn.
  4. Một collector logic mỗi vùng. Collector (ingest, worker, admin) vẫn chung một địa chỉ ghi và một địa chỉ đọc trỏ vào cụm. Mở rộng bằng thêm vmstorage (dữ liệu mới phân bổ sang node mới, dữ liệu cũ ở yên), thêm vminsert hoặc vmselect, thêm node ingest và worker như docs/08. Không cần thêm collector khi chỉ hết dung lượng kho.
  5. vmalert và rollup. Một vmalert (hoặc hai instance HA như docs/14 mục 5) đọc từ vmselect của vm-raw và ghi vào vminsert của vm-long, luật rollup giữ nguyên (sinh từ catalog bằng collector -rollup-rules). Chống trùng ở vm-long bằng -dedup.minScrapeInterval trên vmstorage (cần kiểm chứng cờ này ở bản cụm đang dùng).
  6. Janitor và purge trên cụm. Xem mục 5 (đặc tả thao tác).
  7. Dev và on-prem nhỏ. Giữ một node VM cho mỗi kho. Mã collector chỉ biết địa chỉ ghi, địa chỉ đọc (và xóa) và danh sách vmstorage quản trị, nên node đơn chạy bằng cách cho cả ba trỏ vào cùng một process.
  8. Chuyển từ node đơn sang cụm theo runbook docs/14 mục 12.1. Chuyển công ty giữa các collector theo docs/14 mục 12.2.

5. Đặc tả thao tác janitor và purge trên cụm ​

Địa chỉ theo tài liệu chính thức, accountID = 0:

ViệcNode đơnCụm
Ghi (JSON line)POST /api/v1/importPOST http://<vminsert>:8480/insert/0/prometheus/api/v1/import
Đọc, xuất, liệt kê nhãn/api/v1/query_range, /api/v1/export, /api/v1/label/<tên>/valueshttp://<vmselect>:8481/select/0/prometheus/api/v1/... (cùng hậu tố)
Xóa series/api/v1/admin/tsdb/delete_series?match[]=...http://<vmselect>:8481/delete/0/prometheus/api/v1/admin/tsdb/delete_series?match[]=...
Gộp ép phân vùng/internal/force_mergehttp://<vmstorage>:8482/internal/force_merge trên từng vmstorage
  • Bộ chọn xóa không đổi: janitor xóa {company_id="...", ah_day=~"..."}, purge server xóa {company_id="...", server_id="..."}, purge công ty xóa {company_id="..."}. Luôn có company_id (kiểm thử hai tenant ở internal/retention, internal/purge, deploy/dev/vmcheck phải chạy lại trên cụm).
  • Xóa đi qua vmselect, không qua vminsert. Cấu hình collector cần phân biệt địa chỉ ghi, địa chỉ đọc và xóa, và danh sách vmstorage cho force_merge (tên khóa cấu hình chốt khi làm COL-15). Proxy phía trước cụm phải cho qua các đường dẫn xóa, xuất, liệt kê nhãn ở trên.
  • Janitor chạy force_merge lần lượt từng vmstorage, tối đa một lần mỗi ngày như hiện nay, tránh làm nhiều node merge cùng lúc (tốn IO). Thứ tự và thời gian chờ giữa các node cần đo.
  • Lỗi một phần: delete_series trên cụm khi có vmstorage ngừng hoặc khi nhân bản chưa đủ có thể xóa chưa hết các bản sao. Janitor coi mọi phản hồi khác 2xx là lỗi, không đánh dấu ngày đã xóa, và thử lại ở lượt quét sau (xóa idempotent). Hành vi chính xác của vmselect khi một vmstorage vắng mặt lúc xóa cần kiểm chứng trên cụm thật, kể cả việc phản hồi 2xx có đảm bảo đã xóa ở mọi bản sao hay không.
  • Purge server và công ty (COL-11): vẫn ghi bia mộ trước, xóa, rồi xóa lần hai sau một khoảng chờ. Khoảng chờ hiện là 10 giây vì bộ đệm ghi của một node. Trên cụm, mẫu còn nằm trong bộ đệm của vminsert và vmstorage nên khoảng chờ phải đo lại, giá trị mặc định cho cụm cần kiểm chứng (tạm giữ 10 giây và để cấu hình được). Bia mộ ở collector vẫn là chốt chặn chính (worker bỏ lô còn trên bus).
  • Lưới an toàn giữ nguyên (ADR 0016 mục 4.5): không xóa khi Access Hub lỗi hoặc không trả lời, không xóa gì trẻ hơn 1 ngày, không xóa công ty mới thấy chưa đủ 24 giờ, nhớ retention lớn nhất thấy trong 30 ngày (Redis) và giữ ít nhất mức đó, chế độ dry_run. Thêm: không xóa khi cụm báo thiếu node (cần kiểm chứng cách phát hiện: số vmstorage khả dụng nhỏ hơn số cấu hình), để tránh xóa một phần khi trạng thái cụm chưa rõ.
  • Chuyển dữ liệu cũ không có nhãn ngày (ADR 0016 mục 4.6): thực hiện trên node đơn trước khi chuyển sang cụm, để cụm chỉ nhận dữ liệu đã có nhãn ngày.

6. Cơ sở lý luận (Rationale) ​

  • Đây là đường nâng cấp đã có trong docs/08 và ADR 0014, không đổi mô hình dữ liệu, giao thức hay Access Hub. Access Hub chỉ gọi API collector, không biết kho nằm ở đâu.
  • Tách kho khỏi collector cho phép mở rộng dung lượng và hiệu năng ghi mà không động đến dữ liệu hay đăng ký agent, khác với thêm collector (mỗi collector có kho riêng, chuyển công ty phải chuyển dữ liệu).
  • Retention theo gói đã giải quyết ở tầng collector (nhãn ngày), nên cụm OSS là đủ, không cần Enterprise.

7. Phương án đã cân nhắc (Alternatives) ​

Phương ánKết luận
A. Giữ node đơn, lên cấu hình lớn hơnChỉ chịu đến khoảng 10.000 máy, một điểm lỗi duy nhất, không HA. Giữ cho dev và on-prem nhỏ
B. Nhiều instance chia theo tenantTỉ lệ nhân bản theo số khách, mỗi lần chuyển công ty phải chuyển dữ liệu, truy vấn phải định tuyến. Không chọn
C. Nhiều collector theo nhóm khách hàng (cá nhân, tổ chức)Chủ sở hữu loại bỏ (02/10/2026): không tách pool theo loại khách, việc nâng gói cá nhân lên tổ chức tại chỗ sẽ buộc phải chuyển dữ liệu
D. Cụm VictoriaMetrics, một collector logic mỗi vùng (chọn)Mở rộng trong cụm, dữ liệu đổi gói không di chuyển, HA bằng nhân bản 2
E. Cụm đa tenant bằng accountID mỗi công tyKhông có retention theo tenant ở bản OSS, xóa theo tenant vẫn phải dùng delete_series. Không chọn

8. Ảnh hưởng (Consequences) ​

  • Tích cực: HA (mất 1 vmstorage vẫn đọc và ghi), mở rộng ngang, Hub và agent không đổi.
  • Tiêu cực: thêm thành phần vận hành (6 đến 10 tiến trình mỗi cụm), chi phí chỉ mục của nhãn ngày phải tính trước, janitor và purge phải viết lại phần địa chỉ và force_merge từng node, chuyển node đơn sang cụm cần cutover (mục 4.8).
  • Rủi ro mở: hành vi xóa khi thiếu node, độ trễ của bộ đệm ghi trên cụm, cờ -dedup.minScrapeInterval ở vm-long (mục 5).

9. Tài liệu liên quan (Related) và phê duyệt (Approval) ​

docs/08-scaling-ha.md mục 3 và 6, docs/11-roadmap.md COL-15 và COL-18, docs/14-production-deployment-guide.md mục 5, 12.1 và 12.2, ADR 0014, 0015, 0016.

Vai tròNgườiNgày
Product Owner (hướng đi: cụm cho Cloud, không tách theo nhóm khách)Thiện Phan Ngọc02/10/2026
Enterprise Architectchưa chỉ định
Solution Architectchưa chỉ định
Trang này có giúp được bạn không?
Sửa trang này

Nội dung đồng bộ từ kho mã access-hub-collector lúc 10:57, 03/10/2026. Khi tài liệu và mã khác nhau, mã thắng.