Study Notes - CloudWatch Core Functions


CloudWatch 是學習 AWS 之後,除了 EC2、S3 之外,最重要的 Services 之一,本文整理 CloudWatch 主要的功能介紹。


核心功能

CloudWatch Agent (取代 awslogs)

新一代的 Log Ingest Agent,以 golang 重寫,整合 SSM,同時支援 Linux & Windows。

— 待整理 —

詳細參閱:CloudWatch Agent with AWS Systems Manager Integration – Unified Metrics & Log Collection for Linux & Windows

awslogs (python)

Log 蒐集部分,需要在 EC2 Instance 安裝 agent,底下是快速安裝:

1
2
3
curl https://s3.amazonaws.com/aws-cloudwatch/downloads/latest/awslogs-agent-setup.py -O
chmod +x ./awslogs-agent-setup.py
./awslogs-agent-setup.py -n -r ap-northeast-1 -c s3://<bucket-name>/awslogs.conf

記得先在 s3 放一個 config 檔,或者直接執行安裝檔。

安裝好 awslogs agent,然後設定 Filename Pattern、Time Format、Log Group、Log Stream … 等,就會自動把 Log 傳到 CloudWatch Log,詳細設定:CloudWatch Logs Agent Reference

底下是我蒐集 syslog + nginx 設定例子:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
# see: http://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AgentReference.html
[general]
state_file = /var/awslogs/state/agent-state

[/var/log/syslog]
file = /var/log/syslog
log_group_name = /Worker/SysLog
log_stream_name = {instance_id}_{hostname}
datetime_format = %b %d %H:%M:%S

[/var/log/nginx/log]
file = /var/log/nginx/*.log
log_group_name = /Worker/Nginx
log_stream_name = AccessLog
datetime_format = %Y-%m-%dT%H:%M:%S%z
time_zone = UTC

配置 awslogs agent 要注意看 awslogs 自己的 log,確認他的解析是正確的。awslogs 的 log 放在 /var/log/awslogs.log

Windows 則可以透過 Ec2Config 或者 SSM Windows 自身提供的 Event Logs、Performance Monitoring,或者其他應用程式的 Log ,像是 IIS、 SQLServer 等,傳上去 CloudWatch Log。詳細參閱 Using CloudWatch Logs with Amazon EC2 Running Microsoft Windows Server

CloudWatch Logs

CloudWatch 除了自身提供的 Metric / Alarm ,也可以把自己 Application 的 Log 丟上來、儲存,然後設定 Filter 進行分析,變成 Metric,最後用 Alarm + Rule 驅動事件。

CloudWatch Metrics

Metrics 可以說成 監控指標項目, AWS 各個服務預設很多監控指標,可以在 CloudWatch 上看到相關數據,也可以透過 AWS CLI or SDK 取得數據。要取得 CloudWatch 資料,就要先了解 CloudWatch Metrics 的設計與資料結構:

  • Namespaces: Metrics 的容器 (Container), 就是用來分類 AWS 服務的, 用 slash / 區隔. 像是 AWS/EC2, AWS/DynamoDB. 詳細參閱 AWS Namespaces.
  • Metrics: 意思是 度量, 是一個時間軸 (time-base) 的資料集合. 像是 ELB 的 HealthyHostCount, RequestCount, SurgeQueueLength 都叫做 Metrics.
  • Dimensions: 量測的資源對象 (ARN),是 Key/Value 呈現,像是 Name=InstanceId,Value=${INSTANCE_ID}, Name=LoadBalancerName,Value=${ARN_ID}
  • Statistics: 時間範圍之內的統計方式,包含了:Sum, Minimum, Maximum, and SampleCount.

Metric Filter

Metric Filter 是 CloudWatch Log 中重要的功能,透過 Metric Filter 可以定義自己的 Metric,進而變成 Alarm 或者呈現 Dashboard,他有點像是 ELK 的 Logstash 的角色,主要就是把欄位做對應以及過濾。

底下是我透過 AWS CLI 建立 Metric Filter 處理 Nginx Log 的例子:

1
2
3
4
5
6
7
8
9
10
FILTER_NAME="Connection-Request_Filter"

# 過濾 local health check
FILER_PATTERN="[time_iso8601, remote_user, status, body_bytes_sent, http_referer, server_name != 127.0.0.1, upstream_addr, request, request_length, http_user_agent, remote_addr, proxy_protocol_addr, http_x_forwarded_for, proxy_add_x_forwarded_for, request_time, http_host, scheme, msec, connection, connection_requests, connections_active, connections_reading, connections_writing, connections_waiting]"

aws logs put-metric-filter \
--log-group-name "${LOG_GROUP_NAME}" \
--filter-name "${FILTER_NAME}" \
--filter-pattern "${FILER_PATTERN}" \
--metric-transformations metricName=Connection-Active,metricNamespace=Nginx/Connection-Request,metricValue=1,defaultValue=0.0

如果上傳的 Log 是 JSON,Metric Filter 也支援,他的寫法大概長得像這樣:

這是查詢 Cloudtrail Event 的 Metric Filter:有人開了 *.8xlarge or *.4xlarge 的機器

1
{ ($.eventName = RunInstances) && (($.requestParameters.instanceType = *.8xlarge) || ($.requestParameters.instanceType = *.4xlarge)) }

Custom Metrics

有一些資訊 CloudWatch 本身是不提供的,像是 EC2 Instance 的記憶體、磁碟使用空間 (Disk Usage Percent),或者是自己的 Application Servers 像是 Nginx、Tomcat、IIS、Node.js … 需要監控這些 Servers 的相關數據,像是 Nginx 的記憶體使用例、Connection Request、Tomcat 的 JVM HeapSize … 等。那麼就要自行蒐集相關資料、儲存這些資料。

參考:Monitoring Memory and Disk Metrics for Amazon EC2 Linux Instances

如果是要從自己的 Log 分析出相關資訊,就要透過 CloudWatch Log + Filter 建立自己的 Metric,同樣的這也是 Custom Metrics。像 Nginx or JVM HeapSize 就可以這樣做。

使用 Custom Metrics 要注意怎麼設計 Namespaces, Dimensions,例如依照機器角色分 Namespace,依照角色 Metric 分 Dimension,依照商業邏輯把相關的放一起,日後好整理。

Custom Metrics 不能透過 AWS Console or CLI 刪除,只能等它自己慢慢消失 ..

取得 Metrics 的 DataPoint

有時候需要自行分析 CloudWatch Metric 的數據,或者重新 Aggregation ,例如:

計算一群機器的平均 CPU Utilization,然後平均之後決定是否驅動事件,像是透過 SNS 通知

以下是用 AWS CLI 透過 crontab 固定取得 metric 的例子。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
AWS_PROFILE="<<AWS-PROFILE>>"
INSTANCE_ID="<<EC2-INSTNACE-ID>>"
AWS_REGION="ap-northeast-1"
OUTPUT_TYPE="text"
period=300

# Calculate local time as UTC, there is local time -8 = UTC. my server is local time (UTC+8).
start_time=`date +'%Y-%m-%dT%H:%M:00' --date='-8 hour -10 min'`
end_time=`date +'%Y-%m-%dT%H:%M:00' --date='-8 hour'`

aws cloudwatch get-metric-statistics \
--metric-name CPUUtilization \
--start-time ${start_time} \
--end-time ${end_time} \
--period ${period} \
--namespace AWS/EC2 \
--statistics Average \
--dimensions Name=InstanceId,Value=${INSTANCE_ID} \
--output ${OUTPUT_TYPE} \
--region ${AWS_REGION} \
--profile ${AWS_PROFILE}

Return as text

1
2
3
CPUUtilization
DATAPOINTS 30.24 2016-07-11T06:00:00Z Percent
DATAPOINTS 34.034 2016-07-11T06:05:00Z Percent

Return as json:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
{
"Datapoints": [
{
"Timestamp": "2016-07-11T06:00:00Z",
"Average": 30.240000000000002,
"Unit": "Percent"
},
{
"Timestamp": "2016-07-11T06:05:00Z",
"Average": 34.034000000000006,
"Unit": "Percent"
}
],
"Label": "CPUUtilization"
}

這邊要去深入了解每個 Unit, Statistics 以及 Period 等意義是什麼,才能計算出需要的東西。

處理統計資料,通常要過濾很多不必要的資訊,AWS CLI 可以配合 JEMSPath 找到要的欄位,透過 --query 過濾不必要的資訊,詳細參閱 Ops as Code with AWS CLI 的例子。

CloudWatch Logs Insights

2018/11/27 AWS re:Invent 發表。

透過查詢語言,聚合複雜的查詢內容。

— 待整理 —

詳細參閱:New – Amazon CloudWatch Logs Insights – Fast, Interactive Log Analytics

CloudWatch Dashboard

  • 自行定義 Dashboard,也就是把很多圖放在同一個畫面,版面配置可以自行調整大小。
  • 資訊是即時的 (1-2 分鐘的時間差)
  • 並且自動更新。同時可以設定時間範圍
  • 支援 Local Time。
  • 支援 export / import as JSON,也可以程式化、版控、分享 Dashboard 的設定。2017/07/05: New – API & CloudFormation Support for Amazon CloudWatch Dashboards

非常實用的功能!

缺點:

  • 圖形支援的還不夠多

成本:一個 Dashboard 每個月三塊美金。

Metric Math

多個 Metric 可以用數學函示即時計算出另一個 Metric。詳細參閱:

— 待整理 —

CloudWatch Alarms

使用 AWS 剛開始都會用到的,主要目的:

  • 就針對特定的監控指標
  • 設定告警的條件
  • 通知或者說驅動一個事件

最常見的例子:

  • 設定監控指標:CPU Utilization
  • 告警條件:五分鐘之內,持續 2 次,平均值超過 80%
  • 發動 SNS 事件
    • 發 Email 給一個群組
    • 送簡訊 (SMS) 給 1-n 個人
    • 執行 1-N 個 Lambda

這是非常經典的例子。

使用 Alarms 要知道幾個重要的觀念,包含 Namespaces, Metric Name, Statistics, Unit, Period … 後面 Metric 詳細描述。


其他功能

CloudWatch Events / Rules

主要用來事件驅動 (Event Driven) 的原點,像是 CloudWatch Alarms 發生時,驅動 Lambda 做一件事情。也可以利用固定的排程 (crontab) 做固定的事情,像是每天固定幾點做什麼事情,或者固定每 10 分鐘做一件事情。這樣事件驅動叫做 CloudWatch Event,觸發的每個規則稱為 CloudWatch Rule

這些都可以透過 CLI or SDK 做設定,所以很容易開發。

事件驅動了來源有很多地方,CloudWatch Rule 基本的就有:

  • Schedule: Cron 的方式,或者是固定的時間驅動
  • CloudWatch Events: 配合 AWS Service 的 Action,像是:
    • 當某些重要的 EC2 狀態變成 stopped or shutting-down
      • 驅動一個 Lambda,通知 ooxx
      • 同時 Reboot 自己
    • 有東西放到 S3 就去跑 Lambda …
    • 支援東西很多,像是 EC2, EC2 SSM, ECS, EMR, Auto Scaling, API Call, CodeDeploy, KMS … 等等

在做系統監控的時候,常常需要知道現在的系統狀況,但是身邊也不見得隨時都會有電腦,因為這樣的需求所以我設計了 CloudWatch Reporter,透過 CloudWatch Event Rule ,定期把資訊丟到 Slack,讓大家隨時可以掌握系統狀況。

實作很簡單,就是寫一個 Lambda Function 撈 CloudWatch 時間範圍的資料,做簡單計算,組 Slack Payload,丟 Slack。

CloudWatch 相關的服務

CloudWatch 跟很多東西都有關係,以下整理一些東西:

  • Cloudtrail:可以把 Cloudtrail event 倒進去 CloudWatch Log ,透過官方提供的 CloudFormation 可以自動建立所有的 Metric Filer / Alarm,可以監控不正常的 AWS Event
  • Elasticsearch:可以直接 Log 倒入 AWS ES,但我不太喜歡養機器 … 即使 AWS ES 宣稱是 Managed …
  • Lambda:串接 CloudWatch Rules,最常用的組合,配合 Slack 口味不錯。
  • SNS:同上
  • VPC Flow Log:用來分析網路流量,參閱 Migrate to AWS NAT GatewayLambda Network Traffic Test in VPC w/ or w/o Endpoint 的分享。
  • Kineses Firehose: 串流 Log,讓 Log 落地到 S3 或者與其他資料分析。
  • Auto Scaling / SQS / SES / SWF / DynamoDB / RDS … 幾乎都會跟 CloudWatch 有關。
  • 把 ELB Log 倒入 CloudWatch Log 分析:

延伸閱讀

系列文章

站內延伸

參考資料

更新紀錄


Comments