Posted inMonitoring

Giám sát HAProxy bằng Prometheus & Grafana: Đừng để ‘chết’ rồi mới hay

Monitoring tutorial - IT technology blog
Monitoring tutorial - IT technology blog

Tại sao chạy Load Balancer mà không giám sát là tự sát?

2 giờ sáng, điện thoại rung bần bật. Sếp báo: “Web sập rồi, kiểm tra ngay!”. Mình cuống cuồng SSH vào từng cụm backend nhưng service vẫn sống. Soi log HAProxy mới thấy một server bị treo RAM, khiến request đổ vào đó đều nhận lỗi 504 Gateway Timeout. Mất hơn 1 tiếng để tìm ra nguyên nhân chỉ vì thiếu một cái dashboard tử tế.

Vận hành HAProxy mà không có monitoring chẳng khác nào lái xe tải trong đêm tắt đèn pha. Bạn biết xe vẫn chạy, nhưng không biết động cơ đang nóng 100 độ hay lốp sắp nổ. Chúng ta cần những con số biết nói: Request mỗi giây (RPS) là bao nhiêu? Server nào đang “thở oxy”? Response time đang ổn định ở 50ms hay đã vọt lên 5s?

Bài viết này mình sẽ hướng dẫn cách thiết lập bộ ba HAProxy – Prometheus – Grafana để bạn không bao giờ phải “mò kim đáy bể” khi có sự cố nữa.

Mô hình hoạt động: Exporter – Prometheus – Grafana

HAProxy cung cấp dữ liệu thô qua trang stats, nhưng nó không lưu trữ được lịch sử. Để có biểu đồ theo thời gian, chúng ta cần một quy trình chuẩn:

  • HAProxy Exporter: Đóng vai trò “thông dịch viên”. Nó lấy dữ liệu từ HAProxy và chuyển sang định dạng Prometheus có thể đọc được.
  • Prometheus: Bộ não trung tâm. Cứ mỗi 15 giây, nó sẽ sang “hỏi thăm” Exporter để lấy dữ liệu mới nhất và lưu vào database.
  • Grafana: Lớp áo hiển thị. Nó truy vấn dữ liệu từ Prometheus để vẽ lên những biểu đồ trực quan, giúp bạn phát hiện điểm bất thường trong 3 giây.

Cấu hình chi tiết từng bước

Bước 1: Kích hoạt Metrics trên HAProxy

Từ phiên bản 2.0 trở đi, HAProxy đã tích hợp sẵn tính năng xuất dữ liệu cho Prometheus. Bạn chỉ cần mở file /etc/haproxy/haproxy.cfg và thêm đoạn cấu hình sau:

frontend stats-monitoring
    bind *:8404
    http-request use-service prometheus-exporter if { path /metrics }
    stats enable
    stats uri /stats
    stats refresh 10s

Kiểm tra cú pháp và áp dụng cấu hình mới:

haproxy -c -f /etc/haproxy/haproxy.cfg
systemctl reload haproxy

Bây giờ, hãy truy cập http://<IP-Server>:8404/metrics. Nếu thấy một danh sách dài các dòng như haproxy_frontend_bytes_in_total, chúc mừng bạn đã xong bước khó nhất.

Bước 2: Kết nối Prometheus với HAProxy

Mở file cấu hình prometheus.yml. Chúng ta sẽ khai báo cho Prometheus biết cần lấy dữ liệu từ đâu. Thêm đoạn cấu hình sau vào mục scrape_configs:

scrape_configs:
  - job_name: 'haproxy_production'
    scrape_interval: 15s
    static_configs:
      - targets: ['<IP-HAProxy>:8404']

Sau khi restart Prometheus, hãy vào mục Status -> Targets. Nếu dòng haproxy_production hiển thị trạng thái UP màu xanh, dữ liệu đã bắt đầu được đổ về kho lưu trữ.

Bước 3: Thiết lập Dashboard Grafana chuyên nghiệp

Đừng tốn thời gian tự vẽ biểu đồ từ đầu. Cộng đồng đã làm sẵn những dashboard cực xịn. Mình khuyên dùng Dashboard ID 12633 (dành cho bản tích hợp sẵn) hoặc 367.

  1. Tại giao diện Grafana, chọn biểu tượng dấu cộng (+) -> Import.
  2. Nhập ID 12633 vào ô “Import via grafana.com”.
  3. Tại mục Data Source, chọn Prometheus đã cấu hình.
  4. Nhấn Import. Một hệ thống biểu đồ đầy đủ từ CPU, RAM đến Latency sẽ hiện ra ngay lập tức.

4 chỉ số “sống còn” bạn phải theo dõi

Khi nhìn vào dashboard, hãy bỏ qua những con số rườm rà và tập trung vào 4 thông số sau:

1. Backend Status: Chỉ số này phải luôn là màu xanh. Nếu một server con (backend) chuyển sang màu đỏ, HAProxy sẽ đẩy toàn bộ tải sang các server còn lại. Nếu không xử lý kịp, cả hệ thống sẽ sập theo hiệu ứng domino.

2. HTTP Error Rate (4xx & 5xx): Bình thường tỷ lệ lỗi 5xx nên xấp xỉ 0%. Nếu con số này vọt lên trên 1%, đó là dấu hiệu code ứng dụng lỗi hoặc Database quá tải. Lỗi 4xx tăng đột biến thường là dấu hiệu của một cuộc tấn công Brute-force hoặc Scan lỗi.

3. Maxconn & Session Usage: Mỗi server đều có giới hạn chịu tải. Nếu Active Sessions chạm ngưỡng 80% so với maxconn, người dùng sẽ bắt đầu thấy web load chậm do request phải nằm trong hàng đợi (queue).

4. Response Time (P99 Latency): Đừng chỉ nhìn vào trung bình (Average). Hãy nhìn vào P99. Nếu P99 là 2s, nghĩa là 1% người dùng của bạn đang phải chờ tận 2 giây để tải trang. Đây là con số thực tế nhất phản ánh trải nghiệm khách hàng.

Lời kết

Giám sát không chỉ để cho đẹp hay báo cáo sếp. Nó là công cụ giúp bạn ngủ ngon hơn. Thay vì đợi user phàn nàn, bạn sẽ là người biết trước sự cố để xử lý. Nếu bạn đang vận hành Load Balancer cho dự án thực tế, hãy dành ra 15 phút để cài đặt bộ công cụ này ngay hôm nay. Dữ liệu chính xác luôn là chìa khóa để tối ưu hệ thống hiệu quả nhất.

Share:
Tags: