Study Notes - CloudWatch

CloudWatch 是 AWS 的全託管 (Managed Service) 監控服務，在眾多 AWS 服務預設都會使用，了解他的基本概念與應用，在學習 AWS 服務中是相當重要的。

Log 處理的核心概念

我參考了 Big Data 的處理流水線 (Pipeline)，如下圖：

以此為概念將 Log Process，分成四個階段：

蒐集 Ingest: 從資料產生端，蒐集 Log 資料，有時候會包含 ETL (Extra-Transform-Load)、DLP (Data Leak Prevention, 資料外洩防護)
儲存 Store: 將 Log 儲存到儲存體，常見的 OSS 像是 Elasticsearch、InfluxDB、Prometheus …
處理 Process / Analyze: 將資料分析成有意義的資訊，例如 API Top 10、HTTP 5XX、Latency … ETL 有時候會放這裡。
呈現 Visualize / Action: 將分析的資訊，以視覺畫呈現，或者轉換成行動，也就是自動化的發動點。

整理出對應到 CloudWatch 的應用，如下圖：

底下則是 Data Process Pipeline 常見的 Solutions / Tools:

蒐集 Ingest:
- CloudWatch Agent：安裝在 EC2 或者以 Sidecar 形式包成 Docker，負責蒐集 Log 的
- Kinesis Agent for Kinesis Stream, Kinesis Firehose, CloudWatch Logs
- awslogs：舊版的 Log Agent，效能比較不佳
- ETL Solutions: AWS Glue、Xplant
- OSS: Fluentd、Logstash、Beats
- 架構通常會以 Sidecar 形式寄生在主應用程式旁邊。
儲存 Store: CloudWatch Logs
- CloudWatch Logs：存放 Log 資料的服務，屬於 Storage Service，縮寫成 CWL
- OSS: Elasticsearch、InfluxDB、Prometheus
處理 Process / Analyze:
- CloudWatch Filter：分析 CWL 的功能，但只能下簡單的 Filter 條件，複雜的使用
- CloudWatch Logs Insight：分析存放在 CWL 的功能，可以下類似 SQL 的查詢，功能類似
- OSS: Elasticsearch、InfluxDB、Prometheus、Hadoop/Spark Ecosystem.
呈現 Visualize / Action:
- CloudWatch Metric：透過 Filter 或 Insight 產生的 Metric，屬於 Time-Series
- CloudWatch Dashboard：Metric 的集合呈現，一般當作視覺化監視看板使用。
- CloudWatch Alarms：事件驅動的 Event Source，通常會透過 SNS 串接 Lambda 執行實際行為。
- CloudWatch Events / Rules：類似 Cron 的服務，依據條件執行 Schedule Tasks，也是一種 Event Source。
- OSS: Kibana、Grafana

底下是常見的應用場景：

因應類似的需求，整理出以下系列文章：

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