Bài 15: Monitoring và alert cơ bản

Bài 15: Monitoring và alert cơ bản

Bài này giúp anh hiểu cần monitor gì trên server, alert thế nào cho hữu ích và cách kiểm tra nhanh khi có cảnh báo.

Sau bài này anh sẽ biết:

  • Monitoring khác alert như thế nào.
  • Những metric cơ bản cần theo dõi.
  • Alert nào nên có cho server/web/database.
  • Checklist phản ứng khi có cảnh báo.

Chốt ý nhanh

Chủ đề Điểm cần nhớ
Monitoring Giúp anh thấy hệ thống đang thế nào trước khi user phàn nàn.
Alert Chỉ có ý nghĩa nếu đủ rõ để biết cần làm gì tiếp theo.
Vận hành tốt Không chỉ có dashboard đẹp, mà phải có ngưỡng, người nhận và runbook phản ứng.

1. Monitoring là gì?

Monitoring là theo dõi hệ thống qua metric/log/health check. Alert là cảnh báo khi chỉ số vượt ngưỡng cần hành động.

2. Metric cơ bản cần theo dõi

Nhóm Metric Vì sao quan trọng
CPU usage, load Server quá tải
RAM used, available, swap App có thể bị OOM
Disk used %, inode Disk đầy làm service lỗi
Network traffic, error Debug nghẽn mạng
Service up/down, HTTP status User có truy cập được không

3. Lệnh kiểm tra thủ công

uptime
free -h
df -h
df -i
systemctl --failed
curl -I https://example.com
journalctl -p err --since "1 hour ago"

4. Alert nên có cho server nhỏ

  • Disk used > 85% trong 10 phút.
  • Service Nginx/App/Database down.
  • HTTP health check fail.
  • SSL certificate sắp hết hạn.
  • Backup job fail.

5. Tình huống thực tế

Alert disk 90%. Anh kiểm tra df -h, tìm thư mục lớn bằng du, xác định log/backup/upload tăng bất thường, xử lý tạm thời rồi thêm logrotate/retention.

6. Alert tốt và alert xấu

Alert tốt cần có hành động rõ. Ví dụ “Disk /var còn dưới 15%, xem runbook link”. Alert xấu là cảnh báo quá nhiều, không rõ cần làm gì.

7. Checklist khi nhận alert

  1. Xác nhận alert thật hay false positive.
  2. Xác định mức ảnh hưởng user.
  3. Kiểm tra metric/log liên quan.
  4. Khôi phục dịch vụ nếu cần.
  5. Ghi lại nguyên nhân và hành động phòng ngừa.

8. Lỗi thường gặp

  • Chỉ có dashboard, không có alert.
  • Alert quá nhạy gây nhiễu.
  • Không monitor backup/SSL.
  • Không có người nhận cảnh báo rõ ràng.
Lưu ý production: Alert mà không có runbook thì người trực vẫn phải đoán. Mỗi alert quan trọng nên có hướng xử lý.

9. Bài tập

  1. Viết danh sách 5 alert cần có cho một website.
  2. Chạy các lệnh kiểm tra CPU/RAM/disk/service.
  3. Viết runbook ngắn cho alert disk 90%.

Phần thực hành mở rộng: monitoring và alert theo hướng có hành động

Rất nhiều hệ thống có dashboard nhưng không thật sự được quan sát. Bài này cần giúp người học hiểu monitoring không phải để ngắm, mà để phát hiện, ưu tiên và phản ứng.

Lab 1: Chụp nhanh sức khỏe máy bằng tay

uptime
free -h
df -h
df -i
systemctl --failed
curl -I https://example.com
journalctl -p err --since "1 hour ago"

Đây là bộ kiểm tra thủ công nền tảng mà ngay cả khi chưa có stack monitoring, anh vẫn phải làm được.

Lab 2: Tự thiết kế 5 alert tối thiểu cho một web server

  • Disk usage vượt ngưỡng
  • Nginx/app/database down
  • HTTP health check fail
  • SSL sắp hết hạn
  • Backup job fail

Với mỗi alert, hãy tự viết thêm: ngưỡng, người nhận, mức độ ưu tiên, và hành động đầu tiên.

Lab 3: Phân biệt alert tốt và alert nhiễu

So sánh hai kiểu cảnh báo:

  • Tốt: “Disk /var > 85% trong 10 phút, xem runbook XYZ.”
  • Kém: “Disk warning” nhưng không nói rõ ổ nào, ngưỡng nào, cần làm gì.

Người trực sự cố cần sự rõ ràng, không cần thêm câu đố.

Lab 4: Viết runbook phản ứng ngắn cho một alert

Ví dụ với alert disk 90%:

  1. Xác nhận lại bằng df -hdf -i
  2. Tìm thư mục lớn bằng du
  3. Kiểm tra log/backup/upload/docker
  4. Xử lý tạm thời để giảm áp lực
  5. Ghi lại nguyên nhân gốc và cách phòng ngừa

Tình huống thực tế

Một service có thể down lúc 03:00 mà không ai biết nếu không có alert. Nhưng nếu alert bắn liên tục vì ngưỡng đặt quá nhạy, đội vận hành cũng sẽ sớm bị “lờn” cảnh báo. Bởi vậy monitoring tốt luôn gắn với ngữ cảnh và khả năng hành động.

Lỗi phổ biến

  • Chỉ có dashboard mà không có alert.
  • Có alert nhưng không ai thật sự nhận hoặc xử lý.
  • Ngưỡng quá nhạy gây nhiễu, quá lỏng thì phát hiện quá muộn.
  • Không monitor backup, SSL, expiry hoặc job quan trọng.

Kết bài

Kết thúc bài này, anh đã có một phase 2 khá trọn: biết vào server an toàn, siết firewall, debug network, đọc Nginx, nhìn database, hiểu backup và đặt nền cho monitoring. Đây là lớp kỹ năng đủ thực dụng để bước sang phase 3, nơi mọi thứ sẽ dịch chuyển dần từ “biết vận hành” sang “vận hành sẵn sàng cho production”.

Tác giả: Mạnh Hoàng

Tôi là Hoàng Mạnh, người sáng lập blog SysadminSkills.com. Tôi viết về quản trị hệ thống, bảo mật máy chủ, DevOps và cách ứng dụng AI để tự động hóa công việc IT. Blog này là nơi tôi chia sẻ những gì đã học được từ thực tế – đơn giản, ngắn gọn và áp dụng được ngay.

Để lại một bình luận

Email của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *