一個監控工具只靠一條命令就跑起來，到底省了多少事？

現在搭個服務狀態頁面，動不動就要配PostgreSQL，配Redis，再搞個K8s集群。

前兩天在GitHub上翻到一個叫BetterStatusPage的開源項目，部署方式就一行docker compose up -d。整個應用跑在單個Node.js 22進程上，數據庫用的SQLite，不需要額外裝任何數據庫服務器、緩存或者消息隊列。

這個項目目前還在MVP階段，但核心功能已經能用了。最讓我意外的是它內置了備份和離線恢復——萬一哪天服務器掛了，拿之前的備份文件直接恢復，不至于從頭配起。

監控能查什么

監控類型覆蓋得比較全。HTTP和HTTPS檢查是基本功，能校驗返回的狀態碼、響應時間，還能在響應正文里搜關鍵詞。身份認證方面支持基礎認證、OAuth2和CAS三種方式，對內部系統監控比較實用。

網絡層面的檢查也沒落下：ICMP ping用來測連通性，TCP端口檢查可以確認服務端口是否在監聽。DNS監控覆蓋了A、AAAA、MX、CNAME和TXT五種記錄類型，域名解析出問題能第一時間發現。

數據庫層面目前只支持SQL Server的測試查詢，對于用微軟技術棧的團隊算是個加分項。還有一個被動Webhook監控功能，cron任務跑完或者外部服務要上報狀態時，調個接口就行。

告警能發到哪兒

通知渠道覆蓋了五種：郵件、通用Webhook、Discord、Slack和Microsoft Teams。告警發出去如果失敗了，系統會自動重試，管理員也可以在后臺面板里手動檢查失敗記錄、手動重發。

這個重試機制比很多商業SaaS做得都好——至少你不用半夜被吵醒之后，還得去排查"為什么告警沒收到"這種二次傷害的問題。

恢復通知也支持，服務恢復正常了會自動發一條消息，不用手動更新狀態。

狀態頁和事件管理

公開狀態頁的編輯方式是拖拽網格布局。你可以往上拖監控卡片、服務分組、Markdown文本塊，還有一個事件時間線組件，全程不需要寫CSS。自定義品牌標識和深色模式也做了，多語言支持也在功能列表里。

事件管理這邊的功能設計得比較細。創建事件時可以標記嚴重等級、關聯受影響的監控項，還能添加事件更新的時間線記錄。定時維護窗口也支持——你設定下周三凌晨維護，系統會自動在這個時間段抑制告警，不會給用戶發一堆假警報。

監控依賴關系這個功能挺少見的。比如你有臺服務器宕機了，上面跑的三個服務都會報故障。配好依賴關系后，系統知道根因是服務器掛了，只發一條告警，不會同時彈三條通知把你淹掉。

實時更新走的是Server-Sent Events協議，狀態頁上監控項的狀態變化會實時推送到瀏覽器。運行時間歷史記錄也保留著，想看過去七天某個接口的可用率，直接查就行。

用戶角色、審計日志這些企業級功能也都做了，審計日志能記錄字段級別的變更——誰在什么時候把監控間隔從30秒改成10秒了，一查就知道。

安全方面做了個AES-256-GCM加密的憑據保險箱。數據庫連接字符串、API令牌這些東西不需要明文寫在監控配置里，加密存進去就行。

為什么要做這個項目

作者的想法很直接：他要的不只是一個簡單的uptime檢測器，但也不想為了搭狀態頁專門維護一套基礎設施。很多小團隊、家庭實驗室或者個人項目，配數據庫服務器、緩存、消息隊列再加好幾個容器的運維成本，比狀態頁本身的業務價值還高。

BetterStatusPage的目標體驗就是一條命令啟動，一個進程一個端口跑完全部功能。不需要先裝PostgreSQL、裝Redis、配集群網絡，省下來的時間精力可以干點別的。

目前作者在找人幫忙測試部署、在家庭實驗室或者小規模生產環境里跑跑看，報bug、審安全設計、提缺失的監控類型或者集成需求——特別是安裝升級體驗、界面配置易用性、通知可靠性這些方面，還有"你覺得自己不會認真用它之前，它還需要什么功能"這類直擊要害的反饋。

MIT協議開源，GitHub地址在BElluu/BetterStatusPage，有興趣可以直接拉下來跑一趟。