Chỉ số: bốn kiểu
Counter tốn 2,0 ns, Summary tốn 226,4 ns. Nhưng cái đắt thật không phải kiểu chỉ số — mà là số giá trị nhãn.
DevOps
Theo dõi riêng chuyên mục này 114 bài viết
Cùng một sự cố, ba cách tính SLI cho ba kết luận trái ngược: vi phạm SLO, đạt SLO, và 'không có chuyện gì xảy ra'
Tôi dựng cùng một sự cố hai lần rồi tính SLI ba cách. Theo request: vi phạm nặng. Theo cửa sổ: y hệt nhau dù số người dính khác 3,6 lần. Theo độ trễ trung bình: 100% đạt, mù hoàn toàn. Câu hỏi trung tâm của SLO không phải 'đặt bao nhiêu' mà là 'tính SLI thế nào'.
Bốn cách viết truy vấn Prometheus sai mà không hề báo lỗi — một trong đó thổi con số lên gấp 3,44 lần, một cái giấu mất 75% chiều cao đỉnh
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.
Trace tốn gấp 4.178 lần chỉ số mỗi ngày — nhưng ba trong sáu câu hỏi của báo cáo sự cố lại cần đúng cái nguồn rẻ nhất, và cần nó cũ nhấ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.
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.
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'.