ADR 0014: Giữ VictoriaMetrics làm kho chuỗi thời gian ở giai đoạn hiện tại
1. Tiêu đề quyết định (Title)
Tạm thời giữ VictoriaMetrics (bản mã nguồn mở, hai instance vm-raw và vm-long) làm kho chuỗi thời gian, chưa xây kho tích hợp sẵn trong collector và chưa chuyển sang kho khác.
2. Trạng thái (Status)
Chấp nhận (Accepted) ngày 01/10/2026 bởi Product Owner, giữ VictoriaMetrics ở giai đoạn hiện tại. Bổ sung, không thay thế ADR 0005. Số liệu hiệu năng ghi xem ADR 0015 mục 6.
Ngày quyết định: 30/09/2026 (người dùng: "tạm thời cứ giữ VictoriaMetrics vậy, em cài lên để chạy xem").
3. Ngữ cảnh (Context)
- ADR 0005 chọn VictoriaMetrics, kèm điều kiện "kiểm chứng lại giới hạn OSS ở spike S3" (chưa làm).
- Có ý kiến cân nhắc kho tích hợp (lite store) để giảm phụ thuộc. Người dùng quyết định chưa làm và chạy thử VictoriaMetrics thật trước.
- VictoriaMetrics đã được cài và chạy ở dev cùng vmalert (ADR 0013).
- Giới hạn bản OSS: một retention mỗi instance, không downsampling, retention toàn cụm không theo công ty (ADR 0005, R11).
4. Quyết định (Decision)
Giữ VictoriaMetrics single node: vm-raw (thô, 30 ngày) và vm-long (rollup 5 phút và 1 giờ, 400 ngày qua vmalert). Không xây kho tích hợp sẵn trừ khi người dùng yêu cầu. Truy cập kho chỉ qua giao diện tsdb.Writer và tsdb.Query trong collector, để việc đổi kho về sau khoanh vùng trong internal/tsdb.
Phạm vi: Collector, giai đoạn 1 đến 2 trở đi cho tới khi một điều kiện xem xét lại (mục 6) xảy ra.
5. Cơ sở lý luận (Rationale)
Chi tiết và so sánh nhiều phương án ở báo cáo lựa chọn TSDB. Tóm tắt:
- Đã tích hợp và chạy thật ở dev, vận hành đơn giản nhất, nén tốt, không phí bản quyền.
- Kho tích hợp sẵn tốn công xây và bảo trì, chưa có nhu cầu chứng minh.
- Hạn chế OSS đã có cách xử lý bằng hai instance.
Nhược điểm chấp nhận được:
- Chưa kiểm thử tải VM thật ở quy mô mục tiêu (spike S3, X-7, X-9).
- Không cô lập tenant ở tầng kho (cô lập nằm ở collector, NFR-12), không xác thực, chưa TLS đến VM ở thiết kế sản xuất (báo cáo ANBM, S-06).
- Mã đã gắn với API nhập JSON của VM (ADR 0015), đổi kho tốn công hơn thiết kế remote-write ban đầu.
6. Ảnh hưởng (Consequences)
- Tích cực: đi nhanh, ít thành phần.
- Rủi ro: R11, R18, R2 (xem
docs/13). - Điều kiện xem xét lại: spike S3 không đạt NFR-01; retention theo từng công ty thành bắt buộc; cần downsampling nhiều độ phân giải mà hai instance không đáp ứng; vượt 50.000 agent (cần VM cluster, chưa thử); giấy phép hoặc chính sách nhà cung cấp thay đổi.
- Việc tiếp theo: chạy spike S3, thêm sao lưu snapshot theo lịch, đo dung lượng thực tế (R18), thiết kế TLS và xác thực đến VM cho sản xuất.
7. Các phương án được đánh giá (Considered Options)
| Phương án | Ưu điểm | Nhược điểm | Kết luận |
|---|---|---|---|
| VictoriaMetrics (hai instance, vmalert) | Đơn giản, nén tốt, đã chạy | Hạn chế OSS, chưa thử tải | Chọn (đề xuất) |
| Prometheus cộng Thanos hoặc Mimir | Chuẩn mở, hệ sinh thái | Nhiều thành phần (chung, chưa kiểm chứng) | Không chọn lúc này |
| TimescaleDB | SQL, retention và rollup theo bảng | Thêm PostgreSQL, viết lại bộ ghi | Không chọn lúc này |
| ClickHouse | Rất lớn, phân tích mạnh | Công nghệ mới, viết lại | Không chọn lúc này |
| Kho tích hợp sẵn trong collector | Ít phụ thuộc ngoài | Tốn xây dựng, không mở rộng | Không chọn, chỉ xây khi được yêu cầu |
8. Tài liệu liên quan (Related Artifacts)
- Báo cáo lựa chọn TSDB
- ADR: 0005, 0015, 0013
docs/04-data-model.md,docs/13-risks-open-questions.md(S3, R11, R18)- Báo cáo ANBM
9. Phê duyệt (Approvals)
| Tên | Vai trò | Ghi chú |
|---|---|---|
| chưa chỉ định | Enterprise Architect | Chưa duyệt |
| chưa chỉ định | Solution Architect | Chưa duyệt |
| Thiện Phan Ngọc | Product Owner | Chấp nhận 01/10/2026 |