Uptime Kuma คืออะไร
Uptime Kuma เป็น open source self-hosted monitoring tool สำหรับตรวจสอบสถานะของ websites, APIs, databases และ services ต่างๆ พัฒนาด้วย Node.js มี web UI ที่สวยงามและใช้งานง่าย รองรับ notification หลายช่องทาง เช่น LINE, Telegram, Discord, Slack, Email
จุดเด่นของ Uptime Kuma ได้แก่ Self-hosted ข้อมูลอยู่ในเครื่องของตัวเอง ไม่ต้องพึ่ง third-party, UI สวยงาม responsive ดูได้ทุกอุปกรณ์, รองรับ monitors หลายประเภท HTTP(s), TCP, Ping, DNS, Docker, Push, Steam Game Server, 90+ notification services, Status pages สร้างหน้าแสดงสถานะสำหรับผู้ใช้, Maintenance windows กำหนดเวลา maintenance ไม่แจ้งเตือน
Real-Time Processing สำหรับ monitoring หมายถึงการประมวลผล monitoring data แบบ real-time เพื่อ detect anomalies, trigger alerts และ automate responses ทันทีเมื่อเกิดปัญหา ไม่ต้องรอ batch processing
ติดตั้ง Uptime Kuma
Setup Uptime Kuma
# === Uptime Kuma Installation ===
# 1. Docker Installation (Recommended)
docker run -d \
--name uptime-kuma \
--restart=always \
-p 3001:3001 \
-v uptime-kuma:/app/data \
louislam/uptime-kuma:1
# 2. Docker Compose
cat > docker-compose.yml << 'EOF'
version: '3.8'
services:
uptime-kuma:
image: louislam/uptime-kuma:1
container_name: uptime-kuma
restart: always
ports:
- "3001:3001"
volumes:
- uptime-kuma-data:/app/data
- /var/run/docker.sock:/var/run/docker.sock:ro
environment:
- TZ=Asia/Bangkok
volumes:
uptime-kuma-data:
EOF
docker-compose up -d
# 3. Access Web UI
# URL: http://your-server:3001
# Create admin account on first visit
# 4. Nginx Reverse Proxy with SSL
cat > /etc/nginx/sites-available/uptime-kuma << 'NGINX'
server {
listen 443 ssl http2;
server_name status.example.com;
ssl_certificate /etc/letsencrypt/live/status.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/status.example.com/privkey.pem;
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;
}
}
server {
listen 80;
server_name status.example.com;
return 301 https://$server_name$request_uri;
}
NGINX
sudo ln -s /etc/nginx/sites-available/uptime-kuma /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx
# 5. Node.js Installation (Alternative)
# ===================================
# git clone https://github.com/louislam/uptime-kuma.git
# cd uptime-kuma
# npm run setup
# npm run start-server
# Or use PM2:
# pm2 start server/server.js --name uptime-kuma
echo "Uptime Kuma installed"ตั้งค่า Monitors และ Notifications
Configure monitors และ alerts
# === Monitor Configuration ===
# 1. HTTP(s) Monitor
# ===================================
# Settings > Add New Monitor
# Monitor Type: HTTP(s)
# Friendly Name: Production Website
# URL: https://example.com
# Heartbeat Interval: 60 seconds
# Retries: 3
# Heartbeat Retry Interval: 20 seconds
# Request Timeout: 30 seconds
# HTTP Method: GET
# Accepted Status Codes: 200-299
# Max Redirects: 10
#
# Advanced:
# - Enable certificate expiry notification (30 days)
# - Enable keyword monitoring (check for specific text)
# - Custom headers if needed (Authorization, etc.)
# 2. API Health Check
# ===================================
# Monitor Type: HTTP(s) - Keyword
# URL: https://api.example.com/health
# Keyword: "status":"ok"
# Method: GET
# Expected Status: 200
# Interval: 30 seconds
# 3. TCP Port Monitor
# ===================================
# Monitor Type: TCP Port
# Hostname: db.example.com
# Port: 3306 (MySQL)
# Interval: 60 seconds
# 4. Docker Container Monitor
# ===================================
# Monitor Type: Docker Container
# Container Name: nginx
# Docker Host: /var/run/docker.sock
# Interval: 30 seconds
# 5. DNS Monitor
# ===================================
# Monitor Type: DNS
# Hostname: example.com
# DNS Server: 8.8.8.8
# Expected Type: A
# Expected Value: 1.2.3.4
# 6. Notification Setup
# ===================================
# LINE Notify:
# Type: LINE Notify
# Token: (get from https://notify-bot.line.me/)
#
# Telegram:
# Type: Telegram
# Bot Token: (from @BotFather)
# Chat ID: (your chat/group ID)
#
# Discord:
# Type: Discord
# Webhook URL: (from Discord channel settings)
#
# Slack:
# Type: Slack
# Webhook URL: (from Slack app settings)
#
# Email (SMTP):
# Type: SMTP
# Hostname: smtp.gmail.com
# Port: 587
# Security: STARTTLS
# Username: your@gmail.com
# Password: app-specific-password
echo "Monitors configured"Real-Time Processing Pipeline
สร้าง real-time monitoring pipeline
#!/usr/bin/env python3
# realtime_monitor.py — Real-Time Monitoring Pipeline
import json
import logging
from datetime import datetime, timedelta
from typing import Dict, List
logging.basicConfig(level=logging.INFO)
logger = logging.getLogger("realtime")
class RealTimeMonitorPipeline:
def __init__(self):
self.monitors = {}
self.alerts = []
self.metrics_buffer = []
def ingest_heartbeat(self, monitor_id, data):
"""Process incoming heartbeat data in real-time"""
processed = {
"monitor_id": monitor_id,
"timestamp": datetime.utcnow().isoformat(),
"status": data.get("status"), # up/down/pending
"response_time_ms": data.get("response_time"),
"status_code": data.get("status_code"),
"message": data.get("message", ""),
}
self.metrics_buffer.append(processed)
# Check for anomalies
anomalies = self._detect_anomalies(monitor_id, processed)
if anomalies:
self._trigger_alert(monitor_id, anomalies)
return processed
def _detect_anomalies(self, monitor_id, current):
"""Real-time anomaly detection"""
anomalies = []
# Rule 1: Service down
if current["status"] == "down":
anomalies.append({
"type": "service_down",
"severity": "critical",
"message": f"Monitor {monitor_id} is DOWN: {current['message']}",
})
# Rule 2: High response time
if current["response_time_ms"] and current["response_time_ms"] > 5000:
anomalies.append({
"type": "high_latency",
"severity": "warning",
"message": f"Response time {current['response_time_ms']}ms exceeds threshold",
})
# Rule 3: Non-200 status code
if current["status_code"] and current["status_code"] >= 500:
anomalies.append({
"type": "server_error",
"severity": "high",
"message": f"HTTP {current['status_code']} error",
})
# Rule 4: Response time trend (increasing)
recent = [m for m in self.metrics_buffer[-10:] if m["monitor_id"] == monitor_id]
if len(recent) >= 5:
times = [m["response_time_ms"] for m in recent if m["response_time_ms"]]
if len(times) >= 5 and all(times[i] < times[i+1] for i in range(len(times)-1)):
anomalies.append({
"type": "degrading_performance",
"severity": "warning",
"message": "Response time consistently increasing",
})
return anomalies
def _trigger_alert(self, monitor_id, anomalies):
"""Trigger alerts for detected anomalies"""
for anomaly in anomalies:
alert = {
"monitor_id": monitor_id,
"timestamp": datetime.utcnow().isoformat(),
**anomaly,
}
self.alerts.append(alert)
logger.warning(f"ALERT: {alert['severity']} - {alert['message']}")
def get_dashboard(self):
"""Get real-time dashboard data"""
total = len(self.metrics_buffer)
up_count = sum(1 for m in self.metrics_buffer if m["status"] == "up")
return {
"total_heartbeats": total,
"uptime_pct": round(up_count / max(total, 1) * 100, 2),
"active_alerts": len([a for a in self.alerts if a["severity"] == "critical"]),
"avg_response_ms": round(
sum(m["response_time_ms"] for m in self.metrics_buffer if m["response_time_ms"]) /
max(sum(1 for m in self.metrics_buffer if m["response_time_ms"]), 1), 0
),
}
pipeline = RealTimeMonitorPipeline()
# Simulate heartbeats
pipeline.ingest_heartbeat("web-prod", {"status": "up", "response_time": 150, "status_code": 200})
pipeline.ingest_heartbeat("web-prod", {"status": "up", "response_time": 180, "status_code": 200})
pipeline.ingest_heartbeat("api-prod", {"status": "down", "response_time": None, "status_code": 503, "message": "Connection refused"})
pipeline.ingest_heartbeat("web-prod", {"status": "up", "response_time": 6000, "status_code": 200})
dashboard = pipeline.get_dashboard()
print("Dashboard:", json.dumps(dashboard, indent=2))
print("Alerts:", json.dumps(pipeline.alerts, indent=2))Advanced Monitoring Strategies
กลยุทธ์ monitoring ขั้นสูง
# === Advanced Monitoring ===
# 1. Multi-Location Monitoring
# ===================================
# Deploy Uptime Kuma at multiple locations:
# - Bangkok (primary)
# - Singapore
# - Tokyo
# - US West
#
# Compare results:
# - If DOWN from all locations → actual outage
# - If DOWN from 1 location → network issue at that location
# - Monitor from user's perspective (different ISPs)
# 2. Synthetic Monitoring
# ===================================
# Simulate real user workflows:
# Step 1: GET /login → expect 200
# Step 2: POST /api/auth → expect 200 + token
# Step 3: GET /api/dashboard → expect 200 + data
# Step 4: POST /api/logout → expect 200
#
# Use HTTP(s) monitors with chained checks
# Or use Push monitors with custom scripts
# 3. Status Page Configuration
# ===================================
# Uptime Kuma > Status Pages > Add
# Title: "Service Status"
# Slug: "status"
# Theme: Auto
# Published: Yes
#
# Groups:
# - Core Services: Website, API, Database
# - Infrastructure: CDN, DNS, Email
# - Third-party: Payment Gateway, SMS
#
# Custom domain: status.example.com
# Show history: 90 days
# 4. Maintenance Windows
# ===================================
# Settings > Maintenance > Add
# Title: "Database Maintenance"
# Strategy: Manual / Recurring
# Recurring: Every Sunday 02:00-04:00
# Affected monitors: db-primary, db-replica
# Status page message: "Scheduled database maintenance"
# 5. Monitor Groups
# ===================================
# Organize monitors by:
# - Environment: Production, Staging, Development
# - Type: Frontend, Backend, Database, Infrastructure
# - Priority: Critical, High, Medium, Low
# - Team: DevOps, Backend, Frontend
# 6. Response Time Thresholds
# ===================================
# Web pages: < 2 seconds (warning), < 5 seconds (critical)
# APIs: < 500ms (warning), < 2 seconds (critical)
# Database: < 100ms (warning), < 500ms (critical)
# DNS: < 50ms (warning), < 200ms (critical)
echo "Advanced monitoring configured"Integration และ Automation
Integrate Uptime Kuma กับ tools อื่น
#!/usr/bin/env python3
# kuma_integration.py — Uptime Kuma Integrations
import json
import logging
from datetime import datetime
from typing import Dict, List
logging.basicConfig(level=logging.INFO)
logger = logging.getLogger("integration")
class KumaIntegration:
def __init__(self, kuma_url, api_key=None):
self.kuma_url = kuma_url
self.api_key = api_key
def webhook_handler(self, payload):
"""Handle Uptime Kuma webhook notifications"""
event_type = payload.get("type", "unknown")
monitor = payload.get("monitor", {})
heartbeat = payload.get("heartbeat", {})
result = {
"event": event_type,
"monitor_name": monitor.get("name"),
"monitor_url": monitor.get("url"),
"status": heartbeat.get("status"),
"response_time": heartbeat.get("ping"),
"message": heartbeat.get("msg"),
"timestamp": datetime.utcnow().isoformat(),
}
# Route to appropriate handler
if event_type == "down":
self._handle_down(result)
elif event_type == "up":
self._handle_recovery(result)
return result
def _handle_down(self, event):
"""Handle service down event"""
actions = [
f"Send PagerDuty alert for {event['monitor_name']}",
f"Create Jira incident ticket",
f"Post to #incidents Slack channel",
f"Start auto-remediation runbook",
]
logger.critical(f"SERVICE DOWN: {event['monitor_name']}")
return {"actions_taken": actions}
def _handle_recovery(self, event):
"""Handle service recovery"""
actions = [
f"Resolve PagerDuty alert for {event['monitor_name']}",
f"Update Jira ticket to resolved",
f"Post recovery to #incidents Slack channel",
]
logger.info(f"SERVICE RECOVERED: {event['monitor_name']}")
return {"actions_taken": actions}
def auto_remediation(self, monitor_name, issue_type):
"""Automated remediation based on issue type"""
playbooks = {
"high_memory": [
"Clear application cache",
"Restart PHP-FPM",
"If still high, restart application",
],
"disk_full": [
"Clear log files older than 7 days",
"Remove temp files",
"Compress old logs",
],
"service_down": [
"Check if service process is running",
"Attempt service restart",
"If failed, check dependencies",
"Escalate to on-call engineer",
],
"ssl_expiring": [
"Run certbot renew",
"Verify new certificate",
"Reload Nginx",
],
}
return {
"monitor": monitor_name,
"issue": issue_type,
"playbook": playbooks.get(issue_type, ["Escalate to on-call"]),
"auto_executed": issue_type in ["high_memory", "ssl_expiring"],
}
integration = KumaIntegration("http://localhost:3001")
# Simulate webhook
down_event = integration.webhook_handler({
"type": "down",
"monitor": {"name": "Production API", "url": "https://api.example.com"},
"heartbeat": {"status": 0, "ping": None, "msg": "Connection timeout"},
})
print("Down Event:", json.dumps(down_event, indent=2))
# Auto-remediation
remedy = integration.auto_remediation("Production API", "service_down")
print("\nRemediation:", json.dumps(remedy, indent=2))FAQ คำถามที่พบบ่อย
Q: Uptime Kuma กับ UptimeRobot ต่างกันอย่างไร?
A: Uptime Kuma เป็น self-hosted ข้อมูลอยู่ใน server ตัวเอง ฟรีไม่จำกัด monitors, notifications ไม่ต้องจ่ายค่า subscription ต้อง maintain server เอง UptimeRobot เป็น SaaS ไม่ต้อง manage infrastructure free plan มี 50 monitors interval 5 นาที paid plan $7/mo ขึ้นไป ได้ 1 นาที interval multi-location monitoring สำหรับทีมเล็กที่มี technical skill แนะนำ Uptime Kuma (ประหยัดค่าใช้จ่าย) สำหรับทีมที่ไม่อยาก maintain server ใช้ UptimeRobot หรือ Better Uptime
Q: Uptime Kuma ใช้ resources เท่าไหร?
A: Uptime Kuma ใช้ resources น้อยมาก RAM ประมาณ 100-300MB ขึ้นกับจำนวน monitors CPU น้อยมาก (< 5%) สำหรับ 50-100 monitors Disk ขึ้นกับ retention period (default 180 days) ประมาณ 500MB-2GB VPS เล็กๆ 1 vCPU, 1GB RAM เพียงพอสำหรับ 100+ monitors รัน Docker container เดียวได้เลย ไม่ต้องมี database ภายนอก (ใช้ SQLite built-in)
Q: Monitor interval ควรตั้งเท่าไหร?
A: ขึ้นกับ criticality ของ service Critical services (payment, auth) ตั้ง 30 วินาที, Important services (API, website) ตั้ง 60 วินาที, Normal services (internal tools) ตั้ง 5 นาที, Low priority (dev, staging) ตั้ง 10-15 นาที interval สั้นเกินไปอาจ create load บน target service และสิ้นเปลือง resources ยาวเกินไปอาจ detect outage ช้า สำหรับ production website แนะนำ 60 วินาทีเป็น default
Q: จะ monitor อะไรบ้างสำหรับ production?
A: Must-have Website/landing page (HTTP 200), API endpoints สำคัญ (health check), Database connectivity (TCP port), SSL certificate expiry, DNS resolution Nice-to-have Response time trends, Third-party services (payment, email), CDN status, Background job processing, Disk space และ server resources (ใช้ Push monitor + script) เริ่มจาก monitor สิ่งที่ user-facing ก่อน แล้วค่อยเพิ่ม infrastructure monitors ตั้ง notification ให้แจ้ง LINE หรือ Telegram สำหรับ critical alerts
