dashboard monitoring เซิร์ฟเวอร์

Monitor VPS อย่างไรไม่ให้เซิร์ฟเวอร์พังโดยไม่รู้ตัว

มิถุนายน 2026 · อ่าน 6 นาที

เซิร์ฟเวอร์ล่มตอนดึกโดยไม่มีใครรู้คือฝันร้ายของทุกคนที่มี VPS บทความนี้รวมเครื่องมือและวิธีตั้ง monitoring ที่ใช้งานได้จริงโดยไม่ต้องจ่ายเงิน


สิ่งที่ควร Monitor

ตรวจสอบแบบพื้นฐานด้วย 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 แทน


สัญญาณเตือนที่ไม่ควรมองข้าม

ตั้ง 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"
Port ที่ไม่ควรเปิดออก internet: 3306 (MySQL), 5432 (PostgreSQL), 6379 (Redis), 11211 (Memcached), 19999 (Netdata) — ควร bind เฉพาะ 127.0.0.1 หรือ block ด้วย firewall

ดู 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 /
Tip: ตั้ง alert ทดสอบที่ threshold ต่ำๆ (เช่น CPU > 1%) ครั้งแรกเพื่อยืนยันว่า notification channel (email/Telegram/Line) ส่งถึงจริง แล้วค่อยปรับ threshold กลับเป็นค่าใช้งานจริง — อย่ารอให้ระบบล่มจริงแล้วเพิ่งรู้ว่า alert ไม่เคยทำงาน

แก้ปัญหาที่พบบ่อย

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
Security: อย่าเปิด port 3001 ออก internet โดยตรง ให้ใช้ Nginx reverse proxy + basic auth หรือ SSH tunnel แทน

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 ก่อน แล้วค่อยขยายเพิ่มตามความจำเป็น