Lưu bao lâu là đủ

Phần trước đã cộng tổng chi phí của việc quan sát: 12,9% thông lượng và hàng chục gigabyte mỗi ngày. Câu hỏi kế tiếp là câu mà mọi đội đều phải trả lời và hầu như không đội nào trả lời bằng số: giữ dữ liệu đó bao lâu? Bài này đo hai vế của câu hỏi — chi phí lưu và chi phí truy vấn — rồi nói rõ vế nào tôi không đo được.

Bảng số liệu

Prometheus 2.54.1 với 900 chuỗi. Phần truy vấn đo trực tiếp; phần dung lượng ngoại suy từ 2,16 byte mỗi mẫu — con số đo được ở phần 19 của sê-ri này.

Chi phí truy vấn theo độ dài khoảng xem (bước cố định 15 giây):

Chi phí lưu trữ theo chu kỳ thu thập:

Và theo thời gian giữ (chu kỳ 15 giây):

Điều đáng nhớ

Dung lượng tăng tuyến tính, chi phí truy vấn tăng dưới tuyến tính. Khoảng xem gấp 6 lần chỉ làm thời gian truy vấn gấp 2,4 lần và dữ liệu trả về gấp 2,6 lần, vì mỗi truy vấn có một khoản chi phí cố định không đổi.

Hệ quả thực dụng: giữ dữ liệu lâu hơn không làm bảng điều khiển hằng ngày chậm đi. Truy vấn một giờ gần nhất tốn như nhau dù kho có bảy ngày hay một năm dữ liệu. Giữ lâu chỉ làm hoá đơn dài ra.

Đòn bẩy lớn nhất không phải thời gian giữ — mà là chu kỳ thu thập. Từ 1 giây sang 15 giây giảm 15 lần dung lượng, và với phần lớn chỉ số thì độ phân giải 15 giây là quá đủ. So sánh: rút thời gian giữ từ 90 ngày xuống 30 ngày chỉ tiết kiệm 3 lần, và bạn mất khả năng so sánh với quý trước.

Đòn bẩy lớn thứ hai là gộp. Cùng một khoảng xem 3 phút, truy vấn gộp trả về 2,4 KB còn truy vấn không gộp trả về 484,3 KB — gấp 202 lần. Phần 18 đã đo rằng gộp không làm Prometheus nhẹ đi, nhưng nó cứu băng thông và trình duyệt đúng theo tỷ lệ này.

Vì sao

Prometheus lưu dữ liệu thành các khối theo khoảng thời gian, mỗi khối tự chứa chỉ mục riêng. Truy vấn một giờ gần nhất chỉ chạm khối gần nhất; các khối cũ hơn không được mở ra. Đó là lý do thời gian giữ không ảnh hưởng tới truy vấn ngắn — chúng ở những tệp khác nhau.

Chi phí cố định của mỗi truy vấn gồm phân tích biểu thức, tra chỉ mục để tìm chuỗi khớp, và dựng phản hồi JSON. Với khoảng xem ngắn, phần cố định đó chiếm phần lớn thời gian; đó là lý do đường cong dưới tuyến tính.

Về dung lượng thì không có gì cứu được: mỗi mẫu là 2,16 byte, số mẫu bằng số chuỗi nhân số lần thu thập, và cả hai đều tuyến tính. Không có điểm gãy kỹ thuật nào để bám vào — không có ngưỡng mà sau đó việc giữ thêm trở nên đắt bất thường hay rẻ bất thường.

Điều đó có nghĩa là quyết định "giữ bao lâu" hoàn toàn là quyết định về giá trị, không phải về kỹ thuật. Kỹ thuật chỉ cho bạn giá; nó không cho bạn câu trả lời.

Nghĩa là gì trong thực tế

• Sửa chu kỳ thu thập trước khi sửa thời gian giữ. Đây là cách tiết kiệm rẻ nhất về mặt thông tin mất đi. Với chỉ số có đột biến ngắn thì hãy cẩn thận — phần 33 đã đo rằng chu kỳ thưa giấu mất đỉnh.
• Chọn thời gian giữ theo chu kỳ ra quyết định của đội. Nếu bạn xem lại chỉ số theo quý thì cần 90 ngày; nếu chỉ dùng để gỡ sự cố thì 7–14 ngày là đủ và rẻ hơn mười lần.
• Đừng giữ mọi thứ cùng một khoảng. Chỉ số hạ tầng thô có thể giữ 7 ngày; chỉ số cấp SLO nên giữ hàng năm vì chúng là cái bạn báo cáo. Prometheus không hỗ trợ điều đó trực tiếp, nhưng các hệ lưu trữ dài hạn thì có.
• Ước lượng trước khi bật. 900 chuỗi × chu kỳ 15 giây = 10,7 MB mỗi ngày. Nhân với số chuỗi thật của bạn — phần 11 đã đo rằng một Histogram gắn nhãn sai có thể nhân số chuỗi lên hàng nghìn lần, và đó mới là thứ làm hoá đơn nổ chứ không phải thời gian giữ.

Chỗ tôi không kết luận được

Đây là hạn chế lớn nhất của bài này và tôi đặt nó lên đầu: khoảng xem lớn nhất tôi đo được chỉ là 3 phút. Prometheus của tôi chỉ tích được 200 giây dữ liệu, nên tôi không có cách nào đo một truy vấn 30 ngày trên kho một năm — đúng câu hỏi mà bài này đặt ra.

Cái tôi đo được là hình dạng của đường cong ở quy mô nhỏ: dưới tuyến tính, với chi phí cố định đáng kể. Cái tôi suy ra — rằng giữ lâu không làm truy vấn ngắn chậm đi — dựa trên cơ chế (Prometheus chia khối theo thời gian) chứ không dựa trên phép đo. Đó là suy luận, và tôi trình bày nó như suy luận.

Toàn bộ bảng dung lượng là ngoại suy. Con số 2,16 byte mỗi mẫu là thật, đo ở phần 19, nhưng mọi dòng trong bảng "giữ bao lâu" là phép nhân chứ không phải phép đo. Tỷ lệ nén thực tế phụ thuộc vào dữ liệu — chuỗi nhảy loạn nén kém hơn nhiều — nên các con số đó nên đọc là bậc độ lớn, không phải dự toán.

Tôi không đo chi phí của compactor. Prometheus định kỳ gộp các khối nhỏ thành khối lớn, và việc đó tốn CPU và I/O tỷ lệ với lượng dữ liệu đang giữ. Đó là một khoản chi phí thật của việc giữ lâu mà bảng của tôi hoàn toàn bỏ qua.

Và tôi không đo được vế "giá trị". Chủ đề của phần này là giá trị theo tuổi dữ liệu, nhưng tôi không có cách nào đo khách quan việc một biểu đồ 60 ngày tuổi có ích hơn hay kém hơn một biểu đồ 7 ngày tuổi — điều đó phụ thuộc vào việc đội dùng nó làm gì. Tôi chỉ đo được vế chi phí, và tôi nói rõ ra thay vì bịa một mô hình giá trị rồi trình bày nó như số đo.

Thử ba mươi giây

# Ngan sach luu tru cua chinh Prometheus cua ban
P=http://localhost:9090

curl -s -G "$P/api/v1/query" --data-urlencode \
  'query=prometheus_tsdb_head_series' \
  | python3 -c 'import sys,json;r=json.load(sys.stdin)["data"]["result"];print("so chuoi        :", int(float(r[0]["value"][1])) if r else "?")'

curl -s -G "$P/api/v1/query" --data-urlencode \
  'query=rate(prometheus_tsdb_head_samples_appended_total[5m])' \
  | python3 -c '
import sys,json
r=json.load(sys.stdin)["data"]["result"]
if r:
    mps=float(r[0]["value"][1])
    ngay = mps*86400*2.16/1073741824
    print("mau moi giay    : %.0f" % mps)
    print("uoc %.2f GB moi ngay  ->  %.1f GB cho 30 ngay, %.1f GB cho 1 nam" % (ngay, ngay*30, ngay*365))
'

Ba dòng đó là toàn bộ hoá đơn của bạn. Nếu con số một năm làm bạn giật mình, hãy nhìn lại số chuỗi trước khi nhìn lại thời gian giữ — nó thường là biến sai.