Tại sao Prometheus Pull Model lại “bó tay” với Batch Jobs?
Nếu đã làm việc với Prometheus, bạn thừa biết cơ chế cốt lõi của nó là Pull model. Server sẽ định kỳ ghé thăm các exporter để thu thập dữ liệu. Tuy nhiên, rắc rối bắt đầu khi hệ thống xuất hiện các tác vụ “sáng nở tối tàn”. Chẳng hạn như một CronJob dọn dẹp log chỉ chạy trong 3 giây, hay script backup database diễn ra chưa đầy 1 phút vào lúc 2 giờ sáng.
Ngày trước, mình từng đau đầu vì job backup chết mà Grafana vẫn báo xanh. Lý do cực đơn giản: Prometheus mặc định scrape mỗi 15-30 giây. Nếu job của bạn bắt đầu và kết thúc (hoặc sập) nằm gọn giữa hai chu kỳ scrape, Prometheus hoàn toàn “mù tịt”. Với nó, cái job đó chưa từng tồn tại.
Prometheus Pushgateway ra đời để lấp đầy khoảng trống này. Hãy coi nó như một “hộp thư” trung gian. Thay vì đợi Prometheus đến lấy, các job ngắn hạn sẽ chủ động quăng metrics vào Pushgateway rồi nghỉ. Prometheus chỉ việc ghé qua cái “hộp thư” này để hốt dữ liệu về là xong.
Ba cách giám sát Job ngắn hạn: Nên chọn cái nào?
Trước khi chốt phương án Pushgateway, mình đã thử qua vài cách và rút ra bảng so sánh thực tế sau:
- Ép Scrape Interval xuống 1 giây: Nghe có vẻ ổn nhưng CPU server sẽ “khóc thét” vì quá tải. Thực tế, nếu job chạy 0.5 giây, bạn vẫn có 50% nguy cơ mất trắng dữ liệu.
- Dựng Exporter riêng: Quá cồng kềnh cho một script Bash 10 dòng. Bạn phải duy trì một web service chạy ngầm chỉ để phơi metrics ra.
- Dùng Pushgateway: Giải pháp tối ưu nhất. Script chỉ cần một lệnh
curlđơn giản là dữ liệu đã nằm gọn trên dashboard.
Cảnh báo: Những “hố tử thần” sau 6 tháng thực chiến
Pushgateway rất lợi hại nhưng không phải là chiếc đũa thần. Sau nửa năm vận hành hệ thống hơn 200 CronJobs, mình nhận ra vài điểm yếu chí mạng:
Điểm cộng sáng giá
- Linh hoạt tuyệt đối: Bất cứ thứ gì gửi được request HTTP đều chơi được, từ script Shell đến Java.
- Job “sạch”: Chạy xong là ngắt, không tốn tài nguyên duy trì port hay service trên server chạy job.
Nhược điểm và rủi ro (Cần lưu ý kỹ)
- Single point of failure: Pushgateway sập đồng nghĩa với việc toàn bộ batch jobs biến mất khỏi radar. Bạn cần monitor chính nó thật nghiêm ngặt.
- Bẫy “Stale metrics”: Đây là thứ gây ức chế nhất. Pushgateway không tự xóa dữ liệu. Nếu hôm nay job báo
status=1(thành công), nhưng ngày mai job không chạy được, Pushgateway vẫn giữ nguyên con số 1 đó. Prometheus sẽ báo giả rằng mọi thứ vẫn ổn. - Thiếu metric up: Bạn không thể dùng hàm
upđể kiểm tra tình trạng sống chết của job như với Node Exporter.
Triển khai Pushgateway trong 5 phút
Dùng Docker là cách nhanh nhất để đưa Pushgateway vào hệ thống mà không làm bẩn OS.
1. Khởi tạo với Docker Compose
Tạo file docker-compose.yml với cấu hình tối giản:
services:
pushgateway:
image: prom/pushgateway:v1.9.0
container_name: pushgateway
ports:
- "9091:9091"
restart: always
Gõ lệnh docker-compose up -d. Truy cập ngay http://your-ip:9091 để kiểm tra giao diện quản lý.
2. Đẩy dữ liệu từ script thực tế
Giả sử bạn có script backup database nặng 500GB. Chúng ta cần theo dõi dung lượng và trạng thái.
Ví dụ Bash (Dùng curl)
# Đẩy metrics kèm label chi tiết
cat <<EOF | curl --data-binary @- http://localhost:9091/metrics/job/backup_db/instance/prod_server
# HELP db_backup_size_bytes Dung luong file backup
# TYPE db_backup_size_bytes gauge
db_backup_size_bytes 536870912000
# HELP db_backup_status 1=thanh cong, 0=that bai
db_backup_status 1
EOF
Ví dụ Python (Dùng prometheus_client)
from prometheus_client import CollectorRegistry, Gauge, push_to_gateway
registry = CollectorRegistry()
g = Gauge('job_last_success_time', 'Unix timestamp job chay thanh cong', registry=registry)
g.set_to_current_time()
# Day metrics len gateway
push_to_gateway('localhost:9091', job='daily_report', registry=registry)
3. Cấu hình Prometheus Scrape
Đừng quên sửa file prometheus.yml. Đây là cấu hình chuẩn:
scrape_configs:
- job_name: 'pushgateway'
honor_labels: true
static_configs:
- targets: ['localhost:9091']
Mẹo nhỏ: Phải có honor_labels: true. Nếu thiếu, Prometheus sẽ đè các label bạn dày công thiết lập bằng label mặc định của Pushgateway.
Kinh nghiệm để đời khi vận hành
Để tránh bị dashboard “lừa tình”, hãy tuân thủ hai quy tắc vàng sau:
Luôn dùng Timestamp thành công: Thay vì chỉ nhìn vào status 0/1, hãy đẩy thêm metric job_last_success_unixtime. Trên Grafana, dùng công thức time() - job_last_success_unixtime. Nếu con số này lớn hơn 24 giờ, bạn biết chắc chắn job backup đêm qua đã có biến.
Dọn rác định kỳ: Với các job sinh ra label động (như ID ngẫu nhiên), Pushgateway sẽ phình to rất nhanh, có thể ngốn hàng GB RAM. Hãy dùng script gọi API DELETE để dọn dẹp các metrics đã hết hạn sử dụng.
# Xoa sach du lieu cua mot job khi khong con dung den
curl -X DELETE http://localhost:9091/metrics/job/backup_db
Từ ngày áp dụng bộ combo này, mình không còn phải thức đêm check log hay SSH vào từng server nữa. Sáng ra cứ thong thả làm ly cafe, lướt dashboard là biết ngay tình trạng sức khỏe của cả hệ thống. Nếu bạn đang quản lý hàng tá CronJob quan trọng, triển khai ngay thôi!

