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'.
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ố.
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à.