系統監控 - 心得整理

系統監控「監控」及「處理」

【系統監控】

一開始必須了解監控這件事情。在發生問題點的前後所有的行動、動作,當問題發生後就必須立即止血,

而問題發生點以前就是所謂的「監控」。

系統監控是希望在任何事件發生前能掌握系統相關因子,能提早發現狀況並提供有意義的資訊進行判斷,

在狀況未發生前面對問題解決它,乃至於事情發生時能盡速掌握問題來解決。
 

【監控的目的 / 目標】

《 事前預防回饋給團隊 》,「監」可以解釋為蒐集資訊;「控」可以解釋為控制蒐集的資訊。

因此要有效蒐集系統資訊,將資訊進行分類並篩選出所需資訊,對於資訊進行分析、給予回饋,

接著利用得到的結果來控制我們要達成的目的。


 

1. 系統是否正常

整個公司所有人都會關心系統正不正常這件事情,但是每個人關心系統是否正常的關注點不一定相同,

因此一定要使用簡潔且定義清楚的顯示方式來作為溝通的共用語言。

 

將系統是否正常分為數個層級

I.Light / Static Health Check

II.Layer Health Check

III.Deep Health Check

因此每個層級都應可以測試是否成功且設計成API,可以讓每位想知道的人都可以易於使用並回傳定義清楚的回覆結果。
 

2. 如何知道現在的服務狀況

如果使用 Dashboard 或許能一覽無遺的顯示出所有系統內要監控的部分,

但是由於資訊過於龐大或許充斥著許多不是你需要關注的資訊,

且負責監控的同仁就必須要時常開啟一塊提供「完整」系統的資訊儀表板,若是沒有電腦在身邊就更顯得麻煩。

因此把對的資訊提供給正確需要的人,並使用如 Slack 串接蒐集資訊的工具搭配示警的設定,

能使系統保持全年無休的監控狀態,而監控同仁也能專注在其他負責的部分。

 

3. 監控哪些指標

- 指標的層級

I. Business

II. Application / Service

III. System / Virtual Machine

IV. Network Infrastructure

 

- 而依照所要監控的層級來蒐集資訊/分析固然合理,但是仍要考慮數據存放的位置、成本等。

- 監控的指標、資訊在寫 Log 的時候要仔細設定資料結構,使後續 Filter 好查找。

 

4. 異常通報

- 常見問題:

I. 嚴重程度沒有區分

II. 通知方式過多且訊息太多導致最後沒人看

III.沒有快速找到對的人

為了避免問題發生,因此要針對「異常等級」、「通報方式」、「通報對象」來做區分。

 

(1). 異常等級:

可以使用「綠、黃、紅」來定義異常的嚴重等級,

綠:一般資訊;黃:要注意系統狀況;紅:必須立即處理

 

(2). 通報方式:

通常通報方式會使用 Email、Slack、Voice Call 等,

但是訊息量一多 Email、Slack 就容易被忽略,而且也容易變成擾人的訊息,

如果能依照異常等級來做通報,不僅能區隔異常等級也能提供較有意義的異常訊息。

 

(3). 通報對象:

判斷出「異常等級」及使用較有效的「通報方式」後,那應該將異常訊息通知給什麼人就是重要課題。

應該要把問題給對的人解決,例如已經發生「紅色」的異常,那當然要馬上通知管理者立即的解決問題,

所以定義對的通報對象,將問題提供到對的人身上,這樣才能減少溝通成本並準確地排除異常狀況。

 

當建立良好的通報系統後,如何能使得接收到的對象不掉球,且讓需要觀察的人員能掌握到目前處理進度,

目前自己的經驗是使用 Slack 通知的話必須要在 Thread 回報「處理中」、處理進度等回報,

如此方便掌握也確認有人處理。

 

【總結】

系統監控前期需要設計良好的資料結構來儲存有意義的資訊,並且針對儲存的 Log 容易進行 Filter,

然而儲存了大量的資訊後,如何儲存、該保留多少資料供查找,

保存大量的資訊成本對於公司來說也是一個支出,這也是要考慮。

針對異常進行層級區分,並定義異常等級來將異常資訊告知正確的負責人,

希望能在最短時間找到對的人並且解決問題,避免公司營運收到影響。

 

監控不只是在問題發生時後進行解決,也期待能判斷出有可能發生異常,或者有可能因為流量、

資料量的提升時有可能會產生問題,如何避免問題發生也是監控一項很重要的分析工作。

 

參考資訊:

https://rickhw.github.io/2017/06/21/AWS/Stategies-System-Monitor_and_CloudWatch/

https://rickhw.github.io/2017/12/22/DevOps/What-is-Monitoring/