Bài 30: Prometheus và Grafana nhập môn

# prometheus scrape config mẫu
scrape_configs:
– job_name: node
static_configs:
– targets: ["server1:9100"]

systemctl status prometheus || true
systemctl status grafana-server || true</pre><h2>4. Tình huống thực tế</h2><div class="note"><p>Anh cần dashboard CPU/RAM/disk/network cho nhiều server. Prometheus thu metric, Grafana hiển thị dashboard và alert khi vượt ngưỡng.</p></div><h2>5. Quy trình áp dụng an toàn</h2><ol><li>Viết cấu hình hoặc command trong môi trường lab.</li><li>Kiểm tra syntax/plan/status trước khi apply.</li><li>Chạy với phạm vi nhỏ trước.</li><li>Quan sát log, metric và health check.</li><li>Ghi lại thay đổi vào tài liệu vận hành.</li><li>Chuẩn bị rollback hoặc version trước đó.</li></ol><h2>6. Lỗi thường gặp</h2><ul><li>Copy cấu hình từ mạng mà không hiểu biến/môi trường.</li><li>Không lưu file cấu hình vào Git.</li><li>Không kiểm tra log sau khi apply.</li><li>Không có môi trường test/staging.</li></ul><div class="warn"><strong>Lưu ý production:</strong> Công cụ tự động hóa giúp làm nhanh hơn, nhưng cũng có thể làm sai hàng loạt nhanh hơn. Luôn giới hạn phạm vi khi mới triển khai.</div><h2>7. Checklist</h2><div class="check"><ul><li>Có file cấu hình rõ ràng.</li><li>Có bước kiểm tra trước khi apply.</li><li>Có log/health check sau khi apply.</li><li>Có rollback/version cũ.</li><li>Có tài liệu ai chạy, chạy khi nào, kết quả gì.</li></ul></div><h2>8. Bài tập</h2><ol><li>Dựng một lab nhỏ theo lệnh mẫu.</li><li>Chạy lệnh kiểm tra trạng thái trước/sau.</li><li>Tạo một lỗi cấu hình nhỏ và sửa lại.</li><li>Viết checklist production cho chủ đề này.</li></ol><div class="next"><strong>Bài tiếp theo:</strong> Incident response cho SysAdmin</div></div>

Chốt ý nhanh

Chủ đề	Điểm cần nhớ
Prometheus	Thu thập metrics theo mô hình pull và lưu thành time series để quan sát hệ thống theo thời gian.
Grafana	Giúp trực quan hóa dữ liệu để nhìn xu hướng, bất thường và tình trạng hiện tại.
Góc nhìn thực tế	Monitoring tốt không phải là có thật nhiều dashboard, mà là nhìn ra điều gì đang xấu đi trước khi dịch vụ chết.

Phần thực hành mở rộng: monitoring bằng metrics có ý nghĩa vận hành

Bài nhập môn monitoring rất dễ bị biến thành “cài Prometheus, cài Grafana, xong”. Nhưng người học cần hiểu sâu hơn: metric nào đáng theo dõi, biểu đồ nào giúp ra quyết định và alert nào thật sự hữu ích.

Lab 1: Xác định các metric nền tảng của một server

CPU usage / load average
RAM used / available
disk usage / inode
network traffic
service up/down

Trước khi cài tool, phải biết mình muốn quan sát điều gì.

Lab 2: Dựng lab Prometheus + Grafana bằng Compose

mkdir -p ~/monitoring-lab && cd ~/monitoring-lab
cat <<'EOF' > docker-compose.yml
services:
  prometheus:
    image: prom/prometheus
    ports:
      - "9090:9090"
  grafana:
    image: grafana/grafana
    ports:
      - "3000:3000"
EOF
docker compose up -d
docker compose ps

Lab này thiên về hình dung kiến trúc hơn là production-ready setup.

Lab 3: Tự diễn giải một vài biểu đồ cơ bản

Ví dụ:

CPU tăng ngắn hạn nhưng load thấp: có thể bình thường
RAM đầy nhưng cache reclaim được: chưa chắc là sự cố
disk tăng đều mỗi ngày: cần dự báo sớm

Đây là kỹ năng quan trọng hơn chuyện bấm nút tạo chart.

Lab 4: Tạo alert tối thiểu trên giấy

disk > 85%
node down
service endpoint trả lỗi liên tục
memory pressure kéo dài

Mỗi alert nên đi kèm: ngưỡng, thời gian duy trì, người nhận và hành động đầu tiên.

Lab 5: So sánh “dashboard đẹp” và “dashboard hữu ích”

Tự đánh giá một dashboard theo 3 câu hỏi:

nó giúp phát hiện sự cố gì?
nó giúp xác định phạm vi ảnh hưởng gì?
nó giúp quyết định hành động gì?

Tình huống thực tế

Nhiều đội có Grafana rất đẹp nhưng lúc sự cố vẫn không biết nhìn đâu đầu tiên. Lý do là dashboard được làm để “trông chuyên nghiệp”, không phải để phục vụ quyết định vận hành.

Lỗi phổ biến

Thu quá nhiều metrics mà không biết metric nào quan trọng.
Chỉ nhìn snapshot hiện tại mà không xem trend theo thời gian.
Alert quá nhạy gây nhiễu, rồi dần bị bỏ qua.
Không có runbook đi kèm alert.

Kết bài

Nếu bài này chắc, anh sẽ bắt đầu nhìn monitoring như một hệ thống hỗ trợ ra quyết định, không chỉ là bộ dashboard treo tường. Từ đây sang incident response, anh sẽ ghép thêm một lớp rất thực tế: khi alert đã nổ, đội vận hành phải phản ứng thế nào.