Posted inMonitoring

Hướng dẫn Prometheus Process Exporter: Soi chi tiết ‘sức khỏe’ từng tiến trình Linux

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

Vấn đề: Dashboard báo CPU 100% nhưng không biết ứng dụng nào đang “cắn”

Kịch bản này chắc chắn không lạ với anh em SRE: Grafana báo đỏ, CPU server nhảy vọt lên 100%, RAM bắt đầu tràn vào swap. Bạn vội vàng SSH vào, gõ top hoặc htop để truy tìm hung thủ. Hóa ra là một worker Python đang chạy loop vô tận hoặc một ứng dụng Java bị treo.

Nếu sự cố xảy ra lúc 2 giờ sáng rồi tự hết trước khi bạn kịp kiểm tra, làm cách nào để biết chính xác tiến trình nào đã gây lỗi? Dashboard tổng quan chỉ báo CPU của cả server là không đủ để chúng ta trả lời câu hỏi đó.

Tại sao Node Exporter thôi là chưa đủ?

Hệ thống monitoring mình đang vận hành dùng Prometheus + Grafana để theo dõi hơn 20 server. Ban đầu, mình chỉ dùng Node Exporter. Công cụ này rất tốt để lấy thông số tổng quát như CPU, RAM, Network của cả hệ thống.

Tuy nhiên, Node Exporter có một nhược điểm lớn: nó hoàn toàn “mù” về cấp độ tiến trình. Nó báo server ngốn 16GB RAM, nhưng không thể chỉ ra ứng dụng Node.js của bạn đang bị memory leak chiếm mất 12GB. Trong môi trường microservices, việc thiếu dữ liệu này khiến việc xử lý sự cố (troubleshooting) mất rất nhiều thời gian.

So sánh các phương án giám sát hiện nay

Để giải quyết bài toán này, anh em thường cân nhắc giữa 3 hướng chính:

  • Script tự chế: Viết bash script lấy dữ liệu từ /proc rồi đẩy về Pushgateway. Cách này khá thủ công, khó duy trì và dễ gây tải ảo cho hệ thống.
  • Netdata: Giám sát cực kỳ chi tiết theo thời gian thực. Tuy nhiên, nếu bạn đã có sẵn stack Prometheus thì cài thêm Netdata chỉ để lấy thông số process sẽ hơi lãng phí tài nguyên.
  • Zabbix: Hỗ trợ giám sát process rất mạnh. Nhưng nếu bạn đang đi theo hướng cloud-native, việc đưa Zabbix vào hệ thống Prometheus hiện có là một bước lùi về mặt kiến trúc.

Giải pháp tối ưu: Prometheus Process Exporter

Sau khi thử nghiệm nhiều công cụ, mình chọn Process Exporter. Nó nhẹ, cấu hình linh hoạt và cho phép gom nhóm các tiến trình theo tên, đường dẫn hoặc command line.

Bước 1: Cài đặt lên server Linux

Bạn tải bản phân phối mới nhất từ Github. Ví dụ với môi trường Linux 64-bit:

wget https://github.com/ncabatoff/process-exporter/releases/download/v0.7.10/process-exporter-0.7.10.linux-amd64.tar.gz
tar -xvf process-exporter-0.7.10.linux-amd64.tar.gz
sudo mv process-exporter-0.7.10.linux-amd64/process-exporter /usr/local/bin/

Bước 2: Cấu hình gom nhóm tiến trình

Process Exporter không lấy bừa bãi hàng nghìn tiến trình trong hệ thống. Bạn cần định nghĩa những nhóm ứng dụng mình thực sự quan tâm để giữ dữ liệu tinh gọn.

Tạo file cấu hình tại /etc/process-exporter/config.yaml:

process_names:
  - name: "{{.Comm}}"
    cmdline:
    - 'nginx'

  - name: "{{.Comm}}"
    cmdline:
    - 'mysqld'

  - name: "Java_Backend"
    cmdline:
    - 'java'

Biến {{.Comm}} giúp tự động lấy tên thực thi. Bạn cũng có thể đặt tên gợi nhớ như “Java_Backend” để dễ lọc trên Dashboard.

Bước 3: Chạy dưới dạng Systemd Service

Để exporter tự khởi động cùng server, hãy tạo file service:

sudo nano /etc/systemd/system/process-exporter.service

Nội dung file:

[Unit]
Description=Process Exporter
After=network.target

[Service]
User=root
ExecStart=/usr/local/bin/process-exporter -config.path /etc/process-exporter/config.yaml
Restart=always

[Install]
WantedBy=multi-user.target

Kích hoạt service bằng lệnh:

sudo systemctl daemon-reload
sudo systemctl start process-exporter
sudo systemctl enable process-exporter

Kiểm tra tại http://<IP_SERVER>:9256/metrics. Nếu thấy các dòng namedprocess_namegroup_cpu_seconds_total là bạn đã thành công.

Bước 4: Cấu hình Prometheus Scrape

Thêm đoạn sau vào file prometheus.yml:

scrape_configs:
  - job_name: 'process-stats'
    static_configs:
      - targets: ['192.168.1.10:9256']

Trực quan hóa dữ liệu trên Grafana

Đừng tự vẽ biểu đồ từ đầu. Hãy dùng các Dashboard cộng đồng chất lượng. Mình gợi ý ID 249 (cơ bản) hoặc 8378 (nhiều thông số chuyên sâu).

Các chỉ số quan trọng bạn cần soi:

  • CPU usage per process: Biết ngay ứng dụng nào đang ngốn core.
  • Resident Set Size (RSS): Lượng RAM thực tế tiến trình đang chiếm (rất quan trọng để bắt lỗi leak RAM).
  • Disk I/O: Xem dịch vụ nào đang đọc ghi đĩa 50MB/s làm nghẽn hệ thống.
  • File Descriptors: Cảnh báo sớm lỗi “Too many open files” trước khi crash ứng dụng.

Kinh nghiệm thực tế khi vận hành

Sau khi triển khai cho hệ thống thực tế, đây là 3 lưu ý nhỏ cho anh em:

  1. Đừng tham track quá nhiều: Chỉ nên theo dõi các dịch vụ lõi. Việc giám sát hàng trăm tiến trình nhỏ lẻ sẽ làm TSDB của Prometheus phình to thêm khoảng 50-100MB mỗi ngày cho mỗi node.
  2. Tận dụng Regex: Nếu chạy nhiều instance ứng dụng với tham số khác nhau, hãy dùng regex trong cmdline để gom chúng vào một nhóm duy nhất cho gọn.
  3. Cảnh báo thông minh: Hãy thiết lập Alertmanager báo động khi RAM của một tiến trình vượt ngưỡng 80%, thay vì đợi cả server treo mới xử lý.

Nắm rõ sức khỏe đến từng tiến trình giúp mình tự tin hơn khi scale hệ thống. Hy vọng hướng dẫn này giúp anh em bớt đau đầu mỗi khi CPU server nhảy vọt.

Share:
Tags: