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 的應用


延伸閱讀

系列文章

參考資料

更新紀錄


Comments