Bốn lỗi bảng điều khiển tôi gặp thường xuyên nhất, đo bằng chính Prometheus: cửa sổ rate quá ngắn cho biểu đồ trống, rate(sum()) thay vì sum(rate()) cho con số cao 3,44 lần, vẽ counter thô, và step lớn hơn cửa sổ rate giấu 75% đỉnh. Điểm chung đáng sợ: không cái nào sinh ra lỗi — biểu đồ vẫn vẽ, truy vấn vẫn trả 200.
Dung lượng tăng tuyến tính theo thời gian giữ, nhưng chi phí truy vấn thì DƯỚI tuyến tính — giữ lâu chỉ làm hoá đơn dài ra, không làm bảng điều khiển chậm. Và đòn bẩy tiết kiệm lớn nhất (15 lần) là chu kỳ thu thập, không phải rút thời gian giữ. Quyết định 'giữ bao lâu' hoá ra hoàn toàn là quyết định về giá trị, không phải kỹ thuật.
Ba ngày sau sự cố, bạn ngồi viết báo cáo — dữ liệu nào còn sống? Tôi tính ở 1.000 req/s bằng các hằng số đo trong sê-ri: chỉ số 0,01 GB/ngày, trace 43,45 GB/ngày (gấp 4.178 lần). Đặt cùng thời gian giữ cho cả ba là lãng phí 88%, và cái nghịch lý đẹp là nguồn rẻ nhất trả lời câu khó nhất — 'đã từng xảy ra chưa' — cần dữ liệu vài tháng tuổi.
Tôi đo khoảng cách giữa lúc dịch vụ bắt đầu hỏng và lúc người trực ban biết. Với cấu hình Prometheus phổ biến (for: 2m), chuông reo sau 2 phút 43 giây — gấp 11 lần cấu hình nhanh nhất. Và có một cái sàn 14,6 giây không luật nào rút ngắn được, vì nó không nằm ở đó.
Bản thân cụm Kubernetes cũng là một nguồn phát chỉ số, và nó phát ngay cả khi bạn chưa triển khai gì. Tôi đo: 187 chuỗi/pod tuyến tính hoàn hảo, kể cả pod pause chẳng làm gì. Và một bất ngờ — xoá sạch một namespace để lại 4.580 chuỗi control plane không bao giờ co lại (nhưng nó bão hoà).
Khi dịch vụ cần quan sát là một binary bạn không sửa được, còn hai đường: proxy sidecar hay eBPF. Proxy đắt hơn eBPF ~24 lần, nhưng cái 33 µs ấy là giá của ngữ nghĩa HTTP, không phải giá quan sát. Và bài học đắt nhất: một phép đo cho '0% chi phí' vì nó không hề chạy.