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.
- 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ế
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
- Xác nhận alert thật hay false positive.
- Xác định mức ảnh hưởng user.
- Kiểm tra metric/log liên quan.
- Khôi phục dịch vụ nếu cần.
- 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.
9. Bài tập
- Viết danh sách 5 alert cần có cho một website.
- Chạy các lệnh kiểm tra CPU/RAM/disk/service.
- 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%:
- Xác nhận lại bằng
df -hvàdf -i - Tìm thư mục lớn bằng
du - Kiểm tra log/backup/upload/docker
- Xử lý tạm thời để giảm áp lực
- 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”.
