Mở rộng và sẵn sàng cao
Mọi số trong tài liệu này là ước tính thiết kế và phải được kiểm chứng bằng kiểm thử tải (agentsim, xem 12-testing) trước khi cam kết.
1. Giả định cơ sở
- Chu kỳ gửi 30 giây, khoảng 70 series mỗi máy ở cấu hình chuẩn (thiết kế tối đa 200 series).
- Một request mỗi chu kỳ mỗi agent, khoảng 5 đến 10 KB sau nén.
- Khoảng 1 byte mỗi mẫu sau nén trong VictoriaMetrics, 2.880 mẫu mỗi series mỗi ngày.
2. Bảng cỡ tải
| Số máy | Request/giây | Mẫu/giây | Dung lượng TSDB thô/ngày | Ghi chú |
|---|---|---|---|---|
| 1.000 | 33 | 2,3 nghìn | khoảng 0,2 GB | Một node all dư sức |
| 5.000 | 167 | 11,7 nghìn | khoảng 1 GB | 2 đến 3 node ingest, 1 worker |
| 10.000 | 333 | 23 nghìn | khoảng 2 GB | 3 node ingest, 2 worker, JetStream, Redis HA |
| 50.000 | 1.667 | 117 nghìn | khoảng 10 GB | Cần cụm VM, nhiều collector hoặc phân shard theo tenant |
Với chu kỳ 60 giây, mọi số giảm một nửa. Chu kỳ 10 giây tăng gấp 3.
3. Điểm nghẽn và cách tháo
| Thành phần | Điểm nghẽn | Biện pháp |
|---|---|---|
ingest (CPU giải nén, giải mã, TLS) | Kết nối TLS, giải nén | Scale ngang sau load balancer, TLS terminate ở LB hoặc tại node, keep-alive, HTTP/2 |
| Registry (tra token) | Truy vấn Redis mỗi request | Cache trong bộ nhớ của node (LRU, TTL ngắn 30 giây) trước Redis, giảm tải Redis xuống rất thấp |
| Bus | Một node in-process không chịu được và không bền | JetStream GĐ 3, 64 shard logic, nhân bản 3 |
| Worker (ghi TSDB, đánh giá luật) | CPU, ghi remote-write | Chia shard theo hash(server_id) mod 64, thêm worker, mỗi worker sở hữu tập shard |
| TSDB | Ghi, cardinality (nhãn ah_day nhân số series với số ngày lưu), truy vấn | Single node đến khoảng 10 nghìn máy cho dev và on-prem nhỏ. Hệ thống Cloud dùng cụm (vminsert, vmstorage, vmselect, nhân bản 2) từ đầu, hai cụm vm-raw và vm-long, xem ADR 0017 |
| Redis | last_seen ghi liên tục | Gom ZADD theo lô mỗi giây ở mỗi node ingest, chỉ ghi khi thay đổi vượt ngưỡng |
| Access Hub | Bão seen, events, agents | Gom lô, không gọi theo từng request agent, giới hạn tốc độ riêng, chỉ trạng thái đổi mới gửi |
| Bão kết nối sau sự cố | Toàn bộ agent thử lại cùng lúc | Backoff full jitter, Retry-After, giữ chỗ khởi động theo hash(agent_id), ingest từ chối nhanh có kiểm soát |
4. Chia shard và sở hữu
- Shard logic cố định 64:
shard = hash(server_id) mod 64. ingestkhông trạng thái, chỉ đẩy lô lên bus theo shard.workerđăng ký tập shard quaah:collector:{id}heartbeat và thuê (lease) trong Redis. Khi một worker chết, shard được gán lại sau khi lease hết hạn (mặc định 15 giây), trạng thái đánh giá nạp từ snapshot Redis (mất tối đa 30 giây trạng thái, được bù bởi việc phát lại từ bus).- Với JetStream, consumer bền vững theo shard giữ vị trí đọc nên không mất mẫu khi đổi chủ.
5. Sẵn sàng cao (GĐ 3)
| Thành phần | Cách đạt HA | Hành vi khi mất |
|---|---|---|
ingest | N node sau LB có kiểm tra /readyz | Mất 1 node: LB chuyển, agent thử lại, không mất mẫu (agent giữ lô) |
worker | N node, lease shard | Shard được nhận lại trong vài chục giây, JetStream phát lại |
admin | 2 node | API nội bộ chuyển sang node còn lại |
| Redis | Sentinel hoặc Cluster (hoặc Valkey tương đương), 3 node | Mất master: chuyển đổi trong vài giây. Nếu mất hoàn toàn: ingest dùng cache trong bộ nhớ, tra Access Hub có giới hạn, tạm ngừng agent_down, đánh giá luật tiếp tục từ bộ nhớ |
| JetStream | 3 node, replicas: 3 | Mất 1 node: vẫn ghi được. Mất quorum: ingest trả 503 kèm Retry-After, agent đệm |
| VictoriaMetrics | Cluster, nhân bản -replicationFactor=2 | Mất 1 vmstorage: vẫn đọc và ghi. Mất TSDB toàn bộ: bus giữ tối thiểu 2 giờ (NFR-07) |
| Access Hub | Do nhóm Access Hub vận hành (MySQL Read/Write, nhiều node PHP) | Collector tiếp tục ingest bằng registry cache, outbox giữ sự kiện 24 giờ (NFR-08) |
| Sao lưu | Snapshot VM định kỳ, Redis RDB/AOF, cấu hình dạng mã | Khôi phục theo runbook (xem 09-deployment) |
Chế độ suy giảm có chủ đích: ưu tiên giữ dữ liệu số liệu hơn giữ cảnh báo chính xác. Khi hệ thống quá tải, ingest từ chối có kiểm soát (503) thay vì nhận rồi mất. Agent chịu được vì có đệm đĩa.
6. Nhiều collector và nhiều vùng
- Mở rộng dung lượng và tốc độ ghi trong cụm VictoriaMetrics (thêm
vmstorage,vminsert,vmselect, nodeingestvàworker) trước, không cần thêm collector (ADR 0017). Dữ liệu cũ ở yên, Access Hub và agent không đổi. - Chỉ thêm collector riêng cho khách rất lớn, yêu cầu tuân thủ hoặc vùng khác. Không tách collector theo loại khách hàng (cá nhân hay tổ chức) hay theo gói.
- Mỗi công ty (hoặc mỗi vùng) có thể được gán một collector riêng qua
monitoring_collectorsvàmonitoring_agents.collector_id. Chuyển công ty giữa collector:docs/14mục 12.2. - Agent nhận
collector_urltrong cấu hình từ xa, nên có thể di chuyển agent giữa các collector bằng cách đổi cấu hình, không cần cài lại. - Mỗi collector có TSDB và Redis riêng. Truy vấn từ Access Hub được định tuyến theo
collector_idcủaServerliên quan. - Cô lập theo tenant lớn: gán riêng một cụm cho công ty rất lớn hoặc có yêu cầu tuân thủ.
7. Giới hạn và bảo vệ chống quá tải
| Cơ chế | Mô tả |
|---|---|
| Hàng đợi bus có giới hạn | Đầy thì ingest trả 503 |
| Tốc độ theo agent | Token bucket trong bộ nhớ node (chính xác xấp xỉ) và Redis cho phạm vi cụm |
| Tốc độ theo công ty | Tùy chọn, tránh một công ty chiếm hết dung lượng |
| Giới hạn kết nối đồng thời | Theo node, kèm thời gian chờ đọc header và body |
| Giới hạn ghi TSDB | Gom lô, số lần thử lại giới hạn, không thử lại vô hạn |
| Cầu chì (circuit breaker) | Quanh Access Hub, TSDB, Redis, để không kéo sập cả tiến trình |
8. Kế hoạch kiểm thử tải
Bộ mô phỏng agentsim tạo N agent ảo (mục tiêu 10.000 trên 1 đến 2 máy), thực hiện enroll, gửi metrics đúng chu kỳ có jitter, mô phỏng lỗi mạng và thu hồi. Kịch bản: tăng tải theo bậc (1k, 5k, 10k, 20k), soak 24 giờ, khởi động đồng loạt (thundering herd), mất Redis, mất TSDB, mất Access Hub, mất một node ingest, thu hồi 1.000 agent cùng lúc. Tiêu chí ở NFR-01 và các NFR liên quan. Kết quả ghi lại và cập nhật bảng ở mục 2.