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ả.
Bài chốt sê-ri quan sát: tôi đo thời gian từ 'chưa có gì' tới lúc cảnh báo thật sự reo (11–20 giây), gom bốn mươi phần thành một danh sách kiểm và một bảng hằng số ước lượng được, rồi rút ra kết luận thật của cả sê-ri — hầu hết lỗi quan sát không báo lỗi, chúng chỉ hiện ra ở một con số vô lý khi có sẵn con số khác để đối chiếu.
INFO trả về hơn hai trăm dòng; đo thật trên một Redis 64 MB cho thấy dòng bạn hay cảnh báo nhất — phần trăm bộ nhớ — là dòng vô dụng nhất khi sự cố xảy ra. Nó là chỉ số bão hoà, chạm trần rồi đứng im; cái thật sự nói mức nghiêm trọng là tốc độ đuổi khoá, một con số không có trần. Cùng bốn nguồn để truy một lệnh chậm, và mười chỉ số nên đưa lên bảng.
SLOWLOG là công cụ chẩn đoán tốt nhất của Redis, nhưng nó đo thời gian một lệnh CHẠY, không đo thời gian nó xếp hàng. Đo thật: một EVAL chạy 3 giây làm một GET mất 3,3 giây từ phía khách — và slowlog chỉ ghi EVAL, GET biến mất. SLOWLOG cho biết ai gây nghẽn, không cho biết ai bị nghẽn; muốn thấy phía nạn nhân phải đo ở khách hàng.
Mở sê-ri quan sát: tôi dựng một sự cố thật (0,2% request đi qua nhánh chậm) rồi soi bằng cả metric, log, trace và đo giá từng lăng kính. p99 mù hoàn toàn vì sự cố nằm gọn trong phần đuôi nó cắt bỏ; trung bình chỉ nhích 12%; ba trụ cột không thay thế nhau — metric nói CÓ, log nói request NÀO, trace nói chậm Ở ĐÂU. Phân vị bạn theo dõi quyết định tỷ lệ sự cố nhỏ nhất bạn thấy được.