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.
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.
CPU 100% — hoảng không? Chưa chắc. USE method (Utilization, Saturation, Errors) cho tài nguyên chỉ ra rằng utilization cao một mình là tín hiệu mơ hồ. Bài này dựng thật một worker pool bị nạp quá sức: utilization chạm 100% nhưng không nói lên mức độ quá tải; chính saturation (hàng đợi đầy 20/20) và errors (41 job/s bị rớt) mới định lượng được service đang chết ngạt thế nào.
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.
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.