Service của bạn khoẻ không? RED method trả lời bằng đúng ba tín hiệu: Rate, Errors, Duration. Bài này dựng thật một dashboard RED từ một Go service hai route, rồi cho thấy cú lừa chí mạng: tỉ lệ lỗi tổng hợp 3.9% trông chấp nhận được, nhưng tách theo route lộ ra /checkout đang lỗi 9.3% — đúng route tiền bạc. Chỉ hai metric, ba câu PromQL.
Thêm nhãn user_id vào một metric nghe tiện — lọc theo user mà. Nhưng bài này đo thật cái giá: cùng một app, metric gắn nhãn route tạo 3 chuỗi thời gian, metric gắn nhãn user_id tạo 10000; chỉ một metric sai làm tổng số chuỗi của Prometheus nhảy từ 729 lên 10732 (~14 lần). Và đó mới 10000 user — nhân thêm status, endpoint là nổ tổ hợp đủ làm Prometheus OOM mà chết.
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.
Hệ message queue có khoẻ không? Đừng nhìn CPU hay throughput — nhìn consumer lag. Bài này đo thật trên Kafka: backlog 200.000 message, consumer chậm, producer thêm 100.000 — lag vọt từ 150.000 lên 250.000 dù consumer vẫn chạy, rồi về 0 khi bắt kịp. LAG = LOG-END-OFFSET trừ CURRENT-OFFSET, và nó là chỉ báo sớm nhất rằng hệ sắp không theo kịp.