Kuvasz 是一套開源的可用性與 SSL 監控服務，4.0 於 2026 年 6 月 16 日推出。多數自架玩家提到 uptime 監控會先想到 Uptime Kuma——介面直覺、Docker 一支指令拉起來、社群活躍。但監控項目多起來、開始想把設定塞進 Git 版控、或需要跨主機備份的時候，SQLite 這條臍帶就會慢慢卡到手。Kuvasz 就是為了這個場景長出來的替代品：PostgreSQL 從第一天就是預設後端，監控項目透過 YAML 定義並版控，v4 還把 MCP server 直接塞進主程序，讓 Claude、Cursor 這類 AI 助理可以原生呼叫。
SQLite 撐得起 Home Lab、撐不起半正式的監控
Uptime Kuma 從 1.x 到 2025 年 10 月釋出的 2.0 為止，唯一的儲存後端一直是 SQLite。單檔案、零設定，對兩三個網站沒有痛點。真正卡住是等監控項目突破幾十個、interval 壓到 20 秒以下之後——寫入鎖競爭、狀態頁面 lag、備份時抓到破損檔的風險，這些症狀會逐一浮出來。SQLite 沒有 native 的複寫，多實例 HA 得靠外掛 daemon 或分散式檔案系統，兩條路的複雜度都跟監控本身不成比例。
備份是另一個容易被忽略的角度。SQLite 檔案在寫入時 hot copy 拿到 corrupt 檔的機率不算低，正確做法是走 sqlite3 .backup 或 WAL 檢查點。實務上多數人是直接 cp，出事才知道備份沒用。同樣的資料放在 PostgreSQL，一支 pg_dump 就結案，這差距在監控愈重要時愈明顯。
Uptime Kuma 2.0 補的一半：只給 MariaDB，還不給遷移
2.0 版終於把 MariaDB 塞進來，同時加了 rootless Docker 跟 UI 翻新。乍看之下 SQLite 的天花板要拆了，但細節有兩個坑：PostgreSQL 仍然不在支援清單，官方 issue 上一路擱著；更麻煩的是——官方明說不提供 SQLite 到 MariaDB 的資料遷移路徑，換資料庫等於歷史統計歸零重建。
對純新裝的使用者這不是問題，但對已經跑了半年、累積好幾萬筆 heartbeat 紀錄的環境，等於要在「留在 SQLite 繼續撞牆」跟「丟掉歷史資料換一個能擴充的後端」之間二選一。這是 Kuvasz 開始被拿來討論的直接原因。
PostgreSQL 是預設而非選項
Kuvasz 從 v1 開始就把 PostgreSQL 當唯一支援的儲存後端，沒有 SQLite 模式讓人「先試試看」。這是有意的取捨——放棄零依賴的簡單，換來後續可以直接接 streaming replication、point-in-time recovery、報表 dashboard 用的 read replica。歷史 metrics 資料量大的時候還能直接掛 TimescaleDB 或 pg_partman 做分區，這些選項在 SQLite 環境裡都不存在。
實際跑起來的門檻並不算高。一支 Docker Compose 拉起 Kuvasz 主程序加上 PostgreSQL 14 以上就完事，記憶體分配總計不到 500MB。監控間隔最短可以壓到 5 秒，項目數沒有上限，跟 UptimeRobot 免費 tier 給 50 個監控、5 分鐘 interval 的對照相當明顯。5 秒 interval 用來監控自家內網 API 或 CDN edge node 剛好夠靈敏；對外部服務通常拉到 30 秒到 1 分鐘，避免把對方 rate limit 打爆。
Prometheus 跟 OpenTelemetry 匯出端點也是內建的，不用另外掛 exporter。想把可用性 metrics 送進既有的 Grafana 或 SigNoz 儀表板，Scrape target 加一行就完成，這在 Uptime Kuma 那邊得靠社群第三方 exporter 才做得到。
YAML 是 source of truth，UI 只能看
v4 最有意思的改動不在協定或介面，而是 IaC 這條線。監控項目可以完全從一支 YAML 定義：
1 | http-monitors: |
Kuvasz 開機時把這份 YAML 拿去跟資料庫對帳：檔案裡有、資料庫沒有的建立起來；資料庫有、檔案裡沒有的刪掉；同名的以檔案版本覆蓋。整個模型跟 Kubernetes 的 declarative reconciliation 一致，Git PR review、CI 自動 apply、rollback 都能照 GitOps 流程走。
要注意的兩個坑：一是某個類型的監控一旦寫進 YAML，就不能再從 UI 或 REST API 修改——僅能查看；二是 Kuvasz 用 name 當唯一鍵，改名等於刪掉舊監控再建一個新的，歷史資料一併消失。這規則不是 bug，但團隊導入時要在 onboarding 文件裡明講。
MCP server 把監控介面塞給 AI 助理
v4 內建了實驗性質的 Model Context Protocol server。過去要讓 Claude 或 Cursor 這類助理讀到監控狀態，得先架 REST API、再包一層 MCP wrapper。Kuvasz 直接在主程序把 tool interface 暴露出來，AI 助理可以原生呼叫 list_monitors、get_incidents、toggle_monitor 這幾支工具。
安全上做了分層——REST API 跟 MCP server 各用獨立的 API key，可以只發 read-only 的 MCP key 給 AI，寫入權留在人手上。認證則新增 OIDC，Keycloak、Authentik、Auth0 都能直接接，密碼登入不再是唯一選項。對機房或 VPS 運維來說，一句「幫我看 mail server 的 SSL 剩幾天」就能直接查到答案，不用再切標籤打開儀表板。
Push 監控補上排程任務的空缺
Pull 型監控只能查到「服務有沒有回應」，補不到「排程任務有沒有跑」這一塊。備份 script、日誌輪替、定期健康檢查這類 cron job 失敗時通常沒有對外 endpoint 可以打，Kuvasz 的 push monitor（heartbeat）用反向思路解決：每個 job 拿到一個 URL，跑完就 POST 一下，超過 grace period 沒收到心跳就發警報。
典型用法是把 URL 塞進 crontab 尾端：
1 | 0 3 * * * /usr/local/bin/backup.sh && curl -fsS https://kuvasz.example.tw/push/xxx > /dev/null |
備份成功才會呼叫尾端的 curl，失敗、卡死、機器整臺當掉都會讓心跳缺席，Kuvasz 過了 grace period 沒收到就觸發通知。功能上跟 Healthchecks.io 提供的 SaaS 版本重疊，但整個機制長在同一支 Kuvasz 實例裡，不用另外部署一個服務、也不用把備份訊號送到公網外部——對敏感資料的排程任務尤其實在。
什麼情境下應該切過去
Uptime Kuma 對只有幾個服務、可用性標準寬鬆的 Home Lab 依然是最省事的選擇。監控項目破 30 個、需要把設定塞進 Git、或多人共同維護一份監控清單時，換到 Kuvasz 帶來的可維護性差距會很快回本。JVM 應用起手記憶體稍重，但穩態下的資源需求並不極端，最小規格的 VPS 也撐得起。
臺灣的中小企業如果打算把 uptime 監控從 UptimeRobot、Better Stack 這類 SaaS 搬回自家機房，Kuvasz + PostgreSQL + Git-managed YAML 是 2026 年最合理的組合。NCSE Network 提供的臺灣 VPS 主機（是方電訊機房、Intel Gold CPU、NVMe SSD）搭配穩定的低延遲網路，很適合承載這種需要長時間穩定運行、對延遲敏感的監控節點——把探測點放在臺灣本地，量到的才是臺灣使用者實際看到的服務品質。
