CloudWatch for Log Analysis


整理如何利用 CloudWatch 做 Log 分析。

系統監控 + 巨量資料分析

系統監控一定要提到的就是階段性:

  • 資料蒐集 (Ingest) 或者說 資料 (ETL):萃取 (extract)、轉置 (transform)、載入 (load),主要是 Log 的蒐集與,轉換成需要分析的格式。
    • 經驗上來說,這個過程是最花時間的。很多人往往都沒意會到要先把資料格式弄好,才能分析,然後就傻傻的蒐集一堆 非結構化 的資料,結果無法分析,或者要花更多時間重新結構化。
    • Log 的定義非常重要,我以前在做 [自動化測試][8] 的時候,就經常在處理 Log,不管是處理別人的 Log ,還是自己設計 Logger,處理系統 Log 很有感,重點就是:結構化很重要,不要生出一個自己都看不懂,程式無法解析的垃圾出來。
  • 儲存 (Storage):Log 的資料量非常大,需要有相對應的儲存基礎建設才能放置這些資料,AWS 就是 EBS、S3、EFS 等,或者自己建置 DFS (Distribution File System),像是微軟的 DFS 或者 GlusterFS ..
  • 分析 (Analysis):大量運算,通常會跟 Storage 綁在一起。傳統就是用 RDBMS 做、AWS RedShift / Athena、Google 用 BigQuery (儲存 + 分析)
  • 呈現 (Visualize):把分析結果視覺化,市面上常見的事 BI 的產品,像是 Tableau、AWS QuickSight … 等

從開始做 [系統維運開始][4] ,Log 分析 + 系統監控 一直是很大的挑戰,找了很多相關的解決方案,最後都會遇到同樣的問題:

  • 我們到底分析了些什麼?
  • Log 的資料量太巨大,成本很高
  • Log 系統本身不夠穩定,或者很難維護
  • 資料不夠即時,怎麼查詢?
  • 監控系統自己的監控

大數據 (Big Data) 到去年以前還很熱,最近有緩下來趨勢,因為整個生態圈過於技術導向,往往忘了數據本身的目的性,到底是要做什麼?

回到原點,以系統監控來說,要思考幾個重要的東西:

  • 監控指標是哪些?
  • 什麼樣的 Solution 適合?
  • 成本?
  • 監控系統本身能否自動化建置、配置?本身好不好維護管理?
  • 資安: 任何系統都要面對安全性問題,在 AWS 上 VPC / Subnet / SG 的基本規劃很重要,對我來講是基本的東西,可是大部分的人只要能通就好。最近經常發生的:勒索攻擊大舉鎖定後端系統

抓著這些需求,再去找 Solution ,別一開始就陷入技術的泥淖中。


延伸閱讀

系列文章

站內延伸

更新紀錄


Comments