Cho đúng một chặng giữa chuỗi quên chuyển tiếp header traceparent, cái cây trace tách làm hai — mà không dịch vụ nào báo lỗi, cả hai mảnh đều 'khoẻ mạnh'. Cộng lấy mẫu 10%, tỷ lệ yêu cầu có trace đầy đủ rơi từ 9,93% xuống 1,01%. Mỗi chỗ gãy không cộng chi phí, nó nhân.
Trace đầy đủ đắt, lấy mẫu là câu trả lời. Nhưng lấy mẫu KIỂU NÀO đổi hẳn giá trị: cùng chi phí lưu, lấy mẫu đầu 10% giữ 10,48% trace lỗi, lấy mẫu đuôi giữ trọn 100% — chênh 9,5 lần thứ bạn thật sự cần. Cái giá của lấy mẫu đuôi là 46,3 MB bộ nhớ đệm, lớn hơn ước tính 3,6 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.
Nhúng trace_id vào mỗi dòng log tốn thêm 59,8% dung lượng. Đổi lại: khi có sự cố, số dòng bạn phải lọc để tìm đúng chuyện đã xảy ra giảm 12.000 lần. Thời gian máy chạy gần như không đổi — cái thay đổi là thời gian của con người lúc đang cháy nhà.
Span db.query nói một con số, pg_stat_statements nói một con số khác cho đúng truy vấn đó, và chúng lệch nhau gần chục lần. Không cái nào sai — chúng đo hai thứ khác nhau, và cái hiệu của chúng mới là con số quyết định việc tối ưu SQL của bạn có ích hay hoàn toàn vô nghĩa.
Bộ công cụ tự động đắt hơn tự viết span 2,45 lần và chỉ cho thêm đúng một thuộc tính. Nhìn bảng thì viết tay thắng rõ. Nhưng so chi phí là so sai chỗ: thứ phân biệt hai cách không phải nano-giây, mà là cái giá của một lần ai đó quên.