Metrics và log pipeline trên VPS
Bắt đầu bằng tín hiệu cần ra quyết định, không chỉ dashboard đẹp.
Nắm bản chất
Prometheus thu thập time-series metrics; Grafana trực quan hóa; ứng dụng nên expose HTTP counters và histogram latency. Các labels phải có cardinality được kiểm soát: không đặt user_id/job_id trực tiếp vào labels.
Logs nên đi ra stdout/stderr và có correlation IDs để liên kết request/worker. Với single VPS, lưu trữ monitoring trên cùng host còn rủi ro cùng mất dữ liệu khi host hỏng. Production cần kế hoạch retention và off-host telemetry tùy SLO.
Luồng hoạt động
Hãy tự giải thích mỗi mũi tên: dữ liệu, quyền hoặc tín hiệu nào được truyền qua bước này?
Lệnh & cấu hình mẫu
sum(rate(http_requests_total[5m]))
sum(rate(http_requests_total{status=~"5.."}[5m]))
histogram_quantile(0.95,sum by (le)(rate(http_request_duration_seconds_bucket[5m])))
Lệnh có placeholder hoặc phụ thuộc môi trường thì cần thay thông tin thực tế, kiểm tra quyền và chỉ thực hiện trên tài nguyên được phép.
Bài tập 10–20 phút
Bật monitoring profile trong lab Buổi 8. Tạo một request thành công và một lỗi có chủ đích; xem counters tăng và tìm trace/correlation ID trong logs.
Lỗi dễ mắc
Một metrics endpoint công khai có thể làm lộ nội dung service và topology. Giới hạn truy cập hoặc dùng private scrape network.
Tự kiểm tra
Vì sao không đặt job UUID vào Prometheus label?Xem đáp án ↗
Vì số lượng giá trị không giới hạn gây cardinality explosion và tăng memory/storage costs.
Học thêm qua lab
Có project thực hành đúng với chương này, kèm README và những giới hạn môi trường cần lưu ý.
↓ Tải mã nguồn thực hành chương 08Đối chiếu tài liệu gốc
Cú pháp và khả năng hỗ trợ có thể thay đổi theo phiên bản. Trước khi dùng Production, hãy kiểm tra tài liệu tương ứng.
Mở tài liệu chính thức ↗