前言
Uptime Kuma 本來就很好用，但如果你要監控超過 1000 個以上的 API，單機版其實會開始卡卡的。這篇我想用 Vibe Coding 的方式，帶大家一步步把 Uptime Kuma 升級成支援 分片 (Sharding) 跟 Cluster 的版本，還會加上 API 讓它更方便自動化。
為什麼要搞集群？
先講需求。 Uptime Kuma 是開源監控軟體，之前我已經分享過怎麼改成用 MariaDB 當後端。 但是當監控超過 1000 個 API 之後，效能就會掉很快。實際測試下來，數量一多就卡到不行。
這對需要提供 SLA 的服務超危險，因為只要監控斷掉或不準，就可能直接違約賠錢。
所以如果規模要衝到 4000 個 API，單機肯定不夠了，這時候就要往 Cluster 架構 走，確保：
- 容錯 / 自動移轉：節點掛掉也能自動切換，不怕中斷
- 負載分散：多台一起跑，效能更穩
- 高可用：避免單點失效，數據透明可靠
- 自動化：能用 API 自動建監控，方便 DevOps
拆解需求，整理思路，請用 Vibe Coding 規劃及實作
用 Vibe Coding 的精神，把需求拆細，然後一段一段做：
1. 分片 (Sharding) 支援
不同的監控器要分散到不同節點去跑：
- 可以新增 / 修改 / 刪除節點
- 清楚標示每個監控器是跑在哪個節點
- 容器啟動時會自動註冊節點到資料庫
2. 健康檢查 (Health Check)
用 Nginx / OpenResty 做節點健康檢查：
- 每 60 秒檢查一次
- 如果連續 3 次失敗 → 判定節點掛掉，狀態改成
offline
3. 容錯移轉 (Failover)
節點掛了，監控任務要自動轉移：
在 DB 加上
default_node_id跟assign_node欄位掛掉時 → 平均分配監控器到其他節點
新邏輯：
- 節點優先跑自己
assign_node的監控器 - 有
assign_node就不用管default_node_id
- 節點優先跑自己
4. 節點復原 (Recovery)
節點恢復之後要能自動回來：
- 重啟後自動註冊，狀態改
online - 系統會把移轉走的監控器搬回來
- 確保不會重複執行，避免資料衝突
- 也提供 手動復原，讓管理員自己決定要不要搬回去
5. API 擴充
Uptime Kuma 其實內建不少邏輯，只是沒開放 API，都是透過Web socket 去調用，既然知道這些，我們可以請AI把 Service 暴露成 API，讓自動化更方便。
系統架構圖
┌─────────────────┐
│ OpenResty │
│ (Nginx+Lua) │
│ 智能負載平衡 │
└─────────┬───────┘
│
┌──────────────────┼────────────────────┐
│ │ │
┌───────────▼─────────┐ ┌─────▼────────────┐ ┌─────▼────────────┐
│ Uptime Kuma │ │ Uptime Kuma │ │ Uptime Kuma │
│ Node 1 │ │ Node 2 │ │ Node 3 │
│ (Port 3001) │ │ (Port 3001) │ │ (Port 3001) │
│ (Host: 9091) │ │ (Host: 9092) │ │ (Host: 9093) │
└─────────┬───────────┘ └─────┬────────────┘ └──────┬───────────┘
│ │ │
└───────────────────┼─────────────────────┘
│
┌─────────▼─────────┐
│ MariaDB │
│ (Port 3306) │
│ (Host: 9090) │
└───────────────────┘
流程圖
┌───────────────────┐
│ Nginx 健康檢查 │
│ (每 60 秒檢查一次) │
└─────────┬─────────┘
│
┌───────────▼───────────┐
│ 節點是否連續失敗 3 次? │
└───────┬─────┬─────────┘
│否 │是
│ │
┌───────▼ ▼──────────┐
│ 狀態維持 online │
└────────────────────────┘
│
┌───────────▼───────────┐
│ 狀態更新為 offline │
└───────────┬───────────┘
│
┌──────────────▼──────────────┐
│ 移轉監控器到其他節點 (平均分配)│
└──────────────┬──────────────┘
│
┌────────────▼────────────┐
│ 其他節點繼續跑監控任務 │
└────────────┬────────────┘
│
┌─────────────────────▼─────────────────────┐
│ 節點恢復 (狀態 online)? │
└───────────┬───────────────┬──────────────┘
│否 │是
│ │
┌───────────▼───────┐ │
│ 節點維持 offline │ │
└───────────────────┘ │
│
┌────────────────▼────────────────┐
│ 監控器搬回原始節點 (避免重複跑)│
└────────────────┬────────────────┘
│
┌───────────────▼───────────────┐
│ 系統恢復正常，持續健康檢查 │
└───────────────────────────────┘
成果展示
