Metrics, logs, traces không phải ba cách làm cùng một việc — chúng trả lời ba câu hỏi khác nhau. Bài này đo thật trên Prometheus + Go app: cùng một endpoint, metric cho 90 thành công/11 lỗi (có vấn đề không?), log JSON cho chi tiết từng request (chuyện gì xảy ra?), và trace_id nối các bước lại (lỗi ở đâu?). Khi nào dùng cái nào và vì sao cần cả ba.
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.
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%.
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.