系統監控「監控」及「處理」
【系統監控】
一開始必須了解監控這件事情。在發生問題點的前後所有的行動、動作，當問題發生後就必須立即止血，
而問題發生點以前就是所謂的「監控」。
系統監控是希望在任何事件發生前能掌握系統相關因子，能提早發現狀況並提供有意義的資訊進行判斷，
在狀況未發生前面對問題解決它，乃至於事情發生時能盡速掌握問題來解決。
【監控的目的 / 目標】
《 事前預防回饋給團隊 》，「監」可以解釋為蒐集資訊；「控」可以解釋為控制蒐集的資訊。
因此要有效蒐集系統資訊，將資訊進行分類並篩選出所需資訊，對於資訊進行分析、給予回饋，
接著利用得到的結果來控制我們要達成的目的。
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/