Cardinality metrics là số lượng chuỗi đo khác nhau phát sinh từ tên metric và các tổ hợp nhãn của nó. Một nhãn như trạng thái xử lý có thể chỉ có vài giá trị, nhưng customer_id hoặc URL chứa mã đơn hàng có thể tăng liên tục. Thêm chi tiết để dễ tìm lỗi đôi khi làm hệ thống giám sát phình lớn và khó vận hành hơn chính phần mềm đang được theo dõi.
Cardinality metrics tăng từ tổ hợp nhãn
Nếu một metric có nhiều nhãn, số tổ hợp có thể tăng nhanh khi miền giá trị của từng nhãn mở rộng. Số thực tế phụ thuộc những tổ hợp xuất hiện, không nhất thiết bằng tích tối đa. Vì vậy cần phân biệt ước tính trên thiết kế với số series thực tế đã quan sát. Không nên đưa một công thức vào báo cáo rồi coi đó là dung lượng hoặc chi phí đã đo.
Tài liệu thực hành instrumentation của Prometheus khuyến cáo tránh nhãn cardinality cao. Đây là nguyên tắc giúp thiết kế đo lường có thể kiểm soát, không phải lệnh bỏ mọi chiều phân tích. Câu hỏi đúng là nhóm nào cần để ra quyết định vận hành, miền giá trị có được giới hạn và ai chịu trách nhiệm khi miền đó thay đổi.
Sổ nhãn trước khi thêm metric mới
| Nhãn dự kiến | Miền giá trị | Quyết định cần xem xét |
|---|---|---|
| operation | Danh sách thao tác được duyệt | Dùng tên thao tác, không toàn URL |
| outcome | Nhóm kết quả ổn định | Không dùng nguyên văn lỗi |
| customer_id | Tăng theo khách hàng | Không đưa trực tiếp vào metric chung |
| request_id | Gần như mỗi request một giá trị | Điều tra qua kênh chi tiết phù hợp |
Sổ cần ghi tên metric, mục đích, từng label, danh sách hoặc giới hạn giá trị, người sở hữu và cách kiểm tra tăng trưởng. Với đường dẫn API, mẫu route như /orders/{id} thường có ý nghĩa tổng hợp hơn URL thật chứa từng mã đơn. Tuy nhiên phải thực hiện chuẩn hóa đúng tầng; không dùng thay chuỗi thiếu kiểm soát rồi gộp nhầm các thao tác khác nhau.
Ví dụ giả định: metric thời gian xử lý đơn
Một nhóm muốn biết thao tác tạo đơn có chậm không và khách nào gặp lỗi. Nếu thêm cả customer_id, order_id và nguyên văn lỗi làm label, mỗi biến thể có thể tạo thêm series. Thiết kế thay thế là metric tổng hợp theo operation và outcome có giới hạn, còn request hoặc order cụ thể được tra cứu qua log/trace có quyền truy cập thích hợp.
Phương án này không có nghĩa mọi log đều được phép giữ ID thật. Cần áp dụng quy tắc dữ liệu, che thông tin nhạy cảm và thời hạn lưu của kênh đó. Chuyển từ metric sang log chỉ đổi nơi lưu chi tiết, không tự giải quyết vấn đề riêng tư hay chi phí. Ví dụ là một lựa chọn thiết kế cần cân nhắc, không phải hệ thống đã triển khai.
Giữ được khả năng điều tra sau khi giảm nhãn
Trước khi bỏ một label, hãy xem dashboard, alert hoặc quy trình hỗ trợ nào đang dùng nó. Nếu người vận hành cần tìm một giao dịch cụ thể, phải có đường liên kết sang bằng chứng phù hợp. Không xóa chiều phân tích rồi tuyên bố tối ưu thành công trong khi đội hỗ trợ mất khả năng xác định lỗi của khách.
Nhãn lỗi nên là nhóm mã ổn định, không phải câu thông báo có timestamp hoặc dữ liệu đầu vào. Khi một phiên bản phần mềm bổ sung giá trị mới, cần cập nhật sổ nhãn và kiểm tra tác động. Cả dữ liệu do người dùng kiểm soát lẫn giá trị sinh từ hệ thống đều có thể làm miền nhãn mở rộng ngoài dự kiến.
Quan sát số thực, không hứa tiết kiệm theo giả định
Đo số series đang hoạt động và xu hướng trước/sau theo cùng phạm vi nếu có quyền và công cụ sẵn có. Phân biệt series cũ còn tồn tại do thời hạn lưu với series mới được tạo. Việc sửa instrumentation hôm nay không nhất thiết làm mọi số trên dashboard giảm ngay lập tức. Không quy đổi sang chi phí nếu chưa biết cách tính của hệ thống đo.
Tiêu chí nghiệm thu nên gồm miền label hợp lệ, hành vi với giá trị lạ, dashboard/alert vẫn hoạt động và đường điều tra chi tiết được giữ. Những mục này là checklist đề xuất, không phải benchmark đã chạy. Với một tích hợp cần trao đổi cùng Onter, sổ metric và nhu cầu điều tra cụ thể giúp xác định phần cần sửa mà không mở một dự án giám sát mới ngoài phạm vi.
Đọc thêm theo vấn đề liên quan: Audit log cần gì để điều tra mà không lưu thêm bí mật?.
Đọc thêm theo vấn đề liên quan: Bàn giao sự cố: sổ quyết định quan trọng hơn một chuỗi tin nhắn dài.
Trao đổi phạm vi phát triển và tích hợp tại dịch vụ gia công phần mềm Onter. Tài liệu mẫu cần được che thông tin nhạy cảm trước khi chia sẻ.
Nguồn kỹ thuật
Tài liệu chính thức cho chủ đề cardinality metrics. Quy trình, bảng kiểm và ví dụ trong bài là đề xuất biên tập; chưa phải log triển khai hay chứng nhận sản phẩm.
