CloudWatch for Monitoring and Alarm Systems


本文整理 CloudWatch 最主要的應用:監控服務告警系統 的建置。


監控系統

下圖是我畫的 CloudWatch Services 做系統監控的流程:

這個流程會使用到整個 CloudWatch Services,包含 Logs / Alarms / Metric Filers / Custom Metric / Dashboard,最後配合 CloudWatch Rules / SNS / Lambda 做事件驅動,最後通知到 Slack / SMS .. 等。

值得一提的是,這整串流程是 即時 (Realtime),如果自己蓋類似的服務,我 Survey 過知名的組合,像是:

  • ELK: 使用了兩年,C/P 值不高,費用以及維護成本驚人,雖然後來有系統架構的解法,但是基於成本考量,打算慢慢換掉。
  • Telegraf / Collectd + InfluxDB + Grafana: 很容易安裝,效果也不錯,但是 InfluxDB 需要有好的 File System 支撐。
    • Grafana 每個 Metric 只能設定一個 Alert, 而且 Source 如果是 CloudWatch 就不支援 Alert
    • Grafana 可以跟 Slack + S3 整合,然後把 Metric 圖檔直接丟到 S3,然後在 Slack 呈現。這是我一直很想要的功能,Datadog 有。
    • aws-cloudwatch-chart-slack
  • Fluentd + Prometheus + Grafana: 理由同上

這些都要自己養機器,特別是維護 Storage 部分,會有很多額外的 Operations、教育訓練、權限管控、安全性,最重要的是成本高很多,而且效果不見得好,C/P 值不高。

使用 AWS CloudWatch 整套方案,幾乎可以避免上述我擔心的問題,而且維護 CloudWatch 本身,除了 Dashboard 之外,都可以程式化。唯一要注意的是 CloudWatch Price,要留意 Log 的使用狀況,以及設定 Expiration。

告警系統 (Alarm Systems)

底下是我利用 CloudWatch + Lambda 設計的告警系統 Alarm System,主要設計概念如下:

  • 監控通知定義三種:InfoWarningUrgent
    • Info:設計成 Reporter 形式 (Long Polling),定時把資訊丟到 Slack 的特定 channel,這樣的設計讓系統維運人員可以隨時掌握系統狀況,而且不用帶電腦
    • Warning:超過指標的臨界值,就會通報道 Slack 主要負責單位的 channel,並且 @channel
    • Urgent:同時丟 Slack Channel + 送簡訊給對應的人 (SNS -> SMS)
  • 通報只有一個重點:出問題要能知道問題是啥、然後有人可以去處理

設計的重點在於:

  • 什麼樣的 告警等級,用什麼樣的 方式,通知到 什麼人
    • 告警 一詞是我當兵時任務用詞,我們主要維護實體通訊線路,確保線路正常,當出現異常時,稱『告警搶修』
  • 等級、方式、人
    • 等級:不同人看不同等級,不需要全部的人都知道
    • 方式:有即時性以及時效性的問題
    • :找到對的人,才能快速把問題排除

參加 AWS User Group 有人推薦用 Push …. 我回家路上一值想,為啥我都沒想到這個方法??因為,我從來不會看 APP 的 Push,因為跟山一樣多,都直接忽略 XDD


延伸閱讀

系列文章

站內延伸

參考資料

更新紀錄


Comments