Post on 21-Jan-2018
淺談系統監控與
AWS CloudWatch 的應用
Rick HwangAWS User Group Taiwan
Jun 21, 2017
1
田野調查
● 有多少人是開發人員? (開發 Business Logic)● 有多少人負責系統維運、監控、CI/CD?
● 有沒人專職做監控?
● 有人需要值班監控的?
● 有人是自己從開發、測試、維運的?
● 有人是屬於 Leader, PM, Manager?
2
3
● Software Developer, Guitarist● Experiences
○ Technical Manager, 91APP (EC)■ System Operation and Administrator■ Micro Service Team■ IT Infrastructure / MIS
○ Software QA Manager, Oplink Connected (IOT)○ Sr. Software Developer, Shinewave / IBM
● AWS Certifications○ AWS Certifed Solution Architect○ AWS Certifed SysOps Administrator○ AWS Certifed Developers
● Blogs○ Complete Think: https://rickhw.github.io/○ 喝咖啡 聊音樂: https://rickmidi.blogspot.com/
Rick Hwang
4
5
Questions零、服務的 SLA 是多少?
一、如何確認服務是正常的?
二、如何知道現在系統的狀況?
三、要監控哪些指標?
四、異常的通報方式?
6
7
監控的目標SLA: 99.99%
8
SLA: Service Level Agreement● Yearly / Monthly● Uptime● Percentage
9
SLA - by Yearly
10
SLA Downtime Day Hour Min
99% 1% 3.65 87.6 5,256
99.9% 0.1% 0.365 8.76 525.6
99.99% 0.01% 0.0365 0.876 52.56
99.999% 0.001% 0.00365 0.0876 5.256
99.9999% 0.0001% 0.000365 0.00876 0.5256
When Shutdown or Stop the Services ?
● Abnormal● Depoyment● Maintenance● Security Issues● Shutdown the Business
11
監 控12
監 控WatchMonitorObserveMeasure
ControlCommand
HandleManage
13
Dashboard Console
Targets
Commands
Dashboard => Show Something● Health Status● Sum of Biz TX● Sys Resources● …
Push or Pull Data
14
Target Services / Systems
Watchers Controllers
Events(Conditions / Thresholds)
Console => Do Something● Reset or Clean Cache● On / Off Functions● Notification● ...
Feedback(Adjust Conditions / Thresholds by ML)
15
16
一、如何確認服務是正常的?
想像 Launch 一台 EC2 之後,怎麼確定它好了?
17
18
老闆、主管、其他人:現在系統正常嗎?
怎麼確認是正常的?
花多少時間?
Health Check
每個 System or Service 都要有一個方法可以確定狀態
狀態只有三種:
19
● Operator 看得懂,會用
● Tester 看得懂,會用
● Developer 看得懂
● PM 看得懂
● 老闆看的懂
● 老闆的老闆看的懂
● 客戶也看得懂
● 有 API
Health Check … 必須
20
21
Levels of Health Check
● Light / Static Health Check● Layer Health Check● Deep Health Check
22
Levels of Health Check - Example
23
ASG
ELB(Internet-Facing)
Route 53
Web App
ASG
Web Servers ELB(Internal ELB)
App ServersThird PartyServices
Health-Checker
Light Health CheckLayer Health CheckDeep Health Check
Service A
Service B
Levels of Health Check
24
● Light / Static Health Check○ Application 自己是正常的, 像是: Tomcat, IIS 正常運作
● Layer Health Check○ App 跟另一個 App 溝通是正常的, Tomcat to Redis○ 出問題時,釐清問題的節點
● Deep Health Check○ 確認 Service 自身的商務邏輯是正常的:登入、結帳
25
Service A Service B
Service CService D
Service E(Third Party)
Service Dependencies (Internal)
Levels of Health Check
26
● Light / Static Health Check - Application Self● Layer Health Check - App to App● Deep Health Check: Service Self● Service Health Check: Service to Services
● 開發好的應用程式,交給其他單位 (Test、Operation) 部署時
,用來確認部署正確性、確認點
● CD 時可以自測
● 跨很多系統時,釐清問題的基本參考點,特別是 Micro Service 架構
Health Check 的用途
27
Health Check 的設計
28
● Levels of Health Check: Light/Static, Layer, Deep● 把 Health Check 設計成 API,增加可測性
○ ElasticSearch Health● 提供每個 Request Unique MessageId,每個 Role 都要有
Health API、有 Test / Fake Mode● 釐清 Third Party 的依賴性,重要的服務要納入 Health
Check 範圍
Recap
29
● 東西能動就好了,什麼叫能動?
● 如何定義 Health Check?● 從哪一些層面切入?
● 如何設計 Health Check?
30
二、如何知道現在服務的狀況
31
此時此刻
你正在參加 AWS User Group怎麼知道現在系統的狀況?你現在可以知道哪些資訊?
用什麼方式?
32
33Dashboard(侏羅紀公園 )
● Operator:你、我
● Developer:你、我
● PM / 業務 / 老闆:
○ 系統正常嗎?
○ 現在流量多少?
○ 線上多少人?
○ 訂單成立多少?
34
需要知道監控資訊的人
● 透過 Dashboard○ 值班人員需要有電腦
○ Dashboard 可能資訊太多
○ Dashboard 要開電腦
● 可不可用手機取得系統狀況?○ Health Check○ Key Metrics
35
取得監控資訊的方式
36
Static Health Check Layer Health Check ELB Info
37
CloudWatch Reporter
CloudWatchReporter / Alamer
CloudWatch Event (time-based)
Channels by Services
Operators
Operators
Developers
Metric Configs(Namespace, Stats)
Target Services
Loading
maintain
Commit
Read CW Metrics
Schedule
maintain
Developers
development
Feature Request / PR
Urgent, Warning, Info
Urgent, Warning, Info
Urgent
CloudWatch Reporter - Design Principle● 隨時可以知道系統的狀況 - Mobile / Slack● 監控指標的設定很容易使用,Operator 不需特別學習
● 監控指標的設定要能夠版控、進 GIT、Issue Tracking● 監控系統的功能與設定個別由 Deveoper & Operator 負責
○ 職權分離,Dev & Ops○ Operator 可以 Open PR or Feature Request to Developer
● 監控系統本身容易部署與維護
● 監控系統本身是 High Available,不需要監控
● 監控系統的成本要很低
38
Recap
39
● 如何隨時掌握系統資訊?
● 誰需要這樣的資訊?
● 這系統放哪?
● 資訊跟 Health Check 的關係?
40
41
三、監控哪些指標?
怎麼知道哪些?指標從哪來?
42
EC2 CloudWatch Metrics
43
ELB/ALB CloudWatch Metrics
44
如果我想要看的指標CloudWatch 沒有怎麼辦?
我想知道: Nginx Connection Avarage
45
我想知道:系統的 TCP Connection Status
46
我想知道:HTTP and HTTPS 的狀況
47
我想知道:Nginx HTTP 2XX, 3XX, 4XX Requests
48
49
希望這些指標是即時的
CloudWatch Custom Metrics
50
aws cloudwatch put-metric-data \ --metric-name mem \ --namespace /CWL-Demo/App \ --unit Percent --value 23 \ --dimensions InstanceId=1-23456789,InstanceType=t2.small
● 兩個常見的需求○ EC2 Memory Utilization○ EC2 Disk Utilization
● How○ AWS CLI / SDK: put-metric-data○ AWS CloudWatch Logs○ Third Party Agents:
■ Collected■ Telegraf
怎麼知道有哪一些指標?這些指標從哪來的?
51
52http://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html
為什麼 ALB 會有這些指標?怎麼知道要看這些?
哪來的?
53
系統測試、效能測試
54
系統測試
55
經過系統測試之後,發現、定義的數據與資訊,最後會轉化成監
控指標。這些數據與資訊包含商業資訊、系統性資訊等。
● 系統測試時發現,需要注意 Quene Task 的資訊,像是 Sum of Producing、Sum of Quene、Sum of Consuming
● 監控重要機器:特定 EC2 被關機的時候,透過 CloudWatch Event 觸發 Actions● 商務邏輯指標:線上人數、即時交易量、購物車排隊數量 ...
56
CloudWatch Events
經過效能測試之後,發現、定義的系統性數據與資訊。
● JVM Heap Size● TCP Connections● Surge Quene - ELB
效能測試
57
58Source: http://booklook.morningstar.com.tw/pdf/0139022.pdf
健檢報告的指標,都是經過無數臨床經驗 (監控) 與科學實驗 (測試) 得來的。
59
監控指標跟山一樣多
整理 - 監控哪些指標
60
● CloudWatch 提供的指標
● CloudWatch 沒有提供的指標 - Custom Metrics● 探索未知的指標,包含系統性、商業性
○ 系統是動態的 (Auto Scaling Group),指標也是動態的。
● 指標會跟山一樣多,需要管理與分類
61
分類監控指標的層級
62
Business (EC, IoT, Backing)
Login / LogonShopping CarUser SessionsDevice Sessions
Invention / StockeDM / SMSPushShipping QTY
GAGMVROITracking
Application Servers / Services
Tomcat / IISNginx / HAProxyRDBMS / NoSQL
JVM Heap SizeNode.jsTask QueueSQS / Kafaka
Cache / CDNHTTP RequestsHTTP 4XXs / 5XXsLB Latency
System / Virtual Machine
CPU UtilizationsDisk I/O Disk IOPS / Throughput
Network I/OMemory UtilizationsDisk Usage
CPU CreditSystem CheckInstance Check
NetworkInfrastructureAAA
NAT GatewayNetwork ACLFirewall
AD/DCLDAPIAM
DNSSSL
Level of Metrics
BossManagers
DevelopersDBA, Arch
OperatorsAdministrators
Network Security
這些監控數據放哪?需要多大的儲存空間?
放存放多久?花多少成本?老闆買單?
大數據?Hadoop?Spark?EMR?
WxF ...63
大數據!?Hadoop?Spark?
64
更多成本!
如果監控系統掛了?監控的系統的 SLA?監控系統需要的成本?怎麼教育訓練其他同事?找人怎麼找?JD 怎麼寫?
JD 寫出來了,薪水怎麼開?出的起香蕉只能請到猴子。。。
65
About Monitor System● 監控系統也是系統,需要有 HA / Reliability、自己的 SLA● 『監控指標』從哪來?需要開發程式蒐集
● 誰來『監控』監控系統?
● 在商業模式還沒成功之前 (賺錢),監控系統能用就好。
● 監控系統架構再怎麼漂亮,沒有監控到異常,就 GG 了。
● 監控系統是需要付出成本的:費用、人力。
● 監控系統的目的是發現異常、讓系統更穩定,不是大數據。
● 監控是一件困難、複雜的事情
66
67
68
其實,Monitor 也可以很容易
CloudWatch Logs
69
● CloudWatch Alarms● CloudWatch Dashboard● CloudWatch Logs● CloudWatch Filters● CloudWatch Metrics● CloudWatch Events an Rules
AWS CloudWatch
70
Features● Monitor Logs from Amazon EC2 Instances in Real-time● Monitor AWS CloudTrail Logged Events● Archive Log Data
Related AWS Services● Cloudtrail● IAM● Kinesis Streams● Lambda
71
CloudWatch Logs
Source: http://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html
72
CloudWatch Logs● 可以直接儲存 Log Data,不用管理與維護,用多少付多少
● 可以在 Console 查詢 Log,支援 json, csv 格式○ 不用擔心查詢資料量太大,機器會掛掉
● 可以設定 Retention 時間,或者永久保存
● 可以將查詢的條件 (Filter) 存成監控指標 (Metric)○ 以 Dashboard 呈現
○ 作為 Alarms 報警
○ 可程式化
73
EC2 Instancesawslogs driver
Logs
Log Groups
Log Stream A
Log Stream B
Log Stream C
Log Stream N
Alarms
Filters
[ts, hostname, scope=NGX, tcp_all, tcp_time_wait, tcp_established, ...]
/var/log/app/*.log
2017-06-11T08:45:01 app1 NGX 47 0 47 0 0 02017-06-11T08:45:01 app2 NGX 52 0 52 0 0 02017-06-11T08:46:01 app1 NGX 53 0 52 0 0 02017-06-11T08:46:01 app2 NGX 52 0 51 0 0 02017-06-11T08:47:01 app1 NGX 53 0 53 0 0 02017-06-11T08:47:01 app2 NGX 53 0 53 0 0 02017-06-11T08:48:01 app1 NGX 59 0 59 0 0 02017-06-11T08:48:01 app2 NGX 52 0 51 0 0 02017-06-11T08:49:01 app1 NGX 48 0 48 0 0 0
Dashboard
Metrics
S3
Amazon ESLambda
SNS Topics
Export
Streaming
Push
74
CloudWatch Logs - Workflow● 規劃 Log 的目錄結構,與 Log Groups / Log Streams
○ 要跟 Developer 溝通,不要產出沒有結構化的 Log○ 可以放商業邏輯相關的資訊,做為統計
● 在需要蒐集 Log 的機器安裝 awslogs driver● 建立 Metric Filters● 建立 Dashboard or Alarms● 串接 SNS / Lambda
Example - Monitor EC2 TCP States● 寫 Script 蒐集 TCP States● 每分鐘取樣一次 TCP States● 透過 awslogs 把數據傳到
CloudWatch Logs○ Log Groups: /CWL-Demo/Worker○ Log Streams: TcpState
● 設定 Metric Filter,產生 Custom Metric
75
Source: https://en.wikipedia.org/wiki/Transmission_Control_Protocol
An Script to Sample TCP States
76
#!/bin/sh
ts=$(date +%Y-%m-%dT%H:%M:%S)logts=$(date +%Y%m%d)all_tcp_log="/var/log/tcp/${logts}.log"
# tcp for all socketstcp_all=$(netstat -pt | wc -l)tcp_time_wait=$(netstat -at | grep TIME_WAIT | wc -l)tcp_established=$(netstat -at | grep ESTABLISHED | wc -l)tcp_fin_wait1=$(netstat -at | grep FIN_WAIT1 | wc -l)tcp_fin_wait2=$(netstat -at | grep FIN_WAIT2 | wc -l)tcp_close_wait=$(netstat -at | grep CLOSE_WAIT | wc -l)
echo "$ts `hostname` SYS $tcp_all $tcp_time_wait $tcp_established $tcp_fin_wait1 $tcp_fin_wait2 $tcp_close_wait" >> $all_tcp_log
1. 每分鐘跑一次 2. 放在 /var/log/tcp/{date}.log
CloudWatch Log - awslogs.conf## awslogs config[general]state_file = /var/awslogs/state/agent-state
[/var/log]file = /var/log/tcp/*.loglog_group_name = /CWL-Demo/Workerlog_stream_name = TcpLogdatetime_format = %Y-%m-%dT%H:%M:%S%ztime_zone = UTC
77
1. 存到 s3://<bucket_name>/awslogs.conf2. Make as Public3. 注意時間格式與 timezone
## Install awslogsAWS_REGION=us-east-1BUCKET_NAME=cwl-demo
cd /tmpcurl https://s3.amazonaws.com/aws-cloudwatch/downloads/latest/awslogs-agent-setup.py -Ochmod +x ./awslogs-agent-setup.py./awslogs-agent-setup.py -n -r ${AWS_REGION} -c https://s3.amazonaws.com/${BUCKET_NAME}/awslogs.conf
CloudWatch Log - awslogs driver installation
78
確認:1. /var/awslogs/etc/awslogs.conf 有沒有設定檔,沒有可以手動加2. 檢查 Log 有沒有異常: /var/log/awslogs.log 3. 確認有 IAM 權限,可以先用 CloudWatchLogsFullAccess4. 正常會依據 awslogs.conf 產生 Log Groups, Log Streams
Log Groups, Log Streams
79
FILER_PATTERN="[ts, hostname, scope=ALL, tcp_all, tcp_time_wait, tcp_established, tcp_fin_wait1, tcp_fin_wait2, tcp_close_wait]"
# 建立 Metric Filter & Custom Metricaws logs put-metric-filter \ --log-group-name "/CWL-Demo/App" \ --filter-name "TCP-ALL" \ --filter-pattern "${FILER_PATTERN}" \ --metric-transformations metricName=TCP-All,metricNamespace=CWL-Demo/TCP,metricValue=\$tcp_all,defaultValue=0.0
CloudWatch Metric with AWS CLI
80
CloudWatch Metric with AWS Console
81
CloudWatch Metric with AWS Console
82
83
Metric Filter
[ts, hostname, scope=SYS, tcp_all, tcp_time_wait, tcp_established, tcp_fin_wait1, tcp_fin_wait2, tcp_close_wait]
CloudWatch Custom Metrics
84
85
CloudWatch Dashboard
CloudWatch Alarms
86
Metric Filter
[ts, hostname, scope=SYS, tcp_all, ….
Alarms
Recap: CloudWatch Logs, Filters, Metric, Alarms
87
EC2 Instancesawslogs driver
Logs
Log Groups
Log Stream A
Log Stream B
Log Stream C
Log Stream N
Alarms
Filters
/var/log/app/*.log
2017-06-11T08:45:01 app1 NGX 47 0 47 0 0 02017-06-11T08:45:01 app2 NGX 52 0 52 0 0 02017-06-11T08:46:01 app1 NGX 53 0 52 0 0 02017-06-11T08:46:01 app2 NGX 52 0 51 0 0 02017-06-11T08:47:01 app1 NGX 53 0 53 0 0 02017-06-11T08:47:01 app2 NGX 53 0 53 0 0 02017-06-11T08:48:01 app1 NGX 59 0 59 0 0 02017-06-11T08:48:01 app2 NGX 52 0 51 0 0 02017-06-11T08:49:01 app1 NGX 48 0 48 0 0 0
Dashboard
Metrics SNS Topics
Push
88
Business (EC, IoT, Backing)
Login / LogonShopping CarUser SessionsDevice Sessions
Invention / StockeDM / SMSPushShipping QTY
GAGMVROITracking
Application Servers / Services
Tomcat / IISNginx / HAProxyRDBMS / NoSQL
JVM Heap SizeNode.jsTask QueueSQS / Kafaka
Cache / CDNHTTP RequestsHTTP 4XXs / 5XXsLB Latency
System / Virtual Machine
CPU UtilizationsDisk I/O Disk IOPS / Throughput
Network I/OMemory UtilizationsDisk Usage
CPU CreditSystem CheckInstance Check
NetworkInfrastructureAAA
NAT GatewayNetwork ACLFirewall
AD/DCLDAPIAM
DNSSSL
Level of Metrics
BossManagers
DevelopersDBA, Arch
OperatorsAdministrators
Network Security
Log 的規劃
89
● 思考要監控哪一些指標、資訊,寫 Log 時就要想清楚
● Log 的資料結構關係到 Filter (Query) 怎麼下,以及呈現資訊的完整性
● 規劃 Log Groups, Log Stream, 還有 Metrics
Recap● 結構化系統的 Log,留下有意義的資訊
● 用 CloudWatch Logs 取代 put-metric 方法
● 把指標分層級,也做分工
● 找到服務的特徵值
● 『大數據』是行銷要用詞,不要隨便亂跳
90
補充:CloudWatch Logs - Filter events
91查 Auto Scaling Group 機器的 Log 很好用!
補充:CloudTrail to CloudCloud Logs
92
補充:CloudTrail to CloudCloud Logs
93
94
95
四、異常通報
異常通報常見的問題
● False Alarm (誤報)● 輕重緩急不分
● 找錯人 → 造成無形的溝通成本
● 狼來了現象 → 最後沒人看○ 訊息太多
○ Email / 推播塞爆了 ○ False Alarm
● 通知方式紊亂
● 權責不分
96
異常通報的維度
● 異常的等級
● 通報的方式
● 通報的對象
97
98
等級:國家級方法:手機訊息插播、警報聲對象:全國公民
異常通報的等級
99
戒備狀態 - 美國國家防禦等級
100
Source: https://zh.wikipedia.org/zh-tw/%E6%88%92%E5%A4%87%E7%8A%B6%E6%80%81
101超級戰艦 Battleship 2012
Log Level - bunyan (node.js)
102
https://github.com/trentm/node-bunyan#levels
Log Level - Log4j (java)
103
https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/Level.html
異常通報等級的定義
104
● Info:一般資訊 - CloudWatch Reporter ⇒ 要知道,但有空再看 ⇒ Operator○ 突然一根 HTTP 4XX, 5XX
● Warning:請留意系統狀況 ⇒ 要有人知道、留意到 ⇒ Operator、Developer○ Sum Request 比平常大 50%○ HTTP 4XX 持續三十分鐘,平均 CPU 增加了 30%○ Latency > 5000ms 持續 1 分鐘
● Urgent:馬上要處理 ⇒ 一定要找到人處理 ⇒ PM、老闆、全公司○ 系統沒反應了
○ Latency > 5000ms 持續 5 分鐘
異常通報的等級與 Health Check
105
異常通報的方法
106
異常通報的方法
107
以下是常見的通報方法
● Email● Mobile Push ($)● Slack ($) / Telegram / Line ($)● SMS ($$)● Voice Call ($$$)
容易因洗版而被忽略
不會被洗版、容易抓到人需要成本、HA
異常通報的等級 x 方法 x 對象
108
等級 方法 對象 案例
Info EmailIM: Slack
Operators 隨選資訊、Reporter
Warning IM: Slack、Telegram Operators、Developers 線上活動資源到臨界值
Urgent IM: SlackSMSVoice Call
Operators、DevelopersManagers
系統異常、服務中斷
異常通報系統的設計
● 高可用
● 免維護
● 容易測試與開發
● 容易管理與配置
109
EC2
CloudWatch Alarms
Operators
CloudWatch Event (time-based)
SNS-Adapter
Slack-Notifier
SNS TopicInfo, Warning
Info
Developers
Health-Checker
Auto Scaling
SNS TopicUrgent SMS
Warning
異常通報系統:CloudWatch + Lambda + Slack
● Urgent: SMS, Slack● Warning: Slack● Info 110
Voice Call
111
Recap零、服務的 SLA 是多少?
一、如何確認服務是正常的?
二、如何知道現在系統的狀況?
三、要監控哪些指標?
四、異常的通報方式?
112
Commands
Dashboard => Show Something● Health Status● Sum of Biz TX● Sys Resources● …
Push or Pull Data
113
Target Services / Systems
Watchers Controllers
Events(Conditions / Thresholds)
Console => Do Something● Reset or Clean Cache● On / Off Functions● Notification● ...
Feedback(Adjust Conditions / Thresholds by ML)
Health Check
每個 System or Service 都要有一個方法可以確定狀態
狀態只有三種:
114
115
Business (EC, IoT, Backing)
Login / LogonShopping CarUser SessionsDevice Sessions
Invention / StockeDM / SMSPushShipping QTY
GAGMVROITracking
Application Servers / Services
Tomcat / IISNginx / HAProxyRDBMS / NoSQL
JVM Heap SizeNode.jsTask QueueSQS / Kafaka
Cache / CDNHTTP RequestsHTTP 4XXs / 5XXsLB Latency
System / Virtual Machine
CPU UtilizationsDisk I/O Disk IOPS / Throughput
Network I/OMemory UtilizationsDisk Usage
CPU CreditSystem CheckInstance Check
NetworkInfrastructureAAA
NAT GatewayNetwork ACLFirewall
AD/DCLDAPIAM
DNSSSL
Level of Metrics
BossManagers
DevelopersDBA, Arch
OperatorsAdministrators
Network Security
異常通報的等級 x 方法 x 對象
116
等級 方法 對象 案例
Info EmailIM: Slack
Operators 隨選資訊、Reporter
Warning IM: Slack、Telegram Operators、Developers 線上活動資源到臨界值
Urgent IM: SlackSMSVoice Call
Operators、DevelopersManagers
系統異常、服務中斷
Modern Solutions for System Monitor
117
● ELK: Elasticsearch + Logstash + Kibana● Collected + CloudWatch => 可以取代 Cacti / Nagios● Telegraf + InfluxDB + Grafrana● Fluentd + Prometheus + Grafana● 不要再 Google 下去了,很恐怖
這些工具都要養機器、花錢、監控 (鬼打牆)
有 Ecosystem Know How 要學習
Why AWS CloudWatch?● 可以滿足大部分系統監控的需求
● 部署 awslogs driver 與配置 metrics 簡單
● 不需要自己管理監控系統,不需要擔心監控系統自己會掛掉
● 不需要擔心 Log 儲存空間的問題,或者機器運算成本
● 可以自行定義 Metric、串接 Alarm● 可以 Metric / Alarm 管理與配置可程式化、進版控 (git)● CloudWatch Log + Metric + Alarm 搭配 SNS + Lambda 效果奇佳!
118
When?當有數百台機器要監控
橫跨數個 AWS Regions、數個 VPC 要監控的時候
資源是動態的 (Auto Scaling Group)
自己蓋 ELK 、或者裝 Cacti、Nagios 、InfluxDB …
這些機器掛掉的時候、效能不足要升級的時候 …
想想 Rick 講過的 CloudWatch …
119
CloudWatch 的不足 (許願池)● Dashboard 不能像 Grafana 那樣 configurable,然後分享給社群。
○ Grafana Dashboard 是一個 json file. ⇒ Grafana Community Dashboard
● 資料無法做複雜的 Aggregate ,像是 group by 之後做 order by,算出時間範圍
的 Top 10 API Latency,Kibana 可以做。
● Filter History 不能存起來,每次都要重新敲
● 無法搭配 Athena + QuickSight 應用
● CloudWatch Log 可以 export to S3,但是要透過 Event Rule 排程設定
● CloudWatch Log export to S3 的目錄結構不是結構化,回不來了○ Athena 讀的資料要結構化過,才會省錢
120
簡報內容構思與緣由
● Study Notes - CloudWatch
● AWS Certified SysOps Administrator - Associate 準備心得
121
參考資料
● Amazon CloudWatch Documentation● AWS re:Invent 2014: Amazon CloudWatch Deep Dive● AWS re:Invent 2016: From Monolithic to Microservices● Deep Health Check Pattern● SRE: How Google Runs Production Systems
122
Related AWS Services
123
● CloudWatch Logs, Metrics, Filters, Events, Roles● CloudTrail / CloudFormation● IAM● CLI / SDK● Lambda● SNS● EC2 / ELB
124