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 分析 + 系統監控 一直是很大的挑戰，找了很多相關的解決方案，最後都會遇到同樣的問題：

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

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

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

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