Integrated Gauges: Lessons Learned Monitoring Seastar's IO Stack

ScyllaDB · 2026 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc

Bài kỹ thuật của nhà cung cấp, rút từ việc giám sát IO stack của Seastar (cùng mảng với series I/O ScyllaDB 2026). Không có số liệu production, chỉ có dữ liệu tổng hợp và ảnh dashboard.

Bối cảnh

• Hệ giám sát kiểu scrape (Prometheus) chỉ lấy một điểm mỗi chu kỳ. Với giá trị đổi hàng nghìn lần mỗi giây (độ dài hàng đợi, latency request) mà chu kỳ scrape tính bằng phút, điểm lấy được chỉ là ảnh chụp ngẫu nhiên: trúng lúc cao điểm thì cao, trúng lúc rảnh thì thấp. Trên dữ liệu tổng hợp, chỉ lấy 1/40 điểm đã méo hẳn; thực tế tỉ lệ còn nhỏ hơn nhiều.

Ba cách và đánh đổi

• Histogram: đếm quan sát vào các bucket, tính được p50/p99. Giàu thông tin nhất nhưng N bucket tốn gấp N lần một giá trị: RAM trên node, băng thông gửi đi, đĩa của hệ giám sát.
• Counter + rate() cho giá trị cộng được (latency): xuất hai counter tăng dần là tổng latency và số request đã xong; rate() từng cái rồi chia nhau ra latency trung bình trong chu kỳ. Số request bản thân đã có ích (IOPS), nên chi phí ngang một gauge mà ổn định hơn nhiều. Nhược điểm: gai ngắn hơn chu kỳ scrape bị nuốt mất.
• Integrated gauge cho giá trị không cộng được (độ dài hàng đợi): cộng dồn giá trị × thời gian giữ giá trị đó (diện tích dưới đường cong) vào một counter; rate() của counter chính là giá trị trung bình theo thời gian trong chu kỳ. Đơn vị kiểu "người-giờ" (bài so với action, impulse, absement trong vật lý).

Áp dụng

• Đã đưa vào hàng đợi request theo class của IO stack Seastar (PR 3210). Trên dashboard so sánh:
  • Hàng đợi trong đĩa của compaction: bản scrape chỉ cho biết đĩa không rảnh; bản tích phân cho thấy tải đĩa giảm dần theo thời gian.
  • Hàng đợi commitlog: bản tích phân có một gai hình chữ nhật rõ rệt mà bản scrape hoàn toàn không thấy.
• Giá trị trung bình có phần thập phân (hàng đợi dài 0,3) là bình thường vì đó là trung bình trong vài phút.

Bài học cho SWE

• Gauge của giá trị dao động nhanh dễ nói dối; trước khi alert hay lập kế hoạch capacity theo nó, hỏi xem điểm scrape đại diện cho cái gì.
• Thứ tự cân nhắc theo chi phí: counter + rate() nếu cộng được → integrated gauge nếu không cộng được → histogram khi cần phân bố và đuôi.
• Đo trung bình theo thời gian vẫn mất gai ngắn; nếu gai quan trọng thì cần histogram hoặc max theo cửa sổ.
• Cách làm rẻ: chỉ là một counter thêm ở chỗ giá trị thay đổi, không cần hạ tầng mới (Observability và monitoring).

Liên quan

• ScyllaDB 2026 · ScyllaDB 2026
• Prometheus 2026 · ClickHouse 2025
• Observability và monitoring