系統的監控機制

在開發系統時,工程師都會寫 Log 來除錯,當系統上線到正式環境之後,也會將 Log 模式開啟,如果系統發生錯誤,才能將錯誤訊息寫入 Log 檔,方便日後追蹤。工程師通常很忙,不會沒事去看 Log 檔,而是用戶回報系統出問題時,才會打開正式環境的 Log 檔追查問題。

只是,當用戶告知系統出問題時,通常已經是緊急狀況,而如果系統架構龐大又複雜,那麼如何知道要追查哪些 Log?即便對系統架構很熟的工程師,也不一定能在短時間內找出問題根源。

當然我們都知道,可以透過自動化的方式來監控系統的異常狀況。不過,這個需求提出後,通常會被老闆或 PM 打槍,因為他們認為人力投入到系統開發都來不及了,這些沒有產值的需求, 其 Priority 都是非常低。而且系統出問題,都是工程師倒楣,不會是老闆和 PM 在處理,他們不會痛。

到最後,都是工程師默默地花自己的時間,建置 Log 監控工具(例如 ELK),或者用土法煉鋼的方式,寫工具來監控 Log 檔。這些工具一般是用腳本語言(Scripting Language)寫的,例如 Python 或 PowerShell,如果工程師不會寫腳本語言,請趕快學,Ruby 語言發明人松本行弘,曾經建議工程師不管會幾種程式語言,至少要學會一種腳本語言,我想就是這個原因吧。

除了 Log 的監控之外,正式環境基礎建設的健康狀況,例如 CPU 使用率、記憶體與磁碟空間使用量、Ping 值與網路狀況等,更是要嚴密監控,這些相關的監控工具,可以導入市面上的監控軟體,或者自行寫程式監控。

火災警報器的功能,是偵測到煙霧當下,警報器就會響。如果沒有裝設火災警報器,可能你家火燒厝都還不知道。系統的監控機制也是一樣的道理,當正式環境有錯誤發生時,不管有沒有影響到前端用戶的使用,我們都可以及早知道,然後迅速處理,並防範未然。尤其是一個功能剛釋出到正式環境後,更是要密集監控,雖然在釋出前一定會在測試環境測試過無數次,但畢竟正式環境在配置上還是不同於測試環境,甚至有些詭異的錯誤,只會發生在正式環境。

通常,因為人力和成本的關係,系統監控機制不會一步到位,而是逐步建置,依 80 / 20 法則,較可能出問題的點要先做監控。系統監控的覆蓋率和找到問題根源的時間之關係如下圖,一般來說,覆蓋率越高,當系統異常發生時,越能在短時間內找到問題的根源,進而修正。


我以前曾經管理過一百多台的 Windows Server,系統架構錯綜複雜,不可能一台一台人工檢查,最後本著「做好自動化,遠離肝硬化」的精神,自己寫工具監控 Log 檔,每天把可能有問題的 Log Report 寄出,再用肉眼辨識這些錯誤訊息會不會影響到正式環境的運作,然後再跟工程師討論如何修正。

我把之前自己寫的監控工具放在 Github ,有興趣的朋友可以參考使用。這是用 PowerShell 寫的,只能運行在 Windows 上,並監控 Windows Server。





相關文章

如何將電腦畫面經由 Chromecast 投放到電視螢幕上

Chrome 的檔案續傳功能

隱私權政策產生器 Privacy Policy Generator

使用 Vysor 在電腦上控制 Android 裝置