這是一個真實事件。
某個週日早上，SI 告知客戶的主機服務全掛了，警報也沒有傳遞出來，請我協助查看。 (此案我負責建置此客戶的 LibreNMS 做為系統監視與告警)
問題狀況
到現場查看狀況，擺在 ESXi 虛擬機裡的 LibreNMS 網頁服務運作異常有 could not connect to mysql 的錯誤訊息，SSH 進入後顯示發現整個系統變為唯讀無法寫入，重新開機後則無法進入系統停在 busybox，判斷是磁碟有問題。
回到 ESXi 管理介面上，在該 ESXi 的事件裡有多起寫入磁碟的錯誤事件。
現場這台 LibreNMS 暫時無法開機查看記錄，改用客戶另一個辦公室的第二台 LibreNMS 進行追查，馬上就看到 LibreNMS 記下在發生主機服務全部掛掉的前兩天 (也就是週五) 中午左右就已經出現 vmnic down 的事件，更加確認。
LibreNMS 所記錄的 vmnic down 事件
也就是說，當前兩天開始發生網路中斷的錯誤後，之後陸續有幾次網路斷線以及 VM 寫入當機的警報，但相關人員一直沒有重視與處理，終於導致最後爆發全部陣亡的慘案。
當然除了看中斷的事件之外，同時也搭配當時的 ping 回應、disk i/o 效能、network 流量等數據圖參考運用，快速判斷問題範圍與時間點。
再回到 ESXi 上對照該 vmnic 以及 datastore 的關係，赫然發現原本這些虛擬機應該是使用一部 S 牌 NAS 的空間，卻被接到另一台由 Windows Storage Server 所建立的空間，而 vmnic down 就是跟這個空間的主機相關，而且這個 vmnic 經過 iSCSI 接出來線路只有一條，沒有做兩條容錯備援機制，所以當時一發生網路問題是相關的 VM 寫入行為全部出現問題。
ESXi 儲存區出現降級
到這裡就覺得奇怪，設備怎麼被換掉了？
找出原因
經過詢問相關人員得知，當時因為維護等原因，先把 VM 磁碟暫時移到一部臨時的 Windows Storage Server 運作，但維護作業完成後卻沒有把 VM 移回原有之處，而這臨時 Storage 所用的網路並沒有獨立切開，而是跟整個 Service 網路串在一起，所以除了沒做雙線路容錯備援之外，流量混雜造成網路效能與寫入瓶頸，是導致此次事件的發生的起火點之一。
最早客戶與 SI 以為是虛擬機運作問題，而後經由 LibreNMS 所記錄下的所有線索，方能還原現場，指出是因儲存主機被更換、網路效能不夠、寫入出現問題、等等，並可確認問題各個階段的發生時間，方不致於未知問題所在，只能治標，而無法治本。
更有趣的是，直至我查明所有問題後，也順便發現客戶的 vCenter 已經掛掉很久...
結論
原本我的工作是負責將 LibreNMS 修復 (最後原主機採用 fsck 方式修復，LibreNMS 又活過來了)，結果變成把整串事件給挖掘出來，是一次很有趣的經驗。
LibreNMS 的價值在於資料搜集、中央儲存與自動告警，而且提早發出資訊可以協助資訊人員快速定位問題所在，除了省時更加省力。
若有需要建置導入，歡迎洽詢節省工具箱。
