Giám sát VPS bằng Uptime Kuma bắt trigger CPU, băng thông qua Telegram (2026)

Tác giả: Trần Thảo 30 tháng 09, 2026

Dev hoặc Sysadmin nào cũng từng trải qua cảm giác này: Mở dashboard lên thấy mọi thứ vẫn hiển thị màu xanh an toàn, trạng thái website báo 200 OK, nhưng thực tế phía bên ngoài, người dùng đang phàn nàn vì API timeout liên tục, request bị kẹt cứng, hoặc worker không thể xử lý thêm job mới. Chuyện gì đang xảy ra? Server của bạn đang bị quá tải ngầm, mạng vẫn thông để phản hồi Ping, nhưng CPU đã đạt 100% hoặc băng thông bị bóp nghẹt.

Khi phải quản lý hàng chục node hoặc xử lý các hệ thống scale liên tục, việc nhận biết hệ thống ngừng hoạt động hoàn toàn là chưa đủ. Bạn cần biết khi nào máy chủ bắt đầu có dấu hiệu suy giảm hiệu suất trước khi nó thực sự mất kết nối. Để giải quyết triệt để tình trạng báo cáo ảo này, chúng ta cần can thiệp sâu hơn vào hệ điều hành.

Bài viết hôm nay sẽ đi sâu vào kỹ thuật giám sát VPS bằng Uptime Kuma ở một góc độ thực chiến: đo lường tài nguyên thực tế, thiết lập hệ thống cảnh báo chống nhiễu (anti-spam) và gửi thông báo trực tiếp về nhóm Telegram của team quản trị. Liệu hệ thống monitoring hiện tại của bạn đã thực sự cảnh báo đúng lúc chưa, hay vẫn đang báo động sau khi khách hàng đã phàn nàn?

Quá tải ngầm, Ác mộng của Sysadmin và giới hạn của giám sát Uptime cơ bản

Các công cụ giám sát thông thường mang lại cảm giác an tâm, nhưng đôi khi đó là một sự an tâm chưa trọn vẹn. Hệ thống mặc định của Uptime Kuma chủ yếu sử dụng các cơ chế kiểm tra chủ động từ bên ngoài (Active External Probes) như HTTP Request, TCP Port hay Ping (ICMP).

Những giao thức này chỉ đo đạc phản hồi ở lớp mạng và lớp ứng dụng bề mặt. Chúng không có đặc quyền truy cập sâu vào hệ điều hành (OS Privileges) nhằm đọc các tệp tin ảo trong phân vùng /proc của Linux. Do đó, Kuma mặc định không thể biết VPS của bạn đang tiêu thụ bao nhiêu RAM, CPU đang xử lý bao nhiêu tiến trình hay lưu lượng mạng thực tế ra vào card mạng là bao nhiêu.

Lấy một ví dụ thực tế: Ứng dụng Node.js của bạn dính vòng lặp vô hạn hoặc bị kẹt query database, dẫn đến tình trạng lỗi VPS 100% CPU. Lúc này, Nginx vẫn đang hoạt động, port 80/443 vẫn mở, phản hồi Ping vẫn dưới 10ms. Mặc dù bạn đã cài đặt Uptime Kuma chuẩn xác, bảng điều khiển vẫn báo 🟢 UP. Nhưng request của end-user gửi vào thì bị treo lơ lửng cho đến khi văng lỗi 502 Bad Gateway. Việc chỉ dựa vào check Uptime cơ bản sẽ khiến team DevOps luôn đi sau sự cố một bước.

Biểu đồ minh họa hiện tượng quá tải ngầm trên VPS khi HTTP status báo 200 OK nhưng CPU đã quá tải 100%.

Hiện tượng quá tải ngầm: Uptime Kuma check HTTP vẫn báo UP (xanh), nhưng thực tế CPU đã cạn kiệt, hệ thống không thể xử lý thêm request.

Kiến trúc Push Monitor: Lời giải cho bài toán giám sát tài nguyên chuyên sâu

Thay vì tìm cách mở cổng tường lửa để Uptime Kuma truy cập trực tiếp vào trong máy chủ lấy dữ liệu (phương pháp Pull), giới kỹ thuật ưa chuộng sử dụng mô hình đảo ngược: Push Monitor (Passive Monitoring).

Với kiến trúc này, máy chủ (VPS) cần theo dõi sẽ đóng vai trò chủ động. Nó tự đo đạc sức khỏe của chính mình và định kỳ báo cáo (gửi heartbeat) về hệ thống Kuma thông qua một đường dẫn URL định danh.

Phương pháp này mang lại các lợi ích bảo mật giá trị cho hạ tầng:

Không phơi bày cổng Inbound: Hầu hết các tường lửa (Firewall/UFW) đều cho phép kết nối đi ra (Outbound HTTP/HTTPS). Việc VPS chủ động gửi dữ liệu ra ngoài giúp bạn không cần mở bất kỳ cổng dịch vụ nào, loại bỏ rủi ro bị hacker rà soát cổng mạng (Port Scanning) hoặc lợi dụng lỗ hổng từ các Exporter mở public.
Vượt qua NAT dễ dàng: Dù VPS nằm sâu trong mạng nội bộ (Private Subnet) và không có IP Public tĩnh, nó vẫn giao tiếp mượt mà với server Kuma bên ngoài.
Phát hiện sự cố mất kết nối toàn diện: Nếu Kuma không nhận được heartbeat từ VPS, hệ thống sẽ biết chắc chắn rằng máy chủ hoặc đường truyền mạng đã gián đoạn hoàn toàn.

Sơ đồ kiến trúc Push Monitor giúp giám sát VPS an toàn không cần mở cổng tường lửa Inbound.

Kiến trúc Push Monitor: VPS chủ động đo đạc và đẩy dữ liệu (Heartbeat) ra ngoài, giúp hệ thống an toàn trước các rủi ro rà soát cổng mạng.

Các bước thiết lập hệ thống cảnh báo tự động về nhóm Telegram

Đưa cảnh báo về nhóm Telegram chung của team DevOps là phương pháp mang lại hiệu quả vận hành cao, tránh việc trôi email và giúp các thành viên dễ dàng thảo luận ngay dưới thông báo lỗi.

Bước 1: Tạo Telegram Bot và lấy Chat ID an toàn, chuẩn mực

Bạn mở ứng dụng Telegram, tìm tài khoản @BotFather, gõ lệnh /newbot, đặt tên hiển thị và nhận về một chuỗi Bot Token. Bước tiếp theo là lấy Chat ID của nhóm (Group Chat ID). Ở bước này, nhiều người thường gặp rắc rối với tính năng Privacy Mode của Telegram và tìm đến các Helper Bot bên thứ 3 hoặc mạo hiểm cấp quyền Admin cho Bot.

Lưu ý rằng, việc dùng bot lạ tiềm ẩn rủi ro lộ dữ liệu nội bộ. Bạn có thể lấy Chat ID một cách an toàn mà không cần cấp quyền Admin.

Quy trình lấy Chat ID chuẩn bảo mật:

Thêm Bot bạn vừa tạo vào nhóm Telegram của team.
Gửi một tin nhắn bất kỳ vào nhóm và nhớ tag tên Bot (ví dụ: Khởi tạo kênh cảnh báo hệ thống @ten_bot_cua_ban). Việc tag tên giúp tin nhắn vượt qua rào cản Privacy Mode một cách hợp lệ, báo cho hệ thống Telegram biết Bot cần đọc tin nhắn này.
Mở trình duyệt web, truy cập URL: https://api.telegram.org/bot<BOT_TOKEN>/getUpdates
Tìm trong kết quả trả về đoạn JSON chứa "chat":{"id": -100xxxxxxxxxx...}. Dãy số âm này chính là Chat ID của nhóm. Lưu nó lại để dùng cho bước sau.

Bước 2: Cấu hình Push Monitor và nghệ thuật thiết lập Retries

Truy cập trang quản trị Uptime Kuma, chọn Add New Monitor với Type là Push. Kuma sẽ cấp cho bạn một Push URL chứa token bảo mật. Tại đây, thiết lập Heartbeat Interval (khoảng thời gian gửi báo cáo, ví dụ 60 giây). Tiếp theo, chúng ta cần chú ý đến tham số Retries.

Hiểu đúng về Retries và Packet Loss:

Khi bạn sử dụng script đẩy chủ động trạng thái status=down thông qua Webhook, Kuma sẽ ghi nhận lỗi và bắn thông báo ngay lập tức theo kịch bản đo đạc tài nguyên. Tham số Retries ở đây đóng vai trò bảo vệ hệ thống khỏi các rủi ro vật lý hoặc lỗi mạng chớp nhoáng.

Trong môi trường mạng thực tế, hiện tượng rớt gói tin (packet loss) hoặc mạng chập chờn diễn ra thường xuyên. Kịch bản Bash trên VPS đã tự động lọc nhiễu CPU, nhưng Kuma vẫn cần lọc nhiễu mạng. Các quản trị viên hệ thống khuyên nên thiết lập Retries ở mức 2 hoặc 3.

Mức thiết lập này kết hợp cùng tần suất 60 giây sẽ giúp hệ thống hấp thụ các lỗi mạng tạm thời. Nghĩa là, Kuma sẽ chờ khoảng 3 lần rớt heartbeat liên tiếp (tương đương 3 phút mất kết nối hoàn toàn) trước khi phát ra tiếng còi báo động VPS Offline. Sự kết hợp này mang lại độ chuẩn xác cao, vừa báo CPU lỗi ngay lập tức, vừa tránh spam khi cáp quang bị lag vài giây.

Sơ đồ quy trình lọc nhiễu cảnh báo giả kết hợp giữa Bash script trên VPS và thông số Retries của Uptime Kuma.

Kịch bản lọc nhiễu: Kết hợp bộ đếm trên VPS và thông số Retries của Kuma để ngăn chặn tình trạng bão thông báo (Alert Fatigue).

Bước 3: Triển khai Script giám sát hệ thống (có chống báo động giả)

Để nắm toàn quyền kiểm soát logic cảnh báo và tối ưu tài nguyên máy chủ hiệu quả, việc sử dụng một Bash script thuần túy đọc trực tiếp /proc/stat là phương án được dân kỹ thuật ưa chuộng.

Trước khi viết script, hãy chạy lệnh ip -brief link hoặc ip a trên VPS để xem tên card mạng đang sử dụng. Trên các bản phân phối Linux hiện đại như Ubuntu 22.04 hay Debian 11, card mạng thường có định dạng tên là ens3, enp3s0 thay vì eth0 truyền thống.

Tạo tệp /opt/vps-monitor.sh trên VPS và dán kịch bản sau:

#!/bin/bash
# ==========================================
# Cấu hình ngưỡng cảnh báo
# ==========================================
INTERFACE="ens3" # Đổi tên card mạng tương ứng sau khi check ip a
CPU_THRESHOLD=80
PUSH_URL="https://kuma.yourdomain.com/api/push/YOUR_TOKEN"

# Sử dụng /opt thay vì /tmp để tránh bị reset biến đếm khi server reboot
STATE_FILE="/opt/kuma_cpu_count" 

# Hàm lấy dữ liệu thô từ hệ điều hành (Kernel)
get_metrics() {
  read -r _ user nice system idle iowait irq softirq steal _ < /proc/stat
  read -r rx_bytes tx_bytes < <(awk -v iface="${INTERFACE}:" '$1 == iface {print $2, $10}' /proc/net/dev)
  echo "$user $nice $system $idle $iowait $irq $softirq $steal $rx_bytes $tx_bytes"
}

# Lấy mẫu 1, chờ 1s, lấy mẫu 2 để tính Delta (độ chênh lệch)
read -r u1 n1 s1 i1 io1 irq1 sirq1 st1 rx1 tx1 <<< $(get_metrics)
sleep 1 
read -r u2 n2 s2 i2 io2 irq2 sirq2 st2 rx2 tx2 <<< $(get_metrics) # Tính toán tỷ lệ % CPU idle1=$((i1 + io1)); non_idle1=$((u1 + n1 + s1 + irq1 + sirq1 + st1)); total1=$((idle1 + non_idle1)) idle2=$((i2 + io2)); non_idle2=$((u2 + n2 + s2 + irq2 + sirq2 + st2)); total2=$((idle2 + non_idle2)) total_diff=$((total2 - total1)); idle_diff=$((idle2 - idle1)) cpu_usage=$(awk "BEGIN {printf \"%.0f\", (($total_diff - $idle_diff) * 100 / $total_diff)}") # Lọc nhiễu (Debounce): Đọc số lần vượt ngưỡng từ file trạng thái count=$(cat "$STATE_FILE" 2>/dev/null || echo 0)

if [ "$cpu_usage" -ge "$CPU_THRESHOLD" ]; then
  count=$((count + 1))
  echo "$count" > "$STATE_FILE"
  
  # Bắn báo lỗi DOWN nếu vượt ngưỡng 3 lần liên tiếp (~3 phút)
  if [ "$count" -ge 3 ]; then
      curl -s -o /dev/null -G "$PUSH_URL" \
          --data-urlencode "status=down" \
          --data-urlencode "msg=CẢNH BÁO: CPU đạt ${cpu_usage}% (Vượt ngưỡng ${CPU_THRESHOLD}%)" \
          --data-urlencode "ping=${cpu_usage}"
  else
      # Gửi status UP kèm text thông báo đang theo dõi để team biết tình hình
      curl -s -o /dev/null -G "$PUSH_URL" \
          --data-urlencode "status=up" \
          --data-urlencode "msg=Đang theo dõi CPU cao: ${cpu_usage}% (${count}/3)" \
          --data-urlencode "ping=${cpu_usage}"
  fi
else
  # Reset biến đếm về 0 khi CPU trở lại bình thường
  echo 0 > "$STATE_FILE"
  curl -s -o /dev/null -G "$PUSH_URL" \
      --data-urlencode "status=up" \
      --data-urlencode "msg=CPU Bình thường: ${cpu_usage}%" \
      --data-urlencode "ping=${cpu_usage}"
fi

Cấp quyền thực thi bằng lệnh sau:

chmod +x /opt/vps-monitor.sh

Và thiết lập Cron job (crontab -e) để kịch bản chạy định kỳ mỗi phút:

* * * * * /opt/vps-monitor.sh >/dev/null 2>&1

Thủ thuật ping=, điểm nhấn sáng tạo của hệ thống:

Trong câu lệnh curl phía trên, tham số ping=${cpu_usage} mang một ý nghĩa đặc biệt. Mặc định Uptime Kuma dùng tham số này để vẽ đường đồ thị độ trễ mạng (latency). Việc cố tình truyền giá trị % CPU vào đây sẽ đánh lừa giao diện, ép Kuma vẽ ra một đồ thị trực quan biểu diễn sự biến động của CPU theo thời gian thực. Bằng thủ thuật này, bạn đã mở khóa tính năng giám sát tài nguyên sinh động ngay trên một công cụ chuyên check Uptime, tiết kiệm tài nguyên cài đặt Grafana cho các dự án nhỏ.

Bước 4: Giải pháp mã nguồn mở thay thế (dành cho scale số lượng lớn)

Nếu bạn quản lý nhiều cụm server và không muốn copy/paste file Bash script thủ công, cộng đồng mã nguồn mở hiện nay cung cấp các dự án như uptime-kuma-server-health hoặc uptime-kuma-push.

Các repo này hoạt động dưới dạng agent nhẹ, viết bằng Python hoặc Go, cho phép cài đặt nhanh qua 1 dòng lệnh hoặc chạy qua Docker container. Chúng có khả năng tự động rà soát tên card mạng, phân tích RAM, tình trạng đầy ổ cứng (Disk full), hoặc sức khỏe của ZFS pool. Đây là lựa chọn phù hợp khi bạn cần triển khai giám sát VPS bằng Uptime Kuma đồng loạt trên 10-20 nodes bằng các công cụ Automation như Ansible.

Kinh nghiệm thực chiến và kiểm thử cảnh báo

Hệ thống cấu hình xong chỉ là một nửa chặng đường. Cách team DevOps vận hành và phản ứng với các cảnh báo (Alerts) mới quyết định chất lượng của hạ tầng.

Phân luồng để tránh Alert Fatigue (hội chứng bão thông báo)

Khi hệ thống liên tục reo lên vì những lỗi lặt vặt, các kỹ sư sẽ sinh ra tâm lý chai lỳ, bỏ qua cả những cảnh báo chí mạng. Đừng ném tất cả thông báo vào chung một nhóm chat. Nên chia ra:

Kênh Critical: Dành cho trạng thái DOWN (CPU tải nặng liên tục, máy chủ đứt kết nối). Kênh này luôn bật chuông để gọi Sysadmin xử lý sự cố lập tức.
Kênh Info / Warning: Dành cho cập nhật trạng thái hoạt động bình thường, hoặc lúc hệ thống tự phục hồi (Recovery). Kênh này nên thiết lập Mute mặc định, team chỉ tra cứu khi cần đối chiếu log.

Sơ đồ phân luồng thông báo giám sát hệ thống trên Telegram thành kênh Critical và Info.

Phân luồng kênh Telegram: Tách biệt thông báo lỗi nghiêm trọng và thông tin cập nhật trạng thái để tối ưu vận hành cho team DevOps.

Giả lập tải bằng stress-ng để kiểm tra luồng API

Đừng phó mặc hệ thống và hy vọng nó hoạt động khi sự cố xảy ra. Sau khi hoàn tất cài đặt, hãy chủ động ép tải VPS bằng công cụ stress-ng để kiểm chứng toàn bộ luồng bắn tin Telegram.

Chạy lệnh sau trên Terminal để giả lập đẩy 100% CPU:

stress-ng --cpu 0 --cpu-load 100 --timeout 180s

Tham số --timeout 180s (3 phút) giúp ngắt bài kiểm tra tự động, bảo vệ máy chủ khỏi tình trạng treo cứng nếu bạn mất kết nối SSH. Trong 3 phút này, hãy mở nhóm Telegram và theo dõi xem Bot có gửi tin nhắn cảnh báo chính xác với thông điệp CPU đạt 100% sau 3 lần đếm (debounce) hay không.

Tối ưu hóa Database SQLite của Uptime Kuma

Uptime Kuma mặc định lưu trữ dữ liệu lịch sử trong tệp SQLite. Khi bạn cấu hình Push Monitor chạy mỗi 60 giây, lượng dữ liệu sinh ra mỗi ngày khá lớn. Để tránh tình trạng file database phình to làm chậm chính dashboard giám sát, bạn nên truy cập phần Settings > Monitor History để giới hạn thời gian lưu trữ log xuống mức hợp lý (ví dụ: giữ log chi tiết trong 30 ngày). Điều này giúp Kuma hoạt động bền bỉ, tiêu tốn ít RAM và phản hồi giao diện mượt mà.

Nếu nhu cầu của doanh nghiệp đòi hỏi lưu trữ Metrics hệ thống (CPU, RAM, Bandwidth) kéo dài hàng năm để phục vụ phân tích (Data Analysis), bạn nên cân nhắc xây dựng hệ thống Dashboard giám sát VPS Linux với Prometheus và Grafana thay vì chỉ dùng Kuma.

Câu hỏi thường gặp (FAQ)

1. Tại sao không dùng cơ chế HTTP/Ping mặc định của Kuma để giám sát CPU VPS?

Vì HTTP/Ping chỉ kiểm tra phản hồi từ bên ngoài. Để lấy được thông số sâu bên trong hệ điều hành (CPU, RAM, Bandwidth), bạn phải dùng kiến trúc Push Monitor để VPS tự báo cáo dữ liệu.

2. Dùng Push Monitor có yêu cầu mở port tường lửa không?

Không. Hệ thống hoạt động theo cơ chế đẩy dữ liệu ra ngoài (Outbound traffic). Bạn không cần mở bất kỳ cổng Inbound nào, đảm bảo máy chủ an toàn trước các hành vi rà soát cổng mạng.

3. Hiện tượng Double-debounce (Lọc nhiễu kép) là gì?

Là lỗi cấu hình khi cả Script trên máy chủ và Kuma đều thiết lập bộ đếm thời gian chờ để lọc nhiễu. Hệ quả là thời gian phát hiện lỗi bị cộng dồn, khiến cảnh báo đến tay team DevOps bị chậm trễ.

4. Cách lấy Chat ID nhóm Telegram an toàn mà không cần cấp quyền Admin?

Thêm Bot vào nhóm, gửi một tin nhắn bất kỳ có tag @tên_bot của bạn để vượt qua Privacy Mode, sau đó truy cập API getUpdates trên trình duyệt để lấy dãy số Chat ID.

5. Nếu cần giám sát lượng lớn máy chủ, Kuma có đáp ứng nổi không?

Kuma phù hợp cho mô hình vừa và nhỏ. Khi scale lên hàng chục hoặc hàng trăm node, bạn nên tham khảo hướng dẫn cách xây dựng Dashboard giám sát VPS Linux với Prometheus và Grafana để xử lý dữ liệu chuỗi thời gian chuyên sâu.

Kết luận

Nâng cấp từ việc kiểm tra Ping thụ động sang kiểm soát tài nguyên sâu bên trong OS là một bước tiến quan trọng trong công tác quản trị hạ tầng. Kết hợp kiến trúc Push Monitor an toàn, một kịch bản Bash tinh gọn lưu trạng thái tại /opt/, sự linh hoạt của API Telegram, cùng mẹo vẽ biểu đồ qua tham số ping=, bạn đã nắm trong tay giải pháp giám sát VPS bằng Uptime Kuma mang đậm tính thực chiến.

Khi hệ thống biết tự động lọc nhiễu mạng qua thông số Retries, phát tín hiệu đúng lúc và gửi đến đúng kênh, team quản trị sẽ luôn ở thế chủ động. Cảnh báo sớm giúp kỹ sư có đủ thời gian phân bổ lại luồng request hoặc khởi tạo thêm worker trước khi hệ thống chạm ngưỡng ngừng hoạt động diện rộng. Chúc bạn triển khai giải pháp thành công và xây dựng được những cụm máy chủ hoạt động ổn định, bền bỉ!