Log rời rạc không cho biết thời gian một request nằm ở đâu khi nó đi qua API, DB, cache. Distributed tracing nối tất cả bằng một trace_id và quan hệ cha-con giữa span. Đo thật trong Go với OpenTelemetry: dựng cây trace, và chi phí một span 50 ns (tắt) đến 763 ns (ghi đủ) — sampling là nút chỉnh.
Có log JSON đẹp rồi, nhưng giữa 150 dòng log của 50 request chạy song song, đâu là những dòng của riêng một request? Nếu không có ID chung, chúng đan xen theo lịch chạy goroutine và bạn không tách nổi. Bài này đo thật trong Go: một slog.Handler tùy biến tự gắn trace_id lấy từ context, để mỗi request mang một ID xuyên suốt; rồi một câu jq lọc đúng 3 bước của request trace-0007 giữa 150 dòng — và mọi trace_id đều xuất hiện đúng 3 lần, không sót không lẫn.
Metric cho biết một request chậm, nhưng không nói chậm ở CHẶNG nào. Tracing giải quyết điều đó bằng span lồng nhau: mỗi chặng một span, tất cả cùng traceID, mỗi span trỏ về cha để dựng lại cây. Bài này tự cài một tracer tối giản trong Go (không cần backend) và đo thật một request đi qua handler → auth → db → cache: cây span cho thấy dbQuery chiếm 31/39ms = 80%, đúng chặng cần tối ưu.
Trace và log mỗi request thì đúng nhất, nhưng hàng triệu request/ngày là khối dữ liệu không kham nổi. Sampling giảm khối lượng — nhưng sampling ngẫu nhiên (head) bỏ mù đúng thứ cần thấy: lỗi hiếm. Bài này đo thật trên 100.000 trace: head sampling 1% chỉ bắt 14/1029 lỗi (bỏ sót 99%); error-biased sampling giữ tổng cộng chỉ 4% mà bắt trọn 1029/1029 lỗi. Cùng bàn cái giá của tail sampling và vì sao metric không sample.
Metrics, logs, traces không phải ba cách làm cùng một việc — chúng trả lời ba câu hỏi khác nhau. Bài này đo thật trên Prometheus + Go app: cùng một endpoint, metric cho 90 thành công/11 lỗi (có vấn đề không?), log JSON cho chi tiết từng request (chuyện gì xảy ra?), và trace_id nối các bước lại (lỗi ở đâu?). Khi nào dùng cái nào và vì sao cần cả ba.
Metric báo checkout p99 = 127ms. Nhưng 127ms đó tiêu ở đâu — validate, query DB, hay gọi payment? Metric không biết. Bài này dựng thật tracing với OpenTelemetry và Jaeger: tạo span lồng nhau, export, rồi query Jaeger API lấy trace thật — và thấy ngay queryDB ngốn 91ms (72% tổng) trong khi validate chỉ 3.85ms. Đây là thứ metric tổng hợp không bao giờ chỉ ra được.