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.
DevOps
Theo dõi riêng chuyên mục này 114 bài viết
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.
Cảnh báo ồn
Ngưỡng tức thời báo giả 50 lần cho 3 sự cố thật. Nhưng lỗi không nằm ở quy tắc — nó nằm ở mẫu quá nhỏ.
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.
Thu thập log: agent và sidecar
Thu thập một dòng log tốn 1,73 µs — đắt gấp ba lần chính việc ghi ra dòng đó. Và Vector ăn RAM gấp 10 lần Fluent Bit.
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'.