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.
Nếu chính hệ giám sát chết, bạn biết bằng cách nào? Tôi giết lần lượt exporter, Prometheus, Alertmanager và đo cái nào thật sự kêu. Luật ngưỡng bạn viết (dich_vu_hong > 0) im lặng khi exporter biến mất; chỉ up==0 và absent() bắt được. Và dead man's switch qua Alertmanager có khoảng mù 3 phút.
Tôi đo chi phí tài nguyên thật của Prometheus tự dựng: 20.000 chuỗi tốn 0,12% một lõi và 69 MB RAM. Nhỏ đến mức 'tự dựng tốn máy' là sai. Nhưng nếu bạn chọn máy theo RAM, bạn sẽ mua một cỗ chết vì hết đĩa khi mới dùng một phần bảy số RAM đã trả.