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.
Log văn bản thuần đọc bằng mắt thì được, nhưng máy khó truy vấn — grep với regex mong manh. Bài này chạy thật slog của Go in log JSON có cấu trúc, rồi dùng jq lọc theo level, theo độ trễ, tổng hợp doanh thu ngay trên log. Và cú chốt: gắn trace_id thật từ OpenTelemetry vào mỗi dòng log — thấy lỗi trong log là nhảy thẳng tới đúng trace trong Jaeger, khớp đã kiểm chứng.
Metric đẹp vô dụng nếu không ai nhìn lúc 3h sáng — đó là việc của alert. Nhưng alert sai cách còn tệ hơn không có: báo động giả làm kỹ sư tê liệt (alert fatigue). Bài này dựng thật alert rule trên Prometheus, cho hai alert cùng điều kiện chạy song song: cái không 'for' firing ngay tức khắc, cái có 'for: 30s' chờ pending 30 giây rồi mới firing — đo thật từng mốc chuyển trạng thái qua API.
Dung lượng metric là tích của bốn thừa số — số chuỗi, tần suất lấy mẫu, bytes mỗi sample, và retention — mỗi thừa số là một đòn bẩy cắt chi phí. Bài này đo thật trên Prometheus: 78 samples/s ở scrape 5s, head chứa hơn 10.000 chuỗi (phần lớn là stale vẫn tốn RAM), rồi ngoại suy ra quy mô thật: một nhãn cardinality sai biến 7GB thành 730GB. Ba núm vặn để tiết kiệm mà không mù thông tin.
Mười một phần qua ta dựng từng mảnh observability bằng demo đo thật. Bài cuối ghép chúng lại: một request duy nhất phát cả ba tín hiệu — metric, trace, log — chia sẻ cùng một trace_id, và chính trace_id đó là sợi chỉ nối metric báo động với log và trace để điều tra. Kèm bảng tổng hợp mọi con số đo thật xuyên suốt loạt bài và một checklist gắn observability vào service của bạn.
Gọi service trực tiếp thì caller bị chặn tới khi downstream xong — và sập theo nếu nó chết. Hàng đợi đảo ngược điều đó. Bài này đo thật trên Kafka: producer đẩy 100.000 message ở 377.000 msg/s, chỉ chờ broker ack 1.49ms mà KHÔNG cần consumer nào tồn tại; 100.000 message nằm chờ an toàn trong topic; rồi một consumer đến muộn đọc hết và bắt kịp về lag 0. Đó là tách rời theo thời gian.