Lập trình 22/09/2026 7 phút

Bốn loại metric Prometheus: counter, gauge, histogram, summary — và khi nào dùng cái nào

Counter, gauge, histogram, summary nghe na ná nhau nhưng trả lời bốn câu hỏi khác hẳn. Bài này instrument một Go app với cả bốn, bắn 150 request thật rồi đọc thẳng output /metrics: counter dừng ở 150, gauge vọt lên 51 lúc tải rồi về 0, histogram chia bucket cộng dồn, summary tự tính quantile phía client. Kèm bẫy chọn sai loại khiến số liệu thành vô dụng.

Lập trình 22/09/2026 6 phút

PromQL cho ra hồn: rate, increase và sum by — biến counter thô thành câu trả lời

Counter của Prometheus chỉ là con số cộng dồn vô nghĩa khi đọc trực tiếp — http_requests_total=1055 chẳng nói lên gì. Sức mạnh nằm ở PromQL. Bài này dựng một app với counter gắn nhãn path/status, bắn tải đều rồi chạy query thật trên obs-prom: rate() ra đúng 10/5/2 req/s, increase ra đúng 600 trong 1 phút, sum by gộp theo nhãn, và một dòng tính tỉ lệ lỗi 4.4%.

Lập trình 22/09/2026 7 phút

p50, p95, p99: vì sao trung bình độ trễ nói dối và percentile mới nói thật

Dashboard báo độ trễ trung bình 36ms — service khoẻ? Bài này chạy thật một app có phân bố lệch (95% nhanh, 5% chậm) rồi đo bằng histogram_quantile: trung bình 36ms và p95 25ms đều đẹp, nhưng p99 là 778ms — cứ 100 user thì 1 người chờ gần 0.8 giây. Và một bất ngờ: p99 đo được cao hơn cả giá trị chậm nhất thật, vì bucket chọn quá rộng.

Lập trình 22/09/2026 7 phút

RED method: ba tín hiệu đủ để biết service có khoẻ không — và vì sao phải tách theo route

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.

Lập trình 22/09/2026 7 phút

USE method: vì sao utilization 100% chưa phải vấn đề, mà saturation mới là

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.

Lập trình 22/09/2026 7 phút

Cardinality: vì sao một nhãn user_id vô hại có thể hạ gục cả Prometheus

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.