NAS 掛掉了，我的 WhatsUp Gold Server 也跟著掛了，但 WhatsUp Gold 360 仍持續發出警報。
實際使用案例｜2025 年 4 月 13 日
NAS 掛了，WhatsUp Gold 伺服器也跟著掛了，但 WhatsUp Gold 360 仍然發出警報
這次家用實驗室的故障，說明為什麼需要獨立於本地環境之外的監控與通知機制。當本地監控系統也成為故障的一部分時，雲端發出的通知就特別重要。
2025 年 4 月 13 日，我的家用 Proxmox 實驗室發生故障。提供 NFS 儲存空間給多台虛擬機的 NAS 當機，整個儲存陣列也停止運作。
我重新啟動 NAS，但陣列沒有立即恢復。因此，在陣列完成初始化之前，我先從備份還原受影響的 NFS 虛擬機。
這次儲存故障造成的結果很明顯：
- 使用 ZFS 複寫保護的虛擬機幾乎沒有受到影響。
- 依賴 NFS 儲存空間的虛擬機無法使用。
- 我的主要 WhatsUp Gold 伺服器，剛好也是其中一台放在故障 NFS 儲存空間上的虛擬機。
最後一點，讓這次事件不只是一般的儲存故障，也變成對監控架構的一次測試。原本應該負責回報環境狀況的監控系統，自己也跟著故障了。
但這次故障並沒有完全失去消息。 WhatsUp Gold 360 偵測到環境失去回報，並發出通知。
「我的主要 WhatsUp Gold 伺服器，就放在已經掛掉的 NFS 儲存空間上！」
監控盲點：本地監控可能和整個環境一起失效
本地部署的監控系統，需要依靠自己的作業系統、資料庫、運算資源、儲存空間、網路，以及通知服務才能正常運作。
只要其中一項共用資源故障，監控系統可能也會一起消失。這就像讓警衛和被保護的建築物共用同一把電源開關；電源一斷，警衛也無法回報狀況。
本地通知系統通常也會依賴同一條網際網路連線或電子郵件服務。如果這些服務本身就是故障的一部分，通知可能會延遲，甚至完全送不出去。
我的家用實驗室故障也是類似情況，只是出問題的不是網際網路，而是共用儲存空間。
但對監控伺服器來說，結果是一樣的：它已經無法代表整個環境發聲。
當監控系統自己的基礎架構故障時，還有誰負責監控它？
WhatsUp Gold 360 如何提供獨立的監控訊號
WhatsUp Gold 360 會在受監控的環境中部署專屬的 Cloud Connector（雲端連接器）。這個連接器會與雲端服務保持聯繫，並執行心跳、Ping，以及網路路徑健康檢查。
當連接器無法連線，或符合預先設定的規則時，雲端服務就能透過電子郵件或簡訊發出通知。
我們可以把這種方式稱為「獨立於本地環境之外的通知路徑」。簡單來說，警報是由雲端服務產生，而不是由本地 WhatsUp Gold 伺服器或本地 SMTP 郵件服務產生。
即使本地監控伺服器已經停止運作，雲端仍然可以觀察環境是否還有回應：
- Cloud Connector 是否仍在回報狀態。
- 原本應該定期收到的心跳訊號是否突然消失。
這就像在建築物外另外安排一名保全。即使大樓內的保全室停電，外部保全仍然能發現大樓失去聯絡。
獨立的通知路徑
| 層級 | 在通知流程中的作用 |
|---|---|
| Cloud Connector | 部署在受監控環境中，向 WhatsUp Gold 360 雲端執行心跳、Ping，以及網路路徑健康檢查。 |
| WhatsUp Gold 360 | 追蹤連接器是否可連線、最後回報時間、可用性、延遲、封包遺失，以及網路路徑資訊。 |
| 通知管道 | 透過雲端服務，在連接器無法使用或符合設定規則時，發送電子郵件或簡訊。 |
WhatsUp Gold 360 偵測到什麼，也沒有偵測到什麼
WhatsUp Gold 360 並沒有直接檢查 NAS，然後告訴我「儲存陣列已經鎖死」。它偵測到的是：原本應該持續收到的環境訊號中斷了，或某個受監控元件已經停止回報。
心跳訊號消失，可能代表許多不同的問題：
- 網際網路連線中斷。
- 停電。
- Cloud Connector 或虛擬機故障。
- 虛擬化平台或主機發生問題。
- 儲存系統故障。
- 整個據點發生故障。
這次警報告訴我：環境需要立即檢查。之後進一步調查，才確認真正原因是 NAS 與 NFS 儲存空間故障。
這就像汽車儀表板亮起警示燈。警示燈會告訴你「有問題」，但不一定直接告訴你是哪個零件壞了。先收到警告，才有機會開始找出根本原因。
因此，偵測故障與找出原因是兩個不同步驟。監控系統首先要做的，是確保問題不會悄悄發生而沒人知道。
不只是簡單的「在線」或「離線」檢查
WhatsUp Gold 360 儀表板能提供更多心跳中斷的相關資訊，例如連接器狀態、運作時間、網際網路連線事件、可用性、延遲、封包遺失，以及可展開查看的網路路徑詳細資料。
「隨時間變化的延遲」和「隨時間變化的網路路徑」等資訊，有助於分辨問題是突然發生的本地故障，還是反覆出現的廣域網路不穩定、路徑變更，或網際網路服務供應商的問題。
這些資料也很適合用來記錄 ISP 故障，或在需要升級頻寬、更換供應商時，提供具體的依據。
為什麼這不只是家用實驗室的問題
相同的故障模式，也可能出現在分公司、零售門市、學校、診所、工廠，以及代管服務環境。
一台本地 WhatsUp Gold 伺服器，可能同時監控交換器、無線基地台、應用程式、主機、儲存設備與 WAN 連線；但它自己也可能運作在同一套本地虛擬化平台或儲存系統上。
如果虛擬化平台、據點電力，或網際網路線路發生故障，本地監控系統可能無法發出警報。
透過雲端觀察心跳，中央 IT 團隊就能用另一個獨立方式得知遠端據點已經失去連線，而不是等到使用者或客戶打電話反映。
這就是這項設計背後的實際價值：
- 更快發現問題。
- 提供更可靠的通知管道。
- 減少確認遠端據點是否在線上的時間。
- 更容易調查反覆發生的連線問題。
這次故障帶來的架構經驗
分開不同的故障範圍
在可行的情況下，不要把主要監控伺服器、資料庫、Cloud Connector，以及唯一可用的備份，都放在同一台主機或同一套儲存平台上。
Cloud Connector 不一定能在每一種事故中繼續運作，但整體設計應該確保兩件事至少有一件成立：
- 連接器仍然可以運作並回報問題。
- 連接器消失後，雲端可以發現並通知相關人員。
把心跳中斷視為據點層級事件
心跳消失可能只是網際網路故障，但也可能代表整個虛擬化平台、儲存系統、監控環境，甚至整個實體據點都已經失去服務。
如果無法確認只是單純的網路問題，就應該把警報交給能檢查更大範圍基礎架構的人員處理。
主動測試故障通知流程
不要等到真正發生儲存故障時，才發現雲端通知根本沒有設定好。
可以安排一次受控測試，例如：
- 暫停測試用的 Cloud Connector。
- 暫時阻擋連接器的對外連線。
- 安排維護演練。
透過這些測試，可以確認預期的電子郵件或簡訊是否能正常收到，也能確認後續處理流程是否清楚。
保護管理系統
這次事件中，使用 ZFS 複寫的虛擬機仍然正常運作，但使用 NFS 儲存空間的虛擬機則無法使用。
這不代表某一種儲存設計永遠比較好，但它提醒我們：監控、備份、身分驗證與管理系統，都應該有獨立的復原方式。
因為當其他系統都故障時，這些工具正是我們用來處理問題的工具。就像救生艇一樣，平常可能用不到，但不能和主船放在同一個會一起沉沒的位置。
從心跳監控，延伸到更完整的雲端服務
WhatsUp Gold 360 先解決這次事件中最直接的問題：當本地監控失效時，仍然保留一條獨立的通知管道。
之後，這個雲端平台也能延伸到集中式可視性，以及更智慧的事件處理流程。
另一個實用功能是，你可以將 WhatsUp Gold 伺服器加入同步，讓 Cloud Connector 與 WhatsUp Gold 360 搭配使用。
如此一來，你可以從任何地方查看本地監控資料，不需要直接把 WhatsUp Gold 伺服器暴露在網際網路上。
未來還會推出更多功能。現在先部署 WhatsUp Gold 360 Connector 虛擬應用裝置，就能提前準備，之後更容易使用這些功能。
這次故障很嚴重，但並沒有悄悄發生
NAS 故障了。承載多台虛擬機的 NFS 儲存空間停止運作。我的主要 WhatsUp Gold 伺服器也跟著離線。
我在 ZFS 複寫的虛擬機持續運作期間，從備份還原受到影響的工作負載。
最重要的是，WhatsUp Gold 360 通知我：整個環境已經停止回報。
它沒有阻止故障發生，也沒有取代後續調查。但它提供了獨立的警告，讓我能及早開始處理問題。
這正是網際網路連線與心跳監控應該提供的價值：不是保證基礎架構永遠不會故障，而是讓你相信，重大故障不會在沒有人注意的情況下持續發生。
因為有時候，最需要被監控的系統，就是監控系統本身。
如需了解完整的 Proxmox 架構、高可用性復原結果，以及 4 月 13 日的儲存故障更新，請參閱 Proxmox HA：從真實主機故障中復原。
文章來源: The NAS Died. My WhatsUp Gold Server Died With It. WhatsUp Gold 360 Still Alerted Me.
