Là một lập trình viên yêu công nghệ, thích viết blog để chia sẻ kiến thức, kinh nghiệm lập trình và những điều thú vị trong thế giới tech.
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.
Metric ứng dụng (phần 3-6) cho biết dịch vụ thế nào, nhưng runtime Go bên dưới cũng cần quan sát: bao nhiêu goroutine đang sống, heap lớn bao nhiêu, GC chạy mấy lần và dừng thế giới bao lâu. Bài này đo thật bằng gói runtime/metrics: sinh 5000 goroutine + cấp phát 1.3GB, thấy goroutines 1→5001, 27 lần GC, 0.70ms STW; rồi thả ra thấy goroutines về 1 — chính là cách bắt rò rỉ goroutine, một trong những lỗi Go nguy hiểm nhất.
Mở đầu sê-ri thiết kế API bằng thứ gần như API nào cũng có: phân trang. Mình dựng HTTP server Go với hai cách — `?page=N` dùng OFFSET và `?after=<id>` dùng keyset — trên bảng reviews 400.000 dòng và đo qua HTTP. Ở trang 1–100 hai cách bằng nhau; tới trang 19.999 offset mất 13,62 ms còn keyset vẫn 0,15 ms. EXPLAIN lộ lý do: offset đọc 200.000 dòng index để trả 20. Duyệt hết bảng: 28,5 giây so với 0,96 giây. Và khi có 5 review mới chèn vào giữa hai lần lật trang, offset trả 5 dòng trùng, keyset không trùng dòng nào.
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.
Bạn tạo index nhưng query vẫn chậm và EXPLAIN vẫn báo Seq Scan? Vì predicate không sargable — chỉ cần bọc cột trong một hàm là index nằm im vô dụng. Bài này đo thật trên bảng 1 triệu dòng: WHERE email=x dùng index (0.045ms), nhưng lower(email)=x quét cả bảng (54.857ms); age+1=31 chậm 12ms còn age=30 chỉ 1ms; và một bất ngờ — LIKE 'x%' với index thường vẫn Seq Scan, phải dùng text_pattern_ops.
SetFinalizer đăng ký hàm chạy khi object thành rác, nghe tiện để dọn tài nguyên nhưng đầy cạm bẫy. Đo thật: finalizer chỉ chạy sau GC (0 trước), bất đồng bộ (9998/10000), giữ object sống thêm một chu kỳ GC (19MB vs 0MB), và KHÔNG chạy nếu chương trình thoát trước GC. Go 1.23.