演講:Monitoring Tools 大亂鬥 - AWS CloudWatch


由 DevOps Taiwan 主辦的活動: Monitoring Tools 大亂鬥

準備的時候思考要講什麼,整理以下的觀點:

  • 談「武」、還是論「俠」? (務實、務虛;肉體、靈魂)
  • Target Audience (TA) 為什麼來?
  • 我能給什麼?

最後我用: 人們不會買你買什麼;他們買你的為什麼 這個角度切入,分享一些觀點、策略、想法、實務經驗,實際講的比較像是心靈雞湯之類的,反而沒啥提太多 CloudWatch,現場的問題與討論是最有價值的,也都跟 SRE 有關係,底下是演講的 Slide:

想了解 CloudWatch 技術細節,參閱 Study Notes - CloudWatch 學習筆記

現場錄影:DevOps Taiwan - Monitoring Tools 大亂鬥

現場的問題

Q: 很大的系統怎麼監控?

原則就是:

  1. 分而治之 (Divide and Conquer): 理清楚架構、分群管理
  2. Prioritize: 定義 SLI / SLO,然後排優先次序
  3. 告警的方法與共識:三個東西要抓住:等級方法對象,詳細參考:淺談系統監控與 CloudWatch 的應用 P95-P108

Q: 現場聊到關於『自動化』的看法

現場我答的不是很好,補充一些想法如下:

  • 自動化之前,要搞清楚其必要性
  • 搞清楚問題的流程、程序,問題出現的頻率
  • 自動化程式本身的開發要注意:可測性、可配置性、確認出入輸出、文件、環境與依賴
  • 自動化執行結果的驅動性:執行結果要怎麼處理?程式本身的問題誰來處理
  • 品質:有沒有 PDCA 循環?Feedback 能否處理?

我類似的心得有很多,請參考這些文章的分享:

Q: 會後有朋友問「值班」、「MIS被當苦力」

這是 Ops 的經典題,所以 SRE 更重要了,上次的 Serverless All-Star 的演講主題:Ops as Code using Serverless 談了不少,有興趣的朋友可以再翻翻。

另外我提到的 Health Check 的層次,詳細參考:淺談系統監控與 CloudWatch 的應用 P19-P29,大概有以下:

  • Light Health Check
  • Layer Health Check
  • Service Health Check
  • Deep Health Check

補充關於監控與人力的調整策略:

現場我回答的時候,少講一個東西:機器總數

  • 機器使用率最大化:考量成本的時候,不調整機器總數,Threshold 越高,例如:CPU Utilization 90% 才告警,缺點就是,人工監控密集度高,反應時間短。
  • 不考量成本的時候,增加機器總數,Threshold 降低,例如:CPU 60% 就告警,因為機器變多了,人的監控可以稍微緩和一下。

這是 出來的,不是對或不對,是看團隊的資源、和公司營運狀況,比較過後的策略。最重要的是:老闆的支持很重要。

感謝

感謝正瑋熱情的邀請,讓我又有機會跟社群的朋友一起討論、分享關於 Ops 的一些事,然後也認識了一些在前線努力的朋友,大家都遇到很多類似的問題,特別是我在 Serverless All-Star 分享的想法,很多朋友在工作上都遇到了,而我只是想把這些問題重新點出來,Feedback 讓大家看到,然後看到這些問題的價值,改變它,希望持續點這把火。

歡迎朋友留言、Feedback 問題給我,或者給我建議,感謝。


延伸閱讀


Comments