Cảnh báo bằng cuộc gọi cho Uptime Kuma: Làm điện thoại bạn đổ chuông

Mục lục

• Vì sao Uptime Kuma không tự gọi điện cho bạn được
• Bạn cần những gì
• Bước 1 — Tạo một kênh biết gọi cho bạn
• Bước 2 — Thêm Echobell như một thông báo webhook
• Bước 3 — Gửi một payload mà bạn lọc được
• Bước 4 — Đừng để cảnh báo hồi phục gọi cho bạn
• Bước 5 — Tinh chỉnh monitor để nó đừng báo động giả
• Chỉ đổ chuông ngoài giờ làm việc
• Chia sẻ cảnh báo với cả nhóm
• Thiết lập này không mang lại điều gì
• Xử lý sự cố
• Câu hỏi thường gặp
• Uptime Kuma có tự gọi điện được không?
• Cách này có chạy với Uptime Kuma tự host sau tường lửa không?
• Cuộc gọi có vượt qua chế độ Không làm phiền không?
• Làm sao để không bị gọi khi dịch vụ hồi phục?
• Nhiều người có thể cùng được gọi cho một monitor không?
• Tổng kết
• Bài liên quan

Uptime Kuma hỗ trợ hơn 90 kênh thông báo, nhưng không cái nào làm điện thoại bạn reo. Để nhận một cuộc gọi khi một monitor báo sập, hãy gửi thông báo Webhook của Uptime Kuma tới một kênh Echobell đặt ở chế độ Cuộc gọi. Bài này trình bày chính xác phần thân tùy chỉnh cần dùng, cách tách cảnh báo sập khỏi cảnh báo hồi phục, và hai lỗi âm thầm phá hỏng cả thiết lập.

Uptime Kuma là công cụ giám sát uptime tự host phổ biến nhất hiện nay — khoảng 90.000 sao trên GitHub, với bản 2.5.0 ra mắt vào tháng 8/2026. Nó kiểm tra endpoint HTTP, cổng TCP, bản ghi DNS, container Docker và nhiều thứ khác, và nó phát hiện sự cố thực sự xuất sắc.

Chỗ nó để bạn hở sườn là chặng cuối: đưa cảnh báo tới một con người đang ngủ.

Vì sao Uptime Kuma không tự gọi điện cho bạn được

Danh sách thông báo của Uptime Kuma rất dài — Telegram, Discord, Slack, email, Gotify, ntfy và hàng chục cái khác — nhưng tất cả đều chuyển đi một tin nhắn. Mà tin nhắn thì lệ thuộc vào công tắc chuông của điện thoại, chế độ Không làm phiền và các chế độ Tập trung của iOS. Lúc 3 giờ sáng, điều đó nghĩa là cảnh báo đến nơi mà chẳng có gì xảy ra cả.

Không có kênh "gọi vào điện thoại của tôi" chính chủ nào. Những lựa chọn người ta thường tìm tới là:

• Twilio — bạn có thể dựng cuộc gọi thoại trên nền nó, nhưng kênh Twilio của Uptime Kuma gửi SMS. Muốn gọi thoại thì phải viết một dịch vụ trung gian, mua một số điện thoại, và trả tiền theo từng cuộc gọi.
• PagerDuty, Zenduty, Spike.sh, Splunk On-Call — những dịch vụ này có gọi điện thật, và chúng là nền tảng quản lý sự cố đầy đủ với mức giá tính theo từng người dùng tương xứng. Đây là lựa chọn đúng nếu bạn cần lịch trực xoay vòng và chính sách leo thang; nhưng quá nặng nếu bạn chỉ cần một chiếc điện thoại reo lên.
• Cổng SMS — một tin SMS vẫn đến dưới dạng tin nhắn, và trên iOS thì tin nhắn không xuyên qua chế độ Tập trung trừ khi người gửi nằm trong danh sách cho phép của bạn.

Một đề xuất tính năng thông báo bằng cuộc gọi VoIP đã mở trên repo Uptime Kuma khá lâu. Trong lúc chờ, kênh Webhook tổng quát chính là lối thoát — nó gửi được bất cứ thứ gì tới bất cứ URL nào, và đó là tất cả những gì bạn cần.

Bạn cần những gì

• Một máy chủ Uptime Kuma đang chạy (bài này viết theo bản 2.x; phần thân webhook tùy chỉnh cũng chạy trên 1.23+)
• Đã cài Echobell (App Store / Google Play)
• Năm phút

Máy chủ Uptime Kuma của bạn cần kết nối HTTPS đi ra tới hook.echobell.one. Nó không cần truy cập được từ internet — đây là webhook đi ra, nên một monitor chạy trên máy chủ tại nhà hoặc trong mạng riêng vẫn hoạt động bình thường.

Bước 1 — Tạo một kênh biết gọi cho bạn

Trong Echobell, hãy tạo một kênh tên đại loại như Production Down. Đặt kiểu thông báo cho phần đăng ký của nó là Cuộc gọi. Đây chính là thiết lập quan trọng: cảnh báo dạng Cuộc gọi hiện lên như một cuộc gọi đến và reo xuyên qua chế độ Tập trung cùng Không làm phiền của iOS, thứ mà thông báo đẩy không làm được.

Hãy đặt mẫu như sau:

Title: 🔴 {{monitor}} is down
Body: {{message}}
Target: {{target}}

Rồi sao chép Webhook URL của kênh. Nó trông như thế này:

https://hook.echobell.one/t/<channel-token>

Hãy coi URL đó là bí mật — ai cầm được nó cũng làm điện thoại bạn reo.

Bước 2 — Thêm Echobell như một thông báo webhook

Trong Uptime Kuma, vào Settings → Notifications → Setup Notification và điền:

Để trống phần Additional Headers.

Bước 3 — Gửi một payload mà bạn lọc được

Đây là bước mà phần lớn hướng dẫn bỏ qua, và cũng là bước tạo ra khác biệt giữa một hệ thống cảnh báo và một cỗ máy gây ồn.

Hãy dán đoạn này vào Custom Body:

{
  "monitor": "{{name}}",
  "target": "{{hostnameOrURL}}",
  "message": "{{ msg | strip_newlines }}",
  "up": "{{ heartbeatJSON['status'] }}"
}

Uptime Kuma dựng phần thân tùy chỉnh bằng Liquid và cung cấp những biến sau:

Hai chi tiết trong payload đó là cố ý:

strip_newlines áp lên msg. Thông điệp của Uptime Kuma thường chứa ký tự xuống dòng, và một dấu xuống dòng thô nằm trong chuỗi JSON là JSON không hợp lệ. Không có bộ lọc này, webhook của bạn sẽ thỉnh thoảng thất bại — chỉ với những lỗi mà phần văn bản tình cờ có xuống dòng. Nếu bản Uptime Kuma của bạn đủ mới để có bộ lọc json của Liquid, thì "message": {{ msg | json }} (lưu ý: không có dấu nháy bao quanh) còn an toàn hơn, vì nó thoát cả dấu nháy.

heartbeatJSON['status'] thay vì {{status}}. Biến status hiện ra dưới dạng chữ có emoji, rất khó đem đi so sánh. Còn trạng thái heartbeat là một con số thuần:

• 0 — sập
• 1 — hoạt động
• 2 — đang chờ
• 3 — bảo trì

Việc đặt nó trong dấu nháy ("up": "{{ ... }}") cũng quan trọng, và Bước 5 sẽ giải thích vì sao.

Bước 4 — Đừng để cảnh báo hồi phục gọi cho bạn

Một thông báo Uptime Kuma bắn cho cả lúc sập lẫn lúc hồi phục. Cứ để nguyên, thiết lập này sẽ gọi cho bạn khi dịch vụ hỏng rồi gọi tiếp khi nó tự khỏi. Chính cuộc gọi thứ hai mới là thứ dạy người ta phớt lờ cuộc gọi đầu tiên.

Hãy tách chúng ra bằng điều kiện của Echobell, vốn được đánh giá trước khi bất cứ thứ gì được gửi đi:

Trên kênh Production Down (kiểu thông báo Cuộc gọi), hãy đặt điều kiện:

up == "0"

Tạo một kênh thứ hai tên Production Recovered, đặt kiểu thông báo là Thông thường, và cho nó điều kiện:

up == "1"

Với mẫu:

Title: ✅ {{monitor}} is back up
Body: {{message}}

Rồi thêm một thông báo webhook thứ hai trong Uptime Kuma — cùng phần thân tùy chỉnh, cùng danh sách monitor, nhưng trỏ tới URL của kênh hồi phục. Cả hai thông báo đều nhận mọi sự kiện; mỗi kênh tự bỏ đi nửa mà nó không quan tâm.

Kết quả: lúc sập thì đổ chuông, lúc hồi phục thì đến như một thông báo đẩy im ắng để sáng ra bạn đọc.

Bước 5 — Tinh chỉnh monitor để nó đừng báo động giả

Một cuộc gọi mà hóa ra chỉ là chớp mạng hai giây còn tệ hơn không gọi, vì cuộc gọi tiếp theo cũng sẽ bị gạt đi. Ba thiết lập của Uptime Kuma lo phần lớn việc này, tất cả đều nằm ngay trên monitor:

• Retries — đặt là 2 hoặc 3. Uptime Kuma chỉ đánh dấu monitor là sập sau ngần ấy lần thất bại liên tiếp, nhờ vậy lọc được những gói tin rớt lẻ tẻ.
• Heartbeat Retry Interval — tốc độ kiểm tra lại khi đang thất bại. 20–30 giây là mức cân bằng hợp lý; kết hợp với 3 lần thử lại, bạn phát hiện một sự cố thật trong khoảng một phút.
• Resend Notification if Down X times consecutively — đặt khoảng 10 và Uptime Kuma sẽ gọi lại nếu dịch vụ vẫn sập sau mười lần kiểm tra nữa. Đó là một chính sách leo thang thô sơ, nhưng nó hiệu quả.

Nếu bạn muốn một cuộc gọi chưa được nghe tiếp tục thử ngay thay vì chờ tới lần gửi lại, hãy bật Gọi lại khi thất bại trong phần cài đặt ứng dụng Echobell.

Chỉ đổ chuông ngoài giờ làm việc

Trong giờ làm việc, có lẽ bạn vốn đã nhìn dashboard rồi, và một chiếc điện thoại reo lên chỉ là sự gián đoạn không cần thiết. Các biến thời gian hệ thống của Echobell (tất cả theo UTC) cho phép một kênh hành xử khác nhau theo giờ:

up == "0" && (hour >= 17 || hour < 9)

Điều kiện đó chỉ gọi cho bạn ngoài khung 09:00–17:00 UTC. Hãy trỏ một kênh thứ hai kiểu Thông thường vào điều kiện ngược lại để nhận thông báo đẩy ban ngày:

up == "0" && hour >= 9 && hour < 17

Nhớ bù cho múi giờ của chính bạn — những biến này luôn được tính theo UTC. Có phần trình bày đầy đủ hơn trong bài thông báo theo khung giờ với điều kiện UTC.

Chia sẻ cảnh báo với cả nhóm

Một kênh Echobell chia sẻ được với đồng đội qua liên kết đăng ký, và mỗi người đăng ký tự chọn kiểu thông báo của mình. Nhờ vậy cùng một monitor có thể làm điện thoại của kỹ sư đang trực reo lên trong khi chỉ là thông báo đẩy thông thường với những người khác — không tính tiền theo đầu người, không phải viết luật định tuyến riêng trong Uptime Kuma.

Điều này cũng ăn khớp với chính lý do bạn chọn tự host: các monitor ở lại trên hạ tầng của bạn, còn Echobell giữ nội dung và lịch sử thông báo trên thiết bị chứ không phải trên máy chủ của họ.

Thiết lập này không mang lại điều gì

Nói thẳng về ranh giới sẽ giúp bạn tránh một cuộc chuyển đổi tồi tệ về sau. Echobell là lớp gửi thông báo, không phải nền tảng quản lý sự cố. Nó không có:

• Lịch trực xoay vòng hay bàn giao theo múi giờ
• Cây leo thang tự động gọi người thứ hai
• Dòng thời gian sự cố, theo dõi xác nhận, hay công cụ viết postmortem

Nếu nhóm bạn cần những thứ đó, bạn cần PagerDuty, Grafana Cloud IRM hoặc tương tự. Cái mà thiết lập này lo là đúng khoảng trống Uptime Kuma để lại: biến một sự cố đã phát hiện thành một chiếc điện thoại thực sự reo lên. Với người vận hành đơn lẻ, nhóm nhỏ và homelab, thường thì đó là toàn bộ nhu cầu.

Xử lý sự cố

Nút Test chẳng làm gì cả. Đây là chuyện bình thường với payload ở trên, và lần đầu ai cũng thấy khó hiểu. Khi bạn bấm Test, Uptime Kuma không có heartbeat nào để dựng, nên {{ heartbeatJSON['status'] }} trả về chuỗi rỗng và không điều kiện nào khớp. Muốn thử cho đúng, hãy tạo một monitor TCP tạm trỏ tới một cổng chẳng có gì lắng nghe (127.0.0.1:9) và để nó thất bại.

Webhook thỉnh thoảng lỗi. Gần như luôn là chuyện xuống dòng — hãy kiểm tra xem msg đã đi qua strip_newlines chưa. Nó chỉ hỏng với những thông điệp lỗi tình cờ chứa ký tự xuống dòng, nên trông có vẻ ngẫu nhiên.

Echobell trả về success: false kèm HTTP 200. Token của kênh sai hoặc kênh đã bị xóa. Echobell trả 200 với một token không xác định nhưng đúng độ dài, nên hãy xem phần thân JSON chứ đừng nhìn mã trạng thái.

HTTP 405. Kênh đang bật POST Only mà có thứ gì đó gửi GET. Uptime Kuma dùng POST, nên lỗi này thường nghĩa là bạn đã thử URL bằng trình duyệt.

Không thấy reo, nhưng thông báo vẫn đến. Kiểu thông báo của phần đăng ký đang là Thông thường hoặc Khẩn cấp chứ không phải Cuộc gọi. Kiểu thông báo do từng người đăng ký chọn, nên hãy kiểm tra ngay trên thiết bị không reo.

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

Uptime Kuma có tự gọi điện được không?

Không. Uptime Kuma có hơn 90 kênh thông báo, nhưng tất cả đều chuyển tin nhắn. Muốn có cuộc gọi thì phải đưa một webhook tới dịch vụ có khả năng gọi, chẳng hạn Echobell, hoặc dùng một nền tảng quản lý sự cố trả phí.

Cách này có chạy với Uptime Kuma tự host sau tường lửa không?

Có. Webhook là một HTTPS request đi ra từ máy chủ Uptime Kuma của bạn, nên nó chỉ cần tới được hook.echobell.one. Máy chủ của bạn không cần địa chỉ công khai.

Cuộc gọi có vượt qua chế độ Không làm phiền không?

Có. Kiểu thông báo Cuộc gọi của Echobell hiện ra như một cuộc gọi đến, và nó reo xuyên qua chế độ Tập trung cùng Không làm phiền của iOS. Xem vượt qua chế độ Tập trung của iOS cho cảnh báo nguy cấp để biết chi tiết và các thiết lập liên quan.

Làm sao để không bị gọi khi dịch vụ hồi phục?

Hãy dùng hai kênh kèm điều kiện — up == "0" cho kênh cuộc gọi và up == "1" cho kênh hồi phục ở mức ưu tiên thường — rồi trỏ mỗi thông báo webhook vào một kênh. Bước 4 ở trên hướng dẫn chi tiết.

Nhiều người có thể cùng được gọi cho một monitor không?

Có. Hãy chia sẻ kênh với đồng đội, và mỗi người đăng ký tự chọn kiểu thông báo của mình. Ai đăng ký kênh dạng cuộc gọi thì đều được gọi.

Tổng kết

Toàn bộ thiết lập gồm một webhook, một phần thân tùy chỉnh và hai điều kiện. Nó giữ nguyên các monitor, logic thử lại và trang trạng thái của Uptime Kuma, đồng thời khép lại khoảng cách giữa "monitor đã nhận ra" và "một con người đã nhận ra".

Tải Echobell cho iPhone hoặc tải trên Google Play, rồi nối thử một monitor không quan trọng trước và cố ý để nó thất bại. Hãy tin vào con đường đó trước khi bạn thật sự dựa vào nó.

---

Bài liên quan

• Tài liệu tích hợp Uptime Kuma
• Tham chiếu điều kiện của kênh
• Cảnh báo Upptime với Echobell
• Cảnh báo bằng cuộc gọi khi API của bạn sập
• Hướng dẫn khắc phục mệt mỏi vì cảnh báo cho lập trình viên