Series
- Kiến trúc tổng quan
- Bước 1: Cấu hình webhook nhận alert
- Bước 2: Kết nối UptimeRobot
- Bước 3: Kết nối Grafana
- Bước 4: Cấu hình SSH trong TOOLS.md (xem thêm quản lý nhiều VPS với CMDB)
- Bước 5: Tạo skill riêng và giới hạn quyền (QUAN TRỌNG)
- Bước 6: Cron job kiểm tra định kỳ
- Bước 7: Escalation thông minh
- Kết luận
Hướng dẫn OpenClaw
Bạn đang xem1/14
Xem trang series·Tất cả series
Cơ bản
- . Hướng dẫn OpenClaw chi tiết nhất từ A tới Z
- 2. Cài OpenClaw lên VPS Việt Nam để chạy 24/7
- 3. Tùy biến OpenClaw: Tạo trợ lý AI theo phong cách riêng của bạn
- 4. Tự động hoá với OpenClaw: Cron Jobs, Heartbeats và Webhooks
- 5. Cài đặt và tạo Skills cho OpenClaw: Mở rộng khả năng không giới hạn
Nâng cao
- 6. Kết nối OpenClaw với nhiều AI cùng lúc: Claude, ChatGPT, Gemini
- 7. OpenClaw + GitHub: Quản lý toàn bộ dev workflow bằng chat
- 8. OpenClaw + Home Assistant: Điều khiển nhà thông minh bằng chat
- 9. Tích hợp OpenViking vào OpenClaw: Nâng cấp bộ nhớ AI Agent, giảm 83% token cost
- 12. So sánh cách chạy OpenClaw: VPS, Mac Mini, Windows, Linux, Docker, Raspberry Pi
- 13. OpenClaw hybrid: Gateway trên VPS + Node trên Mac local
- 10. Bảo mật OpenClaw: hướng dẫn cấu hình an toàn theo từng bước
- 11. Một số skill nên cân nhắc cho OpenClaw
- 14. Tối ưu chi phí OpenClaw: Cách giảm 70% token usage mà vẫn giữ chất lượng
Bạn quản trị vài cái VPS, nửa đêm server web sập, CPU tăng 100%, disk đầy. Bạn không biết cho đến khi khách hàng gọi sáng hôm sau. Với UptimeRobot hay Grafana bạn nhận được alert “CPU 95%” nhưng vẫn phải tự SSH vào kiểm tra. Sẽ thế nào nếu có một “NOC engineer” AI túc trực 24/7, tự kiểm tra nguyên nhân và đề xuất xử lý ngay trên Telegram?
Đó chính xác là những gì OpenClaw có thể làm. Bài viết này hướng dẫn biến OpenClaw thành hệ thống giám sát server thông minh, không chỉ cảnh báo mà còn phân tích và hành động.
Kiến trúc tổng quan
Hệ thống gồm ba lớp. Lớp 1 là monitoring tools bên ngoài (UptimeRobot, Grafana, Netdata…) phát hiện sự cố và gửi webhook. Lớp 2 là OpenClaw nhận webhook, phân tích context, tự SSH kiểm tra server nếu cần. Lớp 3 là kênh thông báo (Telegram, Discord, WhatsApp) nơi bot gửi báo cáo và nhận chỉ thị từ bạn.
Khác biệt với monitoring truyền thống: OpenClaw không chỉ forward alert mà hiểu nội dung alert, tự điều tra, và đưa ra đánh giá. Bạn nhận được “CPU 95% trên web-01, nguyên nhân: process mysql chiếm 80% CPU, có 3 slow queries chạy trên 30 giây, đề xuất: kill slow queries và check index” thay vì chỉ “CPU 95%”.
Bước 1: Cấu hình webhook nhận alert
Bật webhook trong OpenClaw:
{
"hooks": {
"enabled": true,
"token": "your-secret-token-here",
"path": "/hooks"
}
}Nếu OpenClaw chạy trên VPS với Tailscale (như hướng dẫn bài 2), webhook URL sẽ là http://your-tailscale-ip:18789/hooks/agent. Nếu cần expose ra internet cho UptimeRobot gọi, dùng openclaw gateway --tailscale serve hoặc đặt sau reverse proxy (Nginx/Caddy) với HTTPS.
Bước 2: Kết nối UptimeRobot
UptimeRobot là dịch vụ monitoring miễn phí phổ biến nhất. Cấu hình để gửi webhook khi server down:
Vào UptimeRobot → My Settings → Add Alert Contact → chọn Webhook. URL điền:
https://your-domain/hooks/agentTrong phần POST body, dùng format:
{
"message": "ALERT: Monitor *monitorFriendlyName* is *alertTypeFriendlyName*. URL: *monitorURL*. Details: *alertDetails*. Hãy kiểm tra server này, SSH vào xem log và báo cáo tình trạng.",
"name": "UptimeRobot",
"deliver": true,
"channel": "telegram"
}Header thêm Authorization: Bearer your-secret-token-here. Khi monitor detect server down, UptimeRobot gửi webhook → OpenClaw nhận, đọc message, tự SSH kiểm tra, và gửi báo cáo qua Telegram cho bạn.
Bước 3: Kết nối Grafana
Nếu bạn dùng Grafana cho monitoring chi tiết hơn, cấu hình Contact Point mới:
Vào Grafana → Alerting → Contact Points → New Contact Point. Chọn type Webhook, URL: https://your-domain/hooks/agent. Trong phần HTTP Headers thêm Authorization: Bearer your-secret-token-here.
Custom message template:
{
"message": "Grafana Alert: {{ .CommonLabels.alertname }} trên {{ .CommonLabels.instance }}. Status: {{ .Status }}. Giá trị hiện tại: {{ .CommonAnnotations.value }}. Hãy SSH vào server kiểm tra và đề xuất cách xử lý.",
"name": "Grafana",
"deliver": true,
"channel": "telegram"
}Bước 4: Cấu hình SSH trong TOOLS.md (xem thêm quản lý nhiều VPS với CMDB)
Để bot tự SSH kiểm tra server, ghi thông tin kết nối vào TOOLS.md trong workspace:
### Servers
- web-01 → 10.0.0.1 (Tailscale), user: admin, role: web server (Nginx + PHP)
- db-01 → 10.0.0.2 (Tailscale), user: admin, role: database (MySQL 8)
- app-01 → 10.0.0.3 (Tailscale), user: deploy, role: application (Node.js)
### Ngưỡng cảnh báo
- CPU > 80% liên tục 5 phút → kiểm tra top processes
- RAM > 90% → kiểm tra memory leak
- Disk > 85% → kiểm tra log files và /tmp
- Load average > số CPU cores × 2 → kiểm tra I/O waitKhi nhận alert, bot đọc TOOLS.md để biết server nào ở đâu, SSH vào bằng key (đã setup trước), chạy các lệnh kiểm tra phù hợp với vai trò server.
Để mượt hơn, bạn có thể setup các server thêm SSH Key cho server đang chạy OpenClaw, bạn có thể đặt passphrase cho key và cung cấp nó cho OpenClaw, bot sẽ tự SSH và làm việc như thật.
Bước 5: Tạo skill riêng và giới hạn quyền (QUAN TRỌNG)
Đây là bước quan trọng nhất trong toàn bộ bài viết. Trước khi cho AI tự SSH vào server, bạn cần hiểu rõ: AI có thể chạy BẤT KỲ lệnh nào mà user SSH có quyền thực thi. Nếu không giới hạn, một lệnh rm -rf / hay DROP DATABASE vô tình được tạo ra sẽ gây hậu quả không thể khắc phục.
Thay vì chỉ ghi rules trong AGENTS.md (bot có thể “quên” hoặc hiểu sai), hãy tạo một skill riêng cho monitoring với danh sách lệnh được phép và bị cấm rõ ràng, hãy nên nhớ chỉ cho phép những gì an toàn chứ không nên cấm những gì bạn muốn cấm.
Tạo skill tại ~/.openclaw/workspace/skills/server-monitor/SKILL.md:
---
name: server-monitor
description: Giám sát và kiểm tra sức khoẻ server. Dùng khi nhận alert, kiểm tra server, hoặc troubleshoot sự cố.
---
# Server Monitor
## ĐỌC KỸ TRƯỚC KHI LÀM BẤT CỨ GÌ
### ✅ Lệnh ĐƯỢC PHÉP chạy trên server
Chỉ được chạy các lệnh sau (read-only, không thay đổi hệ thống):
- `top -bn1` / `htop` — kiểm tra CPU, processes
- `free -h` — kiểm tra RAM
- `df -h` — kiểm tra disk
- `uptime` — thời gian hoạt động, load average
- `ps aux` — danh sách processes
- `tail -n 100 /var/log/...` — đọc log (CHỈ tail, KHÔNG cat file lớn)
- `journalctl -u service --since "1 hour ago"` — log systemd
- `systemctl status service` — trạng thái dịch vụ
- `netstat -tlnp` / `ss -tlnp` — kiểm tra ports
- `du -sh /path` — kiểm tra dung lượng thư mục
- `mysql -e "SHOW PROCESSLIST"` — kiểm tra MySQL queries
- `nginx -t` — test config Nginx (không apply)
- `curl -I https://tech.nhatkychuyenhoa.link` — health check nội bộ
### ⚠️ Lệnh ĐƯỢC PHÉP nhưng CẦN HỎI TRƯỚC
Phải hỏi và được confirm trước khi chạy:
- `systemctl restart nginx/php-fpm/mysql` — restart dịch vụ
- `kill PID` — kill process cụ thể
- `truncate -s 0 /var/log/file.log` — xoá nội dung log file (giải phóng disk)
- `apt update && apt list --upgradable` — kiểm tra updates
### 🚫 TUYỆT ĐỐI KHÔNG ĐƯỢC chạy
KHÔNG BAO GIỜ chạy các lệnh sau, dù user yêu cầu cũng PHẢI TỪ CHỐI:
- `rm -rf` / `rm -r` — xoá file/thư mục đệ quy
- `dd` — ghi đĩa trực tiếp
- `mkfs` — format partition
- `reboot` / `shutdown` — restart/tắt server
- `chmod -R` / `chown -R` — thay đổi quyền đệ quy
- `iptables -F` — xoá firewall rules
- `DROP DATABASE` / `DROP TABLE` — xoá database
- `truncate` trên file KHÔNG phải log
- `wget/curl URL | bash` — chạy script từ internet
- `> /etc/...` — ghi đè file config hệ thống
- Bất kỳ lệnh nào có `sudo` mà không nằm trong danh sách cho phép
### Quy trình khi nhận alert
1. Đọc alert, xác định server và vấn đề
2. SSH vào server, CHỈ chạy lệnh trong danh sách ĐƯỢC PHÉP
3. Phân tích kết quả, xác định nguyên nhân
4. Đề xuất cách xử lý (KHÔNG tự làm)
5. Chờ confirm từ người dùng trước khi chạy lệnh trong danh sách CẦN HỎI
### Nguyên tắc vàng
- Khi nghi ngờ → KHÔNG chạy, HỎI trước
- Ưu tiên đọc (read) hơn ghi (write)
- Luôn dùng `trash` thay `rm` nếu có sẵn
- Log lại mọi hành động đã thực hiện vào memoryTại sao cần skill riêng thay vì chỉ ghi rules trong AGENTS.md? Vì skill được nạp tự động mỗi khi bot nhận diện tác vụ monitoring. AGENTS.md là hướng dẫn chung, bot đọc một lần rồi có thể “quên” trong context dài. Skill thì được inject trực tiếp vào context khi cần, đảm bảo rules luôn có mặt.
Thêm một lớp bảo vệ nữa: tạo user SSH riêng trên server với quyền hạn chế. Thay vì cho bot dùng user root hay admin, tạo user monitor chỉ có quyền đọc log và kiểm tra trạng thái:
# Trên server cần giám sát
sudo useradd -m -s /bin/bash monitor
sudo usermod -aG adm monitor # đọc được log files
# Chỉ cho phép chạy một số lệnh qua sudoers
echo "monitor ALL=(ALL) NOPASSWD: /usr/bin/systemctl status *, /usr/bin/journalctl *" | sudo tee /etc/sudoers.d/monitorVới setup này, ngay cả khi bot “nổi loạn” chạy rm -rf /, user monitor không có quyền xoá files hệ thống. Đây là defense-in-depth: bảo vệ nhiều lớp, không phụ thuộc vào một điểm duy nhất.
Bước 6: Cron job kiểm tra định kỳ
Không chỉ phản ứng khi có alert, bạn có thể chủ động kiểm tra:
# Kiểm tra tất cả server mỗi 6 tiếng
openclaw cron add "Kiểm tra sức khoẻ tất cả server trong TOOLS.md: CPU, RAM, disk, uptime, số process. Báo cáo ngắn gọn, chỉ cảnh báo nếu có vấn đề." \
--every 6h --channel telegram
# Kiểm tra SSL certificate mỗi ngày
openclaw cron add "Kiểm tra SSL certificate của tất cả domain trong TOOLS.md, cảnh báo nếu cert hết hạn trong 14 ngày." \
--every 24h --channel telegram
# Kiểm tra security updates hàng tuần
openclaw cron add "SSH vào tất cả server, chạy apt list --upgradable, tổng hợp danh sách packages cần update. Ưu tiên security updates." \
--cron "0 9 * * 1" --channel telegramBước 7: Escalation thông minh
Cấu hình trong AGENTS.md để bot biết khi nào cần hành động gì:
## Server Monitoring Rules
- Alert nhẹ (disk > 85%, CPU spike ngắn): ghi log vào memory, KHÔNG gửi tin nhắn nếu 23h-7h
- Alert trung bình (service down, high load > 10 phút): gửi Telegram ngay, kèm đề xuất fix
- Alert nặng (server unreachable, disk > 95%): gửi Telegram ngay bất kể giờ nào
- Được phép tự restart service nếu: nginx, php-fpm, mysql đã down > 5 phút
- KHÔNG được phép: xoá file, thay đổi config, reboot server — phải hỏi trướcBot đọc rules này và hành xử tương ứng. Alert nhẹ lúc 2 giờ sáng? Ghi log, sáng mai báo cáo. Server unreachable? Gửi tin nhắn ngay lập tức.
Kết luận
OpenClaw (xem hướng dẫn cài đặt) không thay thế monitoring tools chuyên nghiệp như Prometheus hay Datadog. Nhưng nó bổ sung lớp “thông minh” mà các tool truyền thống thiếu: khả năng phân tích, điều tra nguyên nhân, và đề xuất hành động. Kết hợp UptimeRobot (miễn phí) + OpenClaw + Telegram, bạn có hệ thống giám sát tương đương NOC engineer junior với chi phí gần như bằng không. Để đạt uptime tốt nhất, nên deploy OpenClaw trên VPS thay vì máy cá nhân.
💡 Chạy OpenClaw trên VPS nào cho ổn?
Để hệ thống giám sát chạy 24/7 không gián đoạn, bạn cần một VPS ổn định và không bị downtime. Một vài gợi ý từ AZDIGI:
- AMD Cloud Server (từ 99k/tháng) — chạy AMD EPYC, NVMe phân tán, có High Availability và auto failover. Server giám sát mà tự nó cũng cần được “HA” thì mới yên tâm.
- Platinum Cloud Server (từ 99k/tháng) — Intel Xeon Platinum, cũng HA, phù hợp nếu bạn cần chạy thêm các service khác song song.
- OpenClaw VPS — gói VPS được tối ưu sẵn cho OpenClaw, cài xong là chạy luôn, không cần config thêm.
Nếu bạn đang chạy OpenClaw trên máy cá nhân và muốn chuyển lên VPS để giám sát server liên tục, đây là những lựa chọn đáng cân nhắc.
Thêm một lựa chọn hạ tầng nếu bạn muốn chạy lâu dài
Nếu bạn thấy mô hình OpenClaw kiểu “NOC engineer” này hữu ích và muốn chạy 24/7 ổn định hơn thay vì đặt trên máy cá nhân, bạn có thể chuyển sang hạ tầng VPS hoặc Cloud Server để chủ động hơn về uptime. Với nhu cầu triển khai cơ bản, Pro VPS đủ để dựng môi trường Linux riêng, cài Docker, Tailscale và các tác vụ giám sát quen thuộc.
Trong trường hợp bạn cần hiệu năng lưu trữ tốt hơn hoặc muốn mở rộng dần workload, X-Platinum VPS và AMD Cloud Server là hai lựa chọn đáng cân nhắc. Nếu mục tiêu là dựng nhanh một môi trường dành riêng cho OpenClaw, bạn cũng có thể xem thêm giải pháp OpenClaw VPS từ AZDIGI.
- Pro VPS: phù hợp để bắt đầu với chi phí gọn và dễ cấu hình.
- X-Platinum VPS: hợp với nhu cầu cần NVMe và tốc độ phản hồi tốt hơn.
- AMD Cloud Server / OpenClaw VPS: phù hợp khi bạn muốn chạy ổn định lâu dài và dễ nâng cấp thêm tài nguyên.
Các bài trong serie:
- Bài 1: Hướng dẫn OpenClaw từ A-Z cho người mới bắt đầu
- Bài 2: Cài OpenClaw lên VPS Việt Nam để chạy 24/7
- Bài 3: Tùy biến OpenClaw: Tạo trợ lý AI theo phong cách riêng
- Bài 4: Tự động hoá: Cron Jobs, Heartbeats và Webhooks
- Bài 5: Cài đặt và tạo Skills cho OpenClaw
- Bài 6: Kết nối nhiều AI cùng lúc: Claude, ChatGPT, Gemini
- Bài 7: OpenClaw cho team
- Bài 8: 10 cách sử dụng OpenClaw hữu ích
- Bài 9: Biến OpenClaw thành NOC Engineer (bài này)
- Hướng dẫn OpenClaw
- Cơ bản
- Nâng cao
- Kiến trúc tổng quan
- Bước 1: Cấu hình webhook nhận alert
- Bước 2: Kết nối UptimeRobot
- Bước 3: Kết nối Grafana
- Bước 4: Cấu hình SSH trong TOOLS.md (xem thêm quản lý nhiều VPS với CMDB)
- Bước 5: Tạo skill riêng và giới hạn quyền (QUAN TRỌNG)
- Bước 6: Cron job kiểm tra định kỳ
- Bước 7: Escalation thông minh
- Kết luận
- 💡 Chạy OpenClaw trên VPS nào cho ổn?
- Thêm một lựa chọn hạ tầng nếu bạn muốn chạy lâu dài
No Comment! Be the first one.