Study Notes - CloudWatch FAQ

本篇整理 CloudWatch 常見問答。

問與答

常見問題

Q: Dashboard 可不可以透過程式化動態控制？

可以，Dashboard 可以匯入/匯出 config as JSON，作為版控、或者分享、動態產生。

AWS CLI: get-dashboard, put-dashboard

Q: CWL 上的 Log 可否做類似 Kibana 複雜的查詢？像是查詢條件、集合、統計功能？

可以透過 CloudWatch Insight 做 Aggregation，執行類似 count, sum, group by … 等常用的統計功能。

Q: CWL 上的資料可否落地到 S3 備查？

可以，透過 Kinesis Firehose 即可。注意，寫文章的時候，CW Console 上並沒有對應選項，需要透過 AWS CLI 才行。

AWS CLI: put-subscription-filter –destination-arn [Amazon Kinesis Firehose]

老問題：自己蓋監控系統 or 被 AWS 綁死？

CloudWatch 透過 awslogs agnet + CloudWatch Log + Metric Filter + Alarm + Dashboard，就可以建立屬於自己的監控系統。當然也可以去找外面做好的 Solution，像是監控 Elasticsearch 外面有很多 Solutions，可是往往不知其所以然，反正花錢他就是會動了。

與其如此，不如自己試著：

定義系統的監控指標：設計一個系統的健康檢查報表，這些數據是自己定義出來的，定義的好壞精準於否，取決於自己對系統了解的深度與廣度。
設計 Log 格式：好的 Log 格式才容易解析，資訊也才不會掉東掉西
建置 Log 蒐集的方式：pull (SNMP) or push mode (agent base) 都是常見的方法。
資料儲存：Log 資料量通常都很大，要怎麼存？批次還是即時？放到 S3 的目錄結構怎麼規劃？記得定義 + 設定 Lifecycle。
數據分析的方式：怎麼計算？需要多少資源？
監控指標的呈現：回到第一個點，系統健康檢查報表要呈現什麼？
監控指標的異常通報 (Alarm)：什麼是異常？怎麼通報？SNS、Slack、EMail、SMS、Push
- 我會定義等級，就像是一般程式的 Log 會有 Info, Debug, Error, Fatal, 更細分的會有 Trace Level，像是 Step In, Step Out .. 等

如果是自己蓋的話，架構的設計要考量 SLA，因為如果掛了，能接受多久的 Downtime？資料遺失？資料怎麼蒐集？用 CloudWatch 有個好處，是全部 Managed Services，不用自己蓋機器，大部分可以自動化。

缺點就是被 AWS 綁死，兩年前我就是這樣想，所以到現在才研究 CloudWatch … 現在懶得想那些，就綁死吧 XDD

CloudWatch 的成本

Ingest API
CloudWatch Logs

常見的應用場景

系統資源的監控
Dashboard 系統訊息看板 (即時)
自訂監控指標 (Metric)
即時 Log 蒐集與儲存
Log 批次備份 (S3)

後話

其實在做 系統監控 我會一直想到以前在研究數位音樂科技，特別是混音時常用的一些 EQ / Filter … 基本上跟監控系統的 Alarm 概念一模一樣 XD

更多監控的策略想法請參考我在 AWS User Group Taiwan 的分享：淺談系統監控與 CloudWatch 的應用

Study Notes - CloudWatch FAQ

問與答

常見問題

老問題：自己蓋監控系統 or 被 AWS 綁死？

CloudWatch 的成本

常見的應用場景

後話

延伸閱讀

系列文章

參考資料

更新紀錄

Comments

About

著作

演講

Facebook

AWS Certifications