Giám sát website uptime với Uptime Kuma: Hướng dẫn setup từ A đến Z

Table of Contents

Vấn đề thực tế khi quản lý uptime website

Năm ngoái, khi công ty mình chuyển sang microservices, tình hình trở nên phức tạp. Có lúc API của team A bị down nhưng team B không biết, khách hàng phàn nàn trước khi mình nhận được báo cáo. Lúc đó, tôi đã setup Nagios nhưng cách cấu hình thông qua XML khiến mọi người e dè tiếp cận. Sau một thời gian tìm hiểu, tôi phát hiện ra Uptime Kuma — công cụ monitoring uptime lightweight, giao diện web-based dễ dùng, không cần kiến thức DevOps cao.

Bài này mình muốn chia sẻ cách setup và sử dụng Uptime Kuma thực tế mà không phải đọc docs dài ngoằng.

Vì sao xảy ra tình trạng “không biết sự cố đang diễn ra”?

Khi chỉ dựa vào user báo cáo hoặc check thủ công, bạn luôn đi sau thực tế:

Time to detection chậm: User mất 5-10 phút để nhận ra situs chậm/down, rồi mới báo. Thực tế sự cố đã xảy ra trước đó lâu.
Không có insight về downtime pattern: Bạn không biết thằng nào down lúc 2 AM hay mỗi lần deploy.
Khó scale monitoring: Khi có 20-30 services, không thể check từng cái bằng tay.
Cảnh báo hỗn loạn: Nếu dùng tool phức tạp, cấu hình alert dễ nhầm lẫn, gây “alert fatigue”.

Các cách giải quyết và tại sao chọn Uptime Kuma

Trên thị trường có vài lựa chọn:

Nagios/Icinga: Mạnh nhưng hơi “cứng cổ”, cấu hình XML/text phức tạp.
Zabbix: Quá nặng cho monitoring uptime đơn giản, yêu cầu database lớn.
Datadog/New Relic: Expensive, overkill nếu chỉ cần check endpoint.
Uptime Kuma: Lightweight, open-source, giao diện modern, setup trong 10 phút, không cần database phức tạp.

Mình chọn Uptime Kuma vì nó vừa đủ tính năng: HTTP(s) monitoring, ping, TCP check, cảnh báo qua nhiều kênh (Slack, Discord, Email, Webhook). Quan trọng là team QA hay PM cũng dùng được ngay, không cần training dài.

Setup Uptime Kuma bước-bước

Bước 1: Chuẩn bị server

Uptime Kuma chạy on Node.js, cần server có ~500MB RAM, ổ cứng 1GB. Mình thường deploy nó trên một VPS riêng hoặc container trong cluster K8s.

Yêu cầu cơ bản:

Node.js 14+ hoặc Docker
Port 3001 (mặc định) available
Network có thể reach đến các endpoint cần monitor

Bước 2: Cài đặt Uptime Kuma

Option A – Cài trực tiếp với Node.js:

git clone https://github.com/louislam/uptime-kuma.git
cd uptime-kuma
npm run setup
npm run start

Option B – Sử dụng Docker (recommended):

docker run -d --restart always -p 3001:3001 -v uptime-kuma:/app/data --name uptime-kuma louislam/uptime-kuma:latest

Với Docker Compose để dễ quản lý:

version: '3.8'
services:
  uptime-kuma:
    image: louislam/uptime-kuma:latest
    container_name: uptime-kuma
    restart: always
    ports:
      - "3001:3001"
    volumes:
      - uptime-kuma:/app/data
    environment:
      - UPTIME_KUMA_PORT=3001
volumes:
  uptime-kuma:

Start service:

docker-compose up -d

Check logs nếu có issue:

docker logs -f uptime-kuma

Bước 3: Truy cập giao diện lần đầu

Mở browser, truy cập http://localhost:3001 hoặc http://your-server-ip:3001. Lần đầu tiên, bạn sẽ được yêu cầu set password admin.

Mình khuyến nghị dùng mật khẩu mạnh (16+ ký tự, mix số+chữ+symbol) vì đây là điểm truy cập quan trọng.

Bước 4: Cấu hình monitors (theo dõi services)

Sau khi login, click vào “+” hoặc “Add Monitor” để bắt đầu thêm các services cần theo dõi.

Ví dụ setup monitor cho website chính:

Name: “Production API – auth-service”
Type: HTTP(s)
URL: https://api.yourcompany.com/health
Method: GET
Interval: 60 (check mỗi 60 giây)
Timeout: 30 (chờ 30s, nếu không response là down)
Accepted Status Codes: 200 (endpoint trả 200 là okay)

Lưu ý: Nếu endpoint chuyên đọc database nặng, dùng lightweight health endpoint (ví dụ /ping chỉ trả status, không query full database).

Thêm monitor TCP để check database:

Name: “PostgreSQL Main DB”
Type: TCP
Hostname: db.internal.company.com
Port: 5432
Interval: 120 (check 2 phút 1 lần đủ rồi)

Bước 5: Setup cảnh báo (Notifications)

Đây là phần quan trọng nhất. Mình setup cảnh báo qua nhiều kênh:

Cảnh báo qua Slack:

Vào Settings → Notifications → Add Notification
Chọn type “Slack”
Lấy Webhook URL từ Slack (Apps → Incoming Webhooks → Create New)
Paste URL vào, test bằng nút “Send Test”
Gán notification này cho các monitors muốn nhận Slack alert

Cảnh báo qua Email:

Settings → Notifications → Add Notification
Chọn type “Email”
Config SMTP (Gmail, SendGrid, hay email server nội bộ):

SMTP Host: smtp.gmail.com
SMTP Port: 587
Use TLS: Yes
Username: [email protected]
Password: your-app-password (không phải password Gmail thường)
From Address: [email protected]

Cảnh báo qua Discord:

Tạo webhook trong Discord channel (Settings → Integrations → Webhooks)
Copy webhook URL
Vào Uptime Kuma → Notifications → Add → Discord → paste URL

Bước 6: Tùy chỉnh status page công khai

Mình thường setup status page để customers có thể xem real-time uptime:

Settings → Status Page → Create
Chọn monitors muốn hiển thị công khai
Copy public URL, share với customers

Ví dụ: https://status.yourcompany.com sẽ hiển thị uptime của tất cả critical services.

Best practices từ kinh nghiệm thực tế

Interval check hợp lý

Không phải service nào cũng cần check mỗi 10 giây:

Critical services (API, database): 30-60 giây
Internal tools, admin panel: 5-10 phút
Batch jobs chạy 1 lần/ngày: Dùng webhook trigger từ job scheduler, không cần poll

Check quá thường sẽ gây noise, quá hiếm sẽ miss downtime. Tôi thường bắt đầu với 60s, sau đó adjust dựa vào SLA yêu cầu.

Health endpoint nên trả về gì

Thay vì check homepage hoặc endpoint bất kỳ, hãy tạo dedicated /health endpoint:

@app.get("/health")
def health_check():
    return {
        "status": "healthy",
        "timestamp": datetime.utcnow().isoformat(),
        "uptime_seconds": time.time() - start_time
    }

Endpoint này nên:

Không có database query (nếu possible)
Trả response trong <1 second
Là read-only (không log vào database)

Alert fatigue prevention

Nếu cảnh báo quá nhiều, team sẽ ignore hết. Mình áp dụng rule:

Chỉ cảnh báo service DOWN hoặc UP (transition).
Bỏ cảnh báo “service slow” (ngưỡng response time) nếu service vẫn trả 200 OK.
Dùng “Group” alerts nếu nhiều services down cùng lúc (dấu hiệu network issue chứ không phải service bug).

Backup cấu hình

Uptime Kuma lưu config vào /app/data. Nếu sử dụng Docker, hãy backup volume này:

docker exec uptime-kuma tar czf /tmp/backup.tar.gz /app/data
docker cp uptime-kuma:/tmp/backup.tar.gz ./uptime-kuma-backup.tar.gz

Hoặc setup automated backup với cron job.

Reverse proxy setup (production)

Không expose Uptime Kuma trực tiếp trên internet. Mình dùng Nginx reverse proxy + SSL:

server {
    listen 443 ssl http2;
    server_name uptime.yourcompany.com;
    
    ssl_certificate /etc/letsencrypt/live/uptime.yourcompany.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/uptime.yourcompany.com/privkey.pem;
    
    location / {
        proxy_pass http://localhost: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;
    }
}

Kết quả sau khi áp dụng

Sau 3 tháng setup Uptime Kuma, team mình:

Phát hiện downtime trung bình trong <2 phút (trước đó là 10-15 phút).
Giảm customer complaints từ 5-6 complaints/tuần xuống còn <1.
Tôi có thời gian ngủ ngon vì không cần check email liên tục, chỉ cần nhìn dashboard hoặc nhận Slack alert.
Có data để chứng minh uptime với customers, tăng trust.

Thực ra Uptime Kuma không phải silver bullet. Bạn vẫn cần application monitoring (Prometheus + Grafana để track CPU, memory, request latency) chi tiết. Nhưng để bắt đầu, nó là cách nhanh nhất và hiệu quả nhất.

Share on Facebook

Post on X