Prometheus: mô hình kéo
Một lần quét 50.000 nhãn chuyển 50,6 MB và mất 435 ms. Và khi mục tiêu chết, chuỗi biến mất ngay lập tức.
Q
Quản trị viên
Là một lập trình viên yêu công nghệ, thích viết blog để chia sẻ kiến thức, kinh nghiệm lập trình và những điều thú vị trong thế giới tech.
2300 bài viết
· Website
Nhãn và bùng nổ chiều
Thêm hai nhãn 'vô hại' biến 1.000 chuỗi thành 20.000. Và 50.000 giá trị nhãn ăn 1,3 GB RAM của Prometheus.
Ghi trước quy tắc và cảnh báo
Quy tắc ghi trước làm truy vấn nhanh 35 lần. Và độ trễ phát hiện có công thức chính xác, kiểm chứng được.
svc-a mất 137 ms và trông như thủ phạm — nhưng nó chỉ tự làm 10 ms, kẻ ăn 101 ms nằm ở giữa chuỗi
Một yêu cầu đi qua bốn dịch vụ. Nhìn từ ngoài, hai sự cố khác hẳn nhau chỉ là một con số. Metric ở dịch vụ đầu bó tay, còn trace chỉ thẳng vào svc-c: tự làm 101,45 ms trong khi ba chặng kia đều quanh 10 ms. Bài học: đọc trace theo cột 'tự làm', đừng theo cột 'tổng'.
du -sb báo thư mục Jaeger nặng 2.193 MB — sự thật là 16 MB, sai 133 lần vì một file thưa, và suýt làm cả bài đo sai 432 lần
Jaeger vs Tempo trên cùng 20.000 trace: Tempo nhỏ hơn 3,3 lần, tìm theo dịch vụ nhanh hơn 8 lần, còn Jaeger lấy theo trace_id nhanh hơn. Nhưng con số đáng nhớ nhất là 133 — chênh lệch giữa ba cách đo cùng một dung lượng, và là lần thứ ba trong sê-ri du trên thư mục dữ liệu nói dối tôi.
Tỷ lệ request chậm tăng 10 lần: p50 nhích 3%, trung bình tăng 91%, p99 tăng 927% — vì sao trung bình trên dashboard của bạn nói dối
Tôi cho tỷ lệ request chậm tăng dần trên một triệu mẫu thật và xem ba con số quen thuộc phản ứng ra sao. Kết quả: nếu theo dõi p50 bạn không thấy gì, nếu theo dõi trung bình bạn thấy quá muộn, chỉ p99 kêu đúng lúc. Và con số chính xác nhất Histogram cho bạn lại đúng là con số ít dùng nhất.