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ỏ.
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.
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ỏ.
opentelemetry-sdk thật, xuất OTLP, đo cả tốc độ lẫn số byte. Con số tốc độ đúng như dự đoán. Nhưng số span THỰC SỰ tới nơi thì không: hàng đợi mặc định 2.048 làm mất gần hai phần ba trace khi dịch vụ chạy nhanh, chỉ ghi đúng một dòng log. Không lỗi, không chỉ số.
send() nuốt được khoảng 1,5 lần tổng hai đệm socket rồi mới chặn, dù người nhận đứng hình không đọc byte nào. Đó không phải lỗi mà là kiểm soát luồng của TCP tự ghìm người gửi theo người nhận. Đo thật, kèm cú bẫy kernel âm thầm nhân đôi đệm.
Tôi đo open redirect bằng Chromium thật: phép kiểm 'phải bắt đầu bằng /' chặn được https://evil.com và javascript: nhưng thủng với //evil và /\evil, vì trình duyệt đọc // là một tên miền mới. Chỉ danh sách trắng đích mới chặn sạch. Kèm cái bẫy Referer — token trong URL rò sang trang ngoài — và đo xem trình duyệt hiện đại đã vá được một nửa ra sao.
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.
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.