Monitor VPS อย่างไรไม่ให้เซิร์ฟเวอร์พังโดยไม่รู้ตัว
เซิร์ฟเวอร์ล่มตอนดึกโดยไม่มีใครรู้คือฝันร้ายของทุกคนที่มี VPS บทความนี้รวมเครื่องมือและวิธีตั้ง monitoring ที่ใช้งานได้จริงโดยไม่ต้องจ่ายเงิน
สิ่งที่ควร Monitor
- CPU Usage — ถ้าพุ่งเกิน 90% ต่อเนื่อง แปลว่ามีอะไรผิดปกติ
- RAM — เต็มแล้วระบบเริ่ม swap ความเร็วตกหนัก
- Disk Space — เต็มแล้ว database เขียนไม่ได้ เว็บพัง
- Uptime / Downtime — เว็บยังตอบสนองอยู่ไหม
- Load Average — ค่าเฉลี่ยงานที่เซิร์ฟเวอร์รับ (1/5/15 นาที)
ตรวจสอบแบบพื้นฐานด้วย Command Line
# ดู CPU, RAM, Load ในแบบ real-time
top
htop # สวยกว่า ต้องติดตั้งเพิ่ม
# ดู Disk Space
df -h
# ดู RAM
free -h
# ดู Load Average
uptime
# ดู process ที่กิน resource มากสุด
ps aux --sort=-%cpu | head -10
ตั้ง Alert อีเมลเมื่อ Disk ใกล้เต็ม
สร้างสคริปต์ /usr/local/bin/disk-check.sh:
#!/bin/bash
THRESHOLD=85
USAGE=$(df / | tail -1 | awk '{print $5}' | sed 's/%//')
if [ "$USAGE" -gt "$THRESHOLD" ]; then
echo "Disk usage is ${USAGE}% on $(hostname)" | \
mail -s "ALERT: Disk Space Low" [email protected]
fi
เพิ่มใน crontab ให้รันทุกชั่วโมง:
0 * * * * /usr/local/bin/disk-check.sh
Uptime Kuma: Monitoring ที่ติดตั้งบน VPS ได้เอง
Uptime Kuma คือ open-source uptime monitor ที่ติดตั้งบน VPS ของตัวเองได้ มี UI สวย แจ้งเตือนผ่าน Line, Telegram, Email, Slack และอื่น ๆ
ติดตั้งด้วย Docker:
docker run -d --restart=always -p 3001:3001 \
-v uptime-kuma:/app/data \
--name uptime-kuma louislam/uptime-kuma:1
เปิดที่ http://your-server:3001 แล้วตั้งค่า monitor รายการเว็บที่ต้องการตรวจ
Netdata: Real-time Monitoring ฟรีพร้อม Dashboard
bash <(curl -Ss https://my-netdata.io/kickstart.sh)
เปิดที่ port 19999 จะเห็น dashboard แสดง metric แบบ real-time ทุก 1 วินาที
ข้อควรระวัง: เปิด port 19999 ออก internet โดยตรงถือว่าเสี่ยง ควร block ด้วย firewall แล้วใช้ SSH tunnel แทน
สัญญาณเตือนที่ไม่ควรมองข้าม
- Load average สูงกว่าจำนวน CPU core อยู่ตลอดเวลา
- Memory swap ใช้งานมากกว่า 0 อย่างต่อเนื่อง
- Disk เต็มมากกว่า 80% และไม่มีแผนล้างข้อมูล
- Log เต็มไปด้วย "connection refused" หรือ "too many open files"
ตั้ง Alert แจ้งเตือนหลายช่องทาง
นอกจาก Uptime Kuma แล้ว สามารถตั้ง alert ด้วย script ง่าย ๆ สำหรับ metric ที่สำคัญ:
#!/bin/bash
# /usr/local/bin/health-check.sh
HOSTNAME=$(hostname)
ALERT_EMAIL="[email protected]"
# ตรวจ Disk
DISK=$(df / | tail -1 | awk '{print $5}' | tr -d '%')
[ "$DISK" -gt 85 ] && echo "Disk ${DISK}% on $HOSTNAME" | \
mail -s "ALERT: Disk Full" $ALERT_EMAIL
# ตรวจ RAM
MEM_FREE=$(free | awk '/^Mem:/{printf "%.0f", $4/$2*100}')
[ "$MEM_FREE" -lt 10 ] && echo "RAM only ${MEM_FREE}% free on $HOSTNAME" | \
mail -s "ALERT: Low Memory" $ALERT_EMAIL
# ตรวจ Load
LOAD=$(uptime | awk -F'load average:' '{print $2}' | cut -d, -f1 | xargs)
CPU=$(nproc)
LOAD_INT=$(echo "$LOAD * 10" | bc | cut -d. -f1)
[ "$LOAD_INT" -gt "$((CPU * 10))" ] && echo "High load $LOAD on $HOSTNAME" | \
mail -s "ALERT: High CPU Load" $ALERT_EMAIL
chmod +x /usr/local/bin/health-check.sh
# เพิ่มใน crontab ให้รันทุก 10 นาที
*/10 * * * * /usr/local/bin/health-check.sh
ตรวจสอบ Port ที่เปิดอยู่
ตรวจ port ที่ listen อยู่เพื่อหา service ที่ไม่ควรเปิด:
# ดู port ทั้งหมดที่ listen อยู่
ss -tlnp
# หรือ
netstat -tlnp
# ดูเฉพาะ port ที่ accessible จากภายนอก (ไม่ใช่ 127.0.0.1)
ss -tlnp | grep -v "127.0.0.1\|::1"
ดู Log แบบ Real-time
# ดู system log แบบ real-time
journalctl -f
# ดู nginx access log + error log พร้อมกัน
tail -f /var/log/nginx/access.log /var/log/nginx/error.log
# ดูเฉพาะ error
journalctl -p err..alert -f
# ดู log ของ service เฉพาะ
journalctl -u nginx -f
ตรวจสอบว่าระบบ Monitoring ทำงานถูกต้อง
หลังติดตั้ง agent/exporter แล้ว ตรวจว่า metric ถูกเก็บและ alert ยิงได้จริง — monitoring ที่ "ติดตั้งแล้วแต่ไม่เคยทดสอบ alert" คือ monitoring ที่เชื่อถือไม่ได้:
# 1. node_exporter ตอบ metric อยู่หรือไม่
curl -s localhost:9100/metrics | head -20
# 2. Prometheus scrape target สำเร็จไหม (state ต้องเป็น up)
curl -s localhost:9090/api/v1/targets | grep -o '"health":"[a-z]*"'
# 3. ทดสอบ alert: จงใจกิน CPU แล้วดูว่า rule ยิง
stress-ng --cpu 4 --timeout 60s # apt install stress-ng
# 4. ตรวจ disk/memory metric ตรงกับของจริง
free -m && df -h /
แก้ปัญหาที่พบบ่อย
htop ไม่พบบน server หลัง install fresh
apt install htop -y # Ubuntu/Debian
yum install htop -y # CentOS/AlmaLinux
Uptime Kuma เข้าไม่ได้ทาง browser
# ตรวจว่า container รันอยู่
docker ps | grep uptime-kuma
# ดู log
docker logs uptime-kuma --tail 50
# ตรวจว่า port 3001 เปิดอยู่
ufw allow 3001/tcp
Disk เต็ม แต่ df -h บอกว่ายังมีพื้นที่
มักเกิดจาก inode เต็ม ไม่ใช่ disk space:
# ตรวจ inode
df -i /
# ถ้า Use% ใกล้ 100% คือ inode เต็ม
# หา directory ที่มีไฟล์เยอะที่สุด
find / -xdev -type f | cut -d/ -f2 | sort | uniq -c | sort -rn | head
Load average สูงแต่ CPU ไม่ถึง 100%
Load average รวม I/O wait ด้วย ถ้า CPU ไม่สูงแต่ load สูง แปลว่า disk I/O เป็นปัญหา:
iostat -x 1 5 # ดู disk I/O
# ถ้า %util ใกล้ 100% แปลว่า disk saturated
iotop # ดูว่า process ไหนใช้ disk มาก
คำถามที่พบบ่อย
จะ monitor VPS หลายเครื่องพร้อมกันได้อย่างไร?
ติดตั้ง Uptime Kuma บนเครื่องเดียว แล้ว add monitor URL/IP ของ VPS แต่ละเครื่องเข้าไป หรือใช้ Netdata Cloud ที่รวม dashboard จาก multiple server ได้ฟรีจนถึง 5 nodes
Netdata กินทรัพยากรมากไหม?
Netdata ใช้ RAM ประมาณ 50–200 MB และ CPU 1–3% ในสภาวะปกติ สำหรับ VPS 1 GB RAM อาจหนักไปเล็กน้อย แนะนำให้ใช้บน VPS 2 GB ขึ้นไป หรือใช้ script alert + Uptime Kuma แทนซึ่งเบากว่ามาก
ควร monitor อะไรบ้างเป็นอย่างน้อย?
สี่อย่างที่ขาดไม่ได้: (1) HTTP uptime check ทุก 1–5 นาที (2) Disk usage alert เมื่อเกิน 80% (3) SSL certificate expiry alert ล่วงหน้า 14 วัน (4) Memory/swap usage alert เมื่อ free เหลือน้อยกว่า 10% ทั้งสี่อย่างตั้งได้ฟรีด้วย Uptime Kuma หรือ script + cron
ความต่างระหว่าง Load Average กับ CPU Usage คืออะไร?
CPU Usage คือเปอร์เซ็นต์เวลา CPU ที่ใช้ ส่วน Load Average คือจำนวน process ที่รอ CPU หรือ disk I/O เฉลี่ยใน 1/5/15 นาที ค่า load average ที่ปกติควรต่ำกว่าจำนวน CPU core ถ้า load = 2 บน server 1 core = server busy มาก
สรุป
การ monitor ที่ดีไม่จำเป็นต้องแพง Uptime Kuma บน VPS เครื่องเดิมก็ทำงานได้ดี สิ่งสำคัญคือต้องตั้งค่าก่อนที่จะเกิดปัญหา ไม่ใช่หลังจากเว็บพังไปแล้ว เริ่มจาก disk + uptime alert ก่อน แล้วค่อยขยายเพิ่มตามความจำเป็น