SSD Nodes Learn
คู่มือ Matt Connorโดย Matt Connor · อัปเดตเมื่อ 2026-07-24

วิธีติดตั้ง Uptime Kuma ด้วย Docker

เรียนรู้วิธีรัน Uptime Kuma ผ่าน Docker เพื่อเฝ้าระวังเว็บไซต์และ Port ต่างๆ พร้อมตั้งค่าแจ้งเตือนผ่าน Telegram และการเลือก VPS เพื่อติดตั้งระบบให้มีประสิทธิภาพ

สิ่งที่คุณกำลังสร้าง

Container ขนาดเล็กเพียงตัวเดียวที่ทำหน้าที่ตรวจสอบ server และเว็บไซต์อื่น ๆ จากภายนอก และจะแจ้งเตือนคุณทันทีเมื่อมีบริการใดหยุดตอบสนอง ผ่านทาง email, Telegram, Discord หรือ webhook Uptime Kuma ทำงานด้วย Node process เพียงหนึ่งตัวและใช้ SQLite file เป็นฐานข้อมูล จึงใช้ RAM เพียง 256-512 MB และมีหน้า dashboard แบบ real-time, กราฟประวัติการทำงาน และหน้า status page สาธารณะ การติดตั้งทำได้ง่ายผ่าน Compose file เพียง 10 บรรทัด สิ่งที่สำคัญที่สุดคือ สถานที่ที่คุณติดตั้ง และ การทดสอบว่าระบบแจ้งเตือนทำงานได้จริงหรือไม่ เพราะระบบเฝ้าระวังที่คุณไม่เคยทดสอบว่าสามารถแจ้งเตือนได้จริงนั้นแย่ยิ่งกว่าการไม่มีระบบเลย เนื่องจากมันทำให้คุณรู้สึกปลอดภัยทั้งที่ไม่ได้มีการเฝ้าระวังเกิดขึ้นจริง

รัน monitor ในที่ที่การขัดข้องไม่สามารถเข้าถึงได้

การตัดสินใจนี้มีความสำคัญที่สุดต่อระบบทั้งหมด จึงต้องพิจารณาเป็นอันดับแรก ห้ามรัน Uptime Kuma บนเครื่องเดียวกับบริการที่ต้องการเฝ้าติดตาม หาก monitor อยู่บนเซิร์ฟเวอร์เดียวกับที่มันเฝ้าติดตาม เมื่อเกิดเหตุการณ์ที่ต้องการตรวจจับ เช่น เซิร์ฟเวอร์หยุดทำงานหรือหน่วยความจำเต็ม จะทำให้ monitor หยุดทำงานไปด้วย และคุณจะไม่ได้รับแจ้งเตือนใดๆ เพราะการที่ monitor ไม่ส่งสัญญาณเนื่องจากเครื่องตาย มีลักษณะเหมือนกับสถานะ "ทุกอย่างปกติ"

นอกจากนี้ยังมีปัญหาที่ซับซ้อนกว่าในขณะที่เครื่องยังทำงานอยู่: monitor ที่ชี้ไปยัง localhost จะต้องใช้ CPU ร่วมกับ workload หากเกิด load spike จะทำให้การตรวจสอบหมดเวลา (timeout) และเปลี่ยนสถานะเป้าหมายเป็น down ซึ่งเป็นการแจ้งเตือนที่ผิดพลาด ทั้งที่ผู้ใช้งานจริงยังสามารถใช้งานได้ตามปกติ

ดังนั้น ควรติดตั้ง Uptime Kuma บน VPS คนละเครื่อง กับเครื่องที่ต้องการเฝ้าติดตาม โดยควรเลือกผู้ให้บริการหรือภูมิภาคที่ต่างกัน เพื่อให้ monitor เข้าถึงบริการของคุณผ่านช่องทางเดียวกับผู้ใช้งาน คือผ่าน public internet โดยใช้ hostname การใช้ instance ราคาถูกก็เพียงพอแล้ว และ VPS สำหรับ monitoring เพียงเครื่องเดียวสามารถเฝ้าติดตามเซิร์ฟเวอร์ทั้งหมดของคุณได้ หากต้องการตรวจจับกรณีที่ Kuma หยุดทำงาน ให้เพิ่มการส่ง push heartbeat จาก cron บนเครื่องอื่นแทน

Prerequisites and sizing

  • Ubuntu 24.04 VPS ที่ติดตั้งใหม่ พร้อม Docker Engine และ Compose v2 plugin โดยต้องติดตั้งจาก Docker apt repository โดยตรง ไม่ใช่จาก package ของ distro docker.io เนื่องจากเวอร์ชันอาจล้าสมัย
  • RAM ขนาด 256 MB สามารถรัน monitor ได้เพียงไม่กี่ตัว แนะนำขนาด 512 MB ถึง 1 GB เพื่อความคล่องตัวในการรัน monitor จำนวนมากพร้อมกับ reverse proxy โดยที่ CPU จะทำงานน้อยมากในช่วงระหว่างการตรวจสอบ
  • Domain และ DNS A record (เช่น status.example.com ที่ชี้ไปยัง VPS) เฉพาะในกรณีที่ ต้องการใช้งาน TLS และหน้า status page แบบสาธารณะ หากใช้งานแบบ private instance สามารถข้ามการตั้งค่า DNS และใช้ VPN หรือ SSH tunnel แทนได้
  • การเชื่อมต่อเครือข่ายขาออก (Outbound network) ไปยังปลายทางที่ต้องการรับการแจ้งเตือน เช่น SMTP สำหรับ mail provider หรือ HTTPS สำหรับ Telegram และ Discord

The Compose file

วางเนื้อหานี้ลงใน /srv/uptime-kuma/compose.yaml

services:
  uptime-kuma:
    image: louislam/uptime-kuma:2
    container_name: uptime-kuma
    restart: unless-stopped
    ports:
      - "127.0.0.1:3001:3001"
    volumes:
      - kuma-data:/app/data

volumes:
  kuma-data:

เริ่มการทำงานและตรวจสอบการ boot ครั้งแรก:

sudo mkdir -p /srv/uptime-kuma
# save the file above as /srv/uptime-kuma/compose.yaml, then:
cd /srv/uptime-kuma && sudo docker compose up -d
sudo docker compose logs -f uptime-kuma

หากเริ่มระบบได้ถูกต้อง จะมี log ของ Listening on 3001 และไม่มีข้อความอื่นปรากฏขึ้น มี 3 จุดในไฟล์นี้ที่ตั้งใจกำหนดไว้

127.0.0.1:3001:3001 ไม่ใช่ 3001:3001. Docker จะทำการ publish port ด้วยกฎ DNAT ซึ่งจะถูกประมวลผล ก่อน ที่ ufw จะตรวจพบ packet ดังนั้นการใช้เพียง 3001:3001 จะทำให้ dashboard ของคุณถูกเปิดสู่สาธารณะบนอินเทอร์เน็ตโดยไม่คำนึงถึง firewall การ bind ไปยัง loopback จะช่วยรักษาความเป็นส่วนตัว โดยจะเปิดให้เข้าถึงได้ผ่าน reverse proxy เท่านั้น; สำหรับ instance ที่เป็นส่วนตัว คุณสามารถข้ามการใช้ proxy และเข้าถึง 3001 ผ่าน a self-hosted WireGuard VPN แทนได้

การใช้ named volume ที่ /app/data. ข้อมูลทั้งหมดที่ Uptime Kuma จดจำไว้ เช่น SQLite database, รายการ monitors, การตั้งค่า notification และโลโก้ของ status-page จะถูกเก็บไว้ที่นั่น หากข้อมูลนี้สูญหาย คุณจะต้องเริ่มใช้งานใหม่จากหน้า admin ที่ว่างเปล่า; นี่คือสิ่งเดียวที่คุณจำเป็นต้องสำรองข้อมูล (back up)

การระบุ image ด้วย major tag คือ :2. นี่คือเวอร์ชัน stable ปัจจุบัน; โปรดตรวจสอบ Docker Hub เพื่อดู major version ล่าสุดก่อนคัดลอก และห้ามใช้ tag ที่มีการเปลี่ยนแปลงตลอดเวลาอย่าง latest เนื่องจากโปรเจกต์ไม่แนะนำให้ใช้ การข้ามเวอร์ชัน (major-version jump) ของ image นี้ จะส่งผลให้เกิดการทำ database migration แบบทางเดียว ซึ่งควรเกิดขึ้นจากการตั้งใจสั่งการเท่านั้น ไม่ควรเกิดขึ้นโดยไม่ตั้งใจจากการสั่ง pull ตามปกติ

ข้อควรระวัง: /app/data ต้องอยู่บน filesystem ที่รองรับ POSIX file locks การใช้ local Docker volume สามารถใช้งานได้; หากใช้ NFS จะทำให้ SQLite database เสียหาย และจะเกิด SQLITE_BUSY และ database disk image is malformed ดังนั้นห้ามใช้ network share โดยเด็ดขาด

การใช้งานครั้งแรก: การสร้างบัญชี admin

เข้าถึง instance ผ่าน proxy ที่ https://status.example.com หรือผ่าน SSH tunnel โดยการรัน ssh -L 3001:127.0.0.1:3001 user@your-vps และเปิด http://localhost:3001 หน้าแรกคือแบบฟอร์มตั้งค่า username และ password สำหรับ administrator โดยไม่มีการกำหนด login เริ่มต้นไว้ โปรดเลือก password ที่ใช้งานได้จริง เนื่องจาก dashboard นี้สามารถเข้าถึง internal addresses และ tokens ของทุกสิ่งที่ท่านกำลัง monitor หากลืม password ในภายหลัง ให้ทำการ reset จาก host แทนการทำผ่าน browser:

sudo docker compose exec uptime-kuma npm run reset-password

เพิ่มช่องทางการแจ้งเตือนก่อน แล้วจึงทำการทดสอบ

ควรตั้งค่าการแจ้งเตือนก่อนเริ่มเพิ่ม monitor เพื่อให้สามารถเลือกช่องทางที่ต้องการได้ทันทีขณะสร้าง monitor แต่ละตัว ให้ไปที่ Settings then Notifications then Setup Notification และใช้ปุ่ม Test ของแต่ละช่องทางเพื่อยืนยันว่าข้อความถูกส่งไปถึง เนื่องจากระบบที่ไม่ได้ผ่านการทดสอบเป็นสาเหตุอันดับสองที่ทำให้การตั้งค่าล้มเหลวโดยไม่ทราบสาเหตุ

Email (SMTP). กรอกข้อมูล host, port, encryption, username, password รวมถึง From และ To การตั้งค่าที่ใช้งานได้มี 2 รูปแบบ คือ 465 โดยตั้งค่า "Secure" เป็น TLS/SSL หรือ 587 โดยใช้ STARTTLS สำหรับ Gmail และผู้ให้บริการส่วนใหญ่ที่เปิดใช้งาน two-factor auth คุณต้องสร้าง app password หากใช้รหัสผ่านปกติจะเกิดข้อผิดพลาด Error: Invalid login: 535-5.7.8 Username and Password not accepted

Telegram. ส่งข้อความ @BotFather, ส่ง /newbot, แล้วคัดลอก bot token สำหรับ chat ID ให้ส่งข้อความหา bot ตัวใหม่หนึ่งครั้ง จากนั้นเปิด https://api.telegram.org/bot<token>/getUpdates และอ่านค่า chat.id จาก JSON หากคุณไม่เคยส่งข้อความหา bot ก่อน จะทำให้ค่า getUpdates ว่างเปล่าและไม่สามารถส่งข้อความได้

Discord. ในช่องแชทที่ต้องการ ให้ไปที่ Edit Channel then Integrations then Webhooks then New Webhook จากนั้นคัดลอก URL และนำไปวางในช่องการแจ้งเตือนแบบ Discord

Generic webhook. สำหรับบริการอื่น ๆ เช่น Slack incoming webhook, custom endpoint หรือ home-automation hook ประเภท Webhook จะส่ง JSON payload ผ่านวิธี POST ไปยัง URL ที่คุณระบุ ทั้งนี้การรวมระบบด้วย Apprise สามารถรองรับบริการอื่น ๆ อีกกว่า 90 รายการที่มีอยู่ในรายการได้

เพิ่ม monitor ทีละประเภท

คลิก Add New Monitor เลือกประเภทที่ต้องการ จากนั้นตั้งค่า Friendly Name, Check Interval (แนะนำที่ 60 seconds) และ Retries (จำนวนครั้งที่ล้มเหลวติดต่อกันก่อนจะระบุว่า "down" แนะนำให้ตั้งค่า 2 หรือ 3 ครั้ง เพื่อป้องกันการแจ้งเตือนผิดพลาดจาก packet ที่สูญหายเพียงครั้งเดียว) รวมถึงตั้งค่าการแจ้งเตือน (notifications) ประเภทของ monitor ที่ใช้งานได้มีดังนี้:

  • HTTP(s). ใช้ URL แบบเต็ม สถานะ "up" หมายถึงได้รับ status code ที่กำหนด (ค่าเริ่มต้นคือ 200-299 หาก 301 หรือ 401 เป็นค่าปกติสำหรับคุณ ให้ขยายช่วงในส่วน Accepted Status Codes) ใช้สำหรับตรวจสอบเว็บไซต์และ API
  • HTTP(s) - Keyword. ใช้การร้องขอแบบเดียวกับ HTTP(s) แต่สถานะ "up" จะต้องพบข้อความที่กำหนดใน body ของการตอบกลับ (หากไม่ได้เลือก Invert) วิธีนี้ช่วยตรวจจับกรณีเว็บไซต์ส่งค่า 200 OK กลับมาพร้อมข้อความ "Error establishing a database connection" ซึ่งการตรวจสอบ HTTP แบบปกติจะมองว่าสถานะปกติ
  • TCP Port. เป็นการเชื่อมต่อ TCP ไปยัง host และ port ที่กำหนด สำหรับบริการที่ไม่ใช่ HTTP เช่น SSH บน port 22, Postgres บน port 5432, SMTP server บน port 25 หรือ game server
  • Ping. ใช้ ICMP echo เพื่อตรวจสอบการเชื่อมต่อ (reachability) และค่าความหน่วง (latency) อย่างรวดเร็ว อย่างไรก็ตาม เครือข่ายหรือ cloud firewall หลายแห่งอาจบล็อก ICMP ดังนั้นหาก monitor แสดงสถานะ ping เป็นสีแดง อาจหมายถึง "host down" หรือ "ผู้ให้บริการบล็อก ping" ให้ตรวจสอบซ้ำด้วย TCP monitor
  • DNS. ใช้ตรวจสอบการ resolve record (เช่น A, AAAA, MX, TXT และอื่นๆ) ผ่าน resolver ที่ระบุ เพื่อตรวจจับปัญหาจากผู้ให้บริการจดทะเบียนโดเมนหรือปัญหา DNS ได้อย่างรวดเร็ว
  • Push. การตรวจสอบแบบส่งข้อมูลจากภายใน (inside-out monitor) ซึ่งจะอธิบายในหัวข้อถัดไป

การตรวจสอบ cron job ด้วยการส่งสัญญาณ (push monitor)

ตัวตรวจสอบทั้งหมดข้างต้นจะทำการตรวจสอบจากภายนอกเข้าไปยัง service ของคุณ แต่ push monitor จะทำงานในทางตรงกันข้าม: Uptime Kuma จะรอรับสัญญาณ และ job ของคุณ จะเป็นฝ่ายเรียกไปยัง Uptime Kuma เพื่อแจ้งว่า "ฉันทำงานแล้ว" นี่เป็นวิธีเดียวที่เชื่อถือได้ในการตรวจสอบการสำรองข้อมูลหรือ cron: การตรวจสอบแบบ HTTP จะทราบเพียงว่า URL ตอบสนองหรือไม่ แต่มีเพียง job เท่านั้นที่ทราบว่าการทำงานเสร็จสมบูรณ์หรือไม่

สร้าง monitor ประเภท Push โดย Uptime Kuma จะสร้าง URL เฉพาะขึ้นมา เช่น:

https://status.example.com/api/push/j8Xa2Kd9Qe?status=up&msg=OK&ping=

กำหนดค่า Heartbeat Interval ให้เท่ากับความถี่ที่ job ทำงาน บวกกับเวลาเผื่อไว้เล็กน้อย จากนั้นเพิ่มคำสั่งหนึ่งบรรทัดไว้ที่ ท้าย ของ script เพื่อให้ส่งสัญญาณเฉพาะเมื่อทำงานสำเร็จเท่านั้น:

#!/usr/bin/env bash
set -euo pipefail
# ... your backup or job runs here; set -e aborts on any failure ...
curl -fsS --retry 3 "https://status.example.com/api/push/j8Xa2Kd9Qe?status=up&msg=backup+ok&ping="

หาก job ล้มเหลว set -e จะหยุดทำงานก่อนที่จะเรียก curl; หากเครื่องเซิร์ฟเวอร์ปิดอยู่ คำสั่งนี้ก็จะไม่ทำงานเช่นกัน ไม่ว่ากรณีใดก็ตามหากสัญญาณ heartbeat หยุดส่ง และเมื่อผ่านช่วงเวลา interval-plus-retries ไปแล้ว Uptime Kuma จะเปลี่ยนสถานะ monitor เป็น down และแจ้งเตือนคุณ โปรดเก็บ push token ไว้เป็นความลับ: ผู้ที่มี token นี้สามารถส่งสัญญาณหลอกว่าระบบยังทำงานปกติได้

การสร้างหน้าสถานะแบบสาธารณะ (Public Status Page)

หน้าสถานะคือส่วนที่แสดงผลแก่ลูกค้า เพื่อบอกว่าบริการใดกำลังใช้งานได้และประวัติการทำงานล่าสุด โดยไม่เปิดเผยข้อมูลใน dashboard ของคุณ ให้ไปที่ Status Pages แล้วเลือก New Status Page จากนั้นตั้งชื่อและ slug (เส้นทางสาธารณะ เช่น /status/main) ลาก monitor ที่ต้องการไปไว้ในกลุ่ม เช่น "Websites" และ "APIs" เพิ่มโลโก้และคำอธิบายสั้นๆ แล้วกด Save คุณสามารถเชื่อมต่อหน้าดังกล่าวเข้ากับ domain ของตนเองเพื่อให้ status.example.com ทำหน้าที่ให้บริการโดยตรงได้

ข้อควรระวัง 2 ประการ: หนึ่งคือควรเพิ่มเฉพาะ monitor ที่คุณยินดีเปิดเผยต่อสาธารณะเท่านั้น เนื่องจากหน้าสถานะจะระบุว่ามีบริการนั้นอยู่และสถานะการทำงานปัจจุบันคืออะไร และสองคือ dashboard จะถูกจำกัดสิทธิ์ไว้ภายใต้การ login ของคุณ ในขณะที่หน้าสถานะถูกตั้งค่าให้เป็นสาธารณะและไม่จำเป็นต้องมีการยืนยันตัวตน (auth)

การใช้งานผ่าน reverse proxy พร้อม TLS และข้อควรระวังเรื่อง websockets

สำหรับการใช้งานแบบ public ให้ติดตั้ง reverse proxy ไว้หน้า container ที่ผูกกับ loopback เพื่อใช้งาน TLS และ hostname รายละเอียดที่มักทำให้เกิดปัญหาคือ: UI ของ Uptime Kuma ทำงานผ่าน Socket.IO ดังนั้น proxy ต้องรองรับการ upgrade การเชื่อมต่อเป็น WebSocket หากตั้งค่าส่วนนี้ไม่ถูกต้อง หน้าเว็บจะโหลดขึ้นมาแต่จะไม่สามารถเชื่อมต่อได้ โดย dashboard จะค้างอยู่ที่สถานะ "Connecting..." และค่า heartbeat จะไม่ถูกอัปเดต ซึ่งจะปรากฏข้อผิดพลาด WebSocket connection to 'wss://.../socket.io/...' failed ใน browser console

ติดตั้ง nginx และ certbot จากนั้นเขียน vhost เพื่อ proxy ไปยัง loopback port ให้เริ่มใช้งานผ่าน port 80 ก่อน แล้วจึงใช้ certbot เพื่อเพิ่ม TLS ในภายหลัง; รายละเอียดเรื่องความท้าทาย, ตัวตั้งเวลาการต่ออายุ (renewal timer) และรูปแบบความผิดพลาดที่อาจเกิดขึ้น มีระบุไว้ใน issuing Let's Encrypt certificates with certbot and nginx

sudo apt install -y nginx certbot python3-certbot-nginx

บันทึกไฟล์นี้เป็น /etc/nginx/sites-available/status.example.com; โดยบรรทัด WebSocket ทั้งสองบรรทัดคือส่วนที่สำคัญที่สุด:

server {
    listen 80;
    server_name status.example.com;

    location / {
        proxy_pass http://127.0.0.1:3001;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_read_timeout 3600s;
    }
}

เปิดใช้งาน site, ทดสอบการตั้งค่า (config) จากนั้นให้ certbot ทำการเขียน block ใหม่เพื่อรับการเชื่อมต่อผ่าน port 443 พร้อมทั้งใส่ certificate และเพิ่มการ redirect จาก HTTP ไปยัง HTTPS:

sudo ln -s /etc/nginx/sites-available/status.example.com /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx
sudo certbot --nginx -d status.example.com

การตั้งค่าคู่ Upgrade และ Connection "upgrade" คือส่วนที่สำคัญที่สุด และ proxy_read_timeout 3600s จะช่วยป้องกันไม่ให้ nginx ตัดการเชื่อมต่อ socket ที่ค้างไว้; certbot จะคัดลอกทั้งสองส่วนนี้ลงใน block 443 ที่สร้างขึ้น หากคุณใช้งานหลาย container ผ่าน proxy ตัวเดียว routing them through Traefik with automatic TLS สามารถทำหน้าที่นี้ได้เช่นกันโดยใช้ container labels และจะทำการ forward การ upgrade WebSocket ให้โดยอัตโนมัติ

ห้ามใช้ basic-auth กับ vhost ทั้งหมด เพราะจะทำให้ไม่สามารถเข้าถึง public status page และ endpoint /api/push ได้ ให้ใช้ระบบ login ที่มากับ Uptime Kuma และควรติดตั้ง fail2ban watching for repeated failed logins หากระบบเชื่อมต่อกับอินเทอร์เน็ต และหากไม่จำเป็นต้องให้ dashboard เป็นสาธารณะ ให้ยกเลิกการใช้ proxy และเข้าใช้งานผ่าน VPN แทน

การตรวจสอบวันหมดอายุของ Certificate อย่างถูกต้อง

HTTP(s) monitor สามารถแจ้งเตือนก่อนที่ TLS certificate จะหมดอายุได้ โดยเลือกที่ Certificate Expiry Notification เพื่อให้ Uptime Kuma แจ้งเตือนล่วงหน้าตามจำนวนวันที่กำหนด หากตั้งค่าผิดพลาดจะทำให้การตรวจสอบผิดพลาดได้ มีข้อผิดพลาด 2 ประการดังนี้:

  1. ให้ตรวจสอบด้วย hostname แทนการใช้ IP หากส่ง request โดยไม่มี SNI ระบบจะได้รับ certificate เริ่มต้นของ server และทำให้เกิดข้อผิดพลาด Hostname/IP does not match certificate's altnames
  2. ห้ามเลือก Ignore TLS/SSL Error สำหรับ monitor ที่ต้องการรับการแจ้งเตือนวันหมดอายุ ฟังก์ชันนี้ใช้สำหรับ host ภายในที่ใช้ self-signed certificate (unable to verify the first certificate, DEPTH_ZERO_SELF_SIGNED_CERT) แต่จะทำให้ Uptime Kuma หยุดตรวจสอบ certificate ทั้งหมด รวมถึงการตรวจสอบวันหมดอายุด้วย

Backups: it is one directory

เนื่องจากข้อมูลทั้งหมดถูกเก็บไว้ใน /app/data การสำรองข้อมูลจึงเป็นการคัดลอก volume ดังกล่าวในขณะที่ container หยุดทำงาน เพื่อให้ไฟล์ SQLite มีความถูกต้องสมบูรณ์:

cd /srv/uptime-kuma
sudo docker compose stop
sudo docker run --rm \
  -v uptime-kuma_kuma-data:/data \
  -v /var/backups/kuma:/backup \
  alpine tar czf /backup/kuma-$(date -u +%Y%m%dT%H%M%SZ).tgz -C /data .
sudo docker compose start

ตรวจสอบชื่อจริงของ volume ด้วยคำสั่ง docker volume ls | grep kuma ก่อน เนื่องจาก Compose จะเติมชื่อ project directory ไว้ข้างหน้า จากนั้นให้คัดลอกไฟล์ tarball ออกจากเครื่อง VPS เพราะการสำรองข้อมูลไว้ใน VPS เครื่องเดิมถือเป็นเพียงการคัดลอก ไม่ใช่การสำรองข้อมูล การคืนค่า (Restore) ทำได้โดยทำย้อนกลับ: หยุดการทำงานของ stack, แตกไฟล์ลงใน volume /app/data ที่ว่างอยู่, แล้วจึงเริ่มการทำงานใหม่

Upgrades

การอัปเกรดคือการดึง image ใหม่:

cd /srv/uptime-kuma
sudo docker compose pull
sudo docker compose up -d

Container ตัวใหม่จะรัน database migration เมื่อเริ่มทำงานครั้งแรก ให้ตรวจสอบ docker compose logs -f ควรทำการสำรองข้อมูลตามขั้นตอนด้านบน ก่อน เริ่มการ pull และควรใช้งานภายใน major tag เดียวกัน การเปลี่ยนจาก :1 ไปยัง :2 เป็นการ migration แบบทางเดียว ดังนั้นควรสำรองข้อมูลก่อนและตรวจสอบ release notes ให้ถี่ถ้วน

Failure modes, with the strings you will see

สถานะ "down" ปลอมเมื่อ monitor ชี้ไปที่ localhost. หน้าจอแสดงสีแดงพร้อมข้อความ timeout of 48000ms exceeded หรือ connect ETIMEDOUT ทั้งที่ service ยังตอบสนองจาก laptop ของคุณ หาก monitor ชี้ไปยัง host เดียวกับที่ Uptime Kuma ทำงานอยู่ สาเหตุเกิดจาก CPU หรือ memory ทำงานหนักจนทำให้การตรวจสอบล้มเหลว ไม่ใช่เกิดจาก target ให้เปลี่ยนไปใช้ VPS แยกต่างหากและ monitor ผ่าน public hostname แทน

connect ECONNREFUSED 127.0.0.1:443 (หรือ port ใดก็ตาม) ไม่มี service รอรับการเชื่อมต่อบน port นั้น สาเหตุคือ service หยุดทำงาน หรือคุณกำลัง monitor localhost จากภายใน container ซึ่ง 127.0.0.1 คือ container ไม่ใช่ server ของคุณ ให้เปลี่ยนไป monitor ผ่าน public hostname แทนการใช้ loopback

Invalid login: 535-5.7.8 Username and Password not accepted ในการทดสอบ email ข้อมูลรับรอง SMTP ไม่ถูกต้อง หรือผู้ให้บริการต้องการ app-specific password แต่คุณใช้ password ของบัญชี ให้สร้าง app password แล้วนำมาใช้งานแทน

connect ETIMEDOUT หรือ queryA ETIMEDOUT <host> ในการทดสอบ email ใช้ port ไม่ถูกต้อง หรือผู้ให้บริการบล็อกการส่ง SMTP ออกไปภายนอก ตรวจสอบว่า 465 หรือ 587 ตรงกับการตั้งค่า Secure/STARTTLS หรือไม่ และทดสอบจาก host ด้วย nc -vz smtp.example.com 587 ผู้ให้บริการหลายรายบล็อกการส่ง 25 ออกไป และบางรายบล็อก submission ports จนกว่าจะมีการแจ้งขออนุญาต

self signed certificate หรือ unable to verify the first certificate ในการทดสอบ email SMTP server ใช้ certificate ที่ Node ไม่เชื่อถือ ให้แก้ไข certificate ของ mail server แทนการข้ามการตรวจสอบ

Dashboard ค้างที่ "Connecting..." และ console แสดง WebSocket connection ... failed reverse proxy ไม่ได้ทำการ upgrade WebSocket ให้เพิ่ม header Upgrade และ Connection "upgrade" ใน nginx หรือใช้ proxy ที่ส่งต่อ header เหล่านี้โดยค่าเริ่มต้น เช่น Traefik หรือ Caddy ทั้งนี้ HTML สามารถโหลดได้เพราะเป็น HTTP GET ปกติ แต่เฉพาะ live socket เท่านั้นที่ต้องการการ upgrade

Monitor การหมดอายุของ cert ไม่แจ้งเตือน หรือแจ้งเตือนผิดพลาด อาจเป็นเพราะมีการเลือก Ignore TLS/SSL Error ซึ่งเป็นการปิดการตรวจสอบ cert หรือ monitor ชี้ไปที่ IP ทำให้ไม่สามารถอ่าน certificate ที่ถูกต้องผ่าน SNI ได้ และแสดงผลเป็น Hostname/IP does not match certificate's altnames ให้ยกเลิกการเลือก ignore และเปลี่ยนมา monitor ด้วย hostname

SQLITE_BUSY หรือ database disk image is malformed ใน logs volume ของ /app/data อยู่บน filesystem ที่ไม่มีระบบ file locking ที่เหมาะสม (มักเป็น NFS) ให้ย้ายไปไว้บน local Docker volume และทำการ restore จาก backup แทน

FAQ

ควรติดตั้ง uptime monitor ไว้ที่ใด?

ควรติดตั้งไว้บนเซิร์ฟเวอร์คนละเครื่องกับเซิร์ฟเวอร์ที่ต้องการตรวจสอบ โดยควรอยู่คนละผู้ให้บริการหรือคนละภูมิภาคกัน และควรเข้าถึงผ่าน hostname บน public internet เช่นเดียวกับที่ผู้ใช้งานทั่วไปเข้าถึง หากติดตั้ง monitor ไว้บนเครื่องเดียวกับเป้าหมาย เมื่อเซิร์ฟเวอร์หลักล่ม monitor จะล่มตามไปด้วย และหาก host ทำงานหนักเกินไปอาจทำให้เกิดการแจ้งเตือนผิดพลาด (false positive) ว่าบริการหยุดทำงาน ทั้งที่จริงยังใช้งานได้ปกติ การใช้ VPS ขนาดเล็กแยกต่างหากจะช่วยป้องกันปัญหาทั้งสองนี้

จะรับการแจ้งเตือนผ่าน Telegram หรือ email ได้อย่างไร?

ไปที่เมนู Settings แล้วเลือก Notifications เพื่อเพิ่มช่องทางการแจ้งเตือน จากนั้นจึงนำไปเชื่อมต่อกับ monitor แต่ละตัว สำหรับ Telegram ให้สร้าง bot ด้วย @BotFather และอ่าน chat.id จาก https://api.telegram.org/bot<token>/getUpdates สำหรับ email ให้ใช้ 465 สำหรับ SSL หรือ 587 สำหรับ STARTTLS พร้อมกับ app password หากผู้ให้บริการของคุณใช้การยืนยันตัวตนแบบ two-factor auth ให้กดปุ่ม Test เพื่อตรวจสอบว่าข้อความส่งมาถึงจริงก่อนเริ่มใช้งานจริง

Uptime Kuma สามารถตรวจสอบ cron job หรือ backup script ได้หรือไม่?

สามารถทำได้โดยใช้ monitor ประเภท Push โดย Uptime Kuma จะให้ URL มาหนึ่งชุด และคุณต้องใช้คำสั่ง curl เมื่อสคริปต์ทำงานเสร็จสิ้น เพื่อให้ระบบส่งสัญญาณเมื่อทำงานสำเร็จเท่านั้น หากงานล้มเหลวหรือเครื่องเซิร์ฟเวอร์ปิดอยู่ สัญญาณ heartbeat จะไม่ถูกส่งมา และระบบจะแจ้งเตือนหลังจากสิ้นสุดช่วงเวลาที่กำหนดไว้ วิธีนี้เป็นวิธีเดียวที่เชื่อถือได้ในการตรวจสอบว่างานที่ตั้งเวลาไว้ได้ทำงานจริงหรือไม่ เนื่องจากเครื่องมือตรวจสอบจากภายนอกไม่สามารถตรวจสอบการทำงานภายในสคริปต์ได้

Uptime Kuma กับ Zabbix ควรเลือกใช้ตัวไหน?

Uptime Kuma ตอบคำถามที่ว่า "บริการยังใช้งานได้หรือไม่เมื่อตรวจสอบจากภายนอก และมีการแจ้งเตือนหรือไม่" ได้ภายใน 10 นาที โดยใช้ทรัพยากรน้อยมาก และมีหน้า status page ให้ด้วย อย่างไรก็ตาม Uptime Kuma ไม่ได้เก็บข้อมูลเชิงลึก เช่น แนวโน้มการใช้งาน CPU, memory และ disk หรือการตั้งค่า threshold สำหรับอุปกรณ์จำนวนมาก หากต้องการฟีเจอร์เหล่านั้น a full Zabbix monitoring server จะเป็นเครื่องมือที่ใช้ agent และใช้ทรัพยากรมากกว่า ซึ่งหลายคนเลือกใช้งานทั้งสองระบบควบคู่กัน หากยังตัดสินใจไม่ได้ our roundup of what to self-host in 2026 จะช่วยให้คุณเห็นภาพรวมของการใช้งาน self-hosted ได้ดีขึ้น

#uptime-kuma#monitoring#docker#self-hosting#status-page