2017/06/21, AWS User Group Taiwan https://rickhw.github.io/2017/06/21/AWS/Stategies-System-Monitor_and_CloudWatch/

1. 淺談系統監控
與
AWS CloudWatch 的應用
Rick Hwang
AWS User Group Taiwan
Jun 21, 2017
1

2. 田野調查
● 有多少人是開發人員？ (開發 Business Logic)
● 有多少人負責系統維運、監控、CI/CD？
● 有沒人專職做監控？
● 有人需要值班監控的？
● 有人是自己從開發、測試、維運的？
● 有人是屬於 Leader, PM, Manager？
2

3. 3

4. ● 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. 5

6. Questions
零、服務的 SLA 是多少？
一、如何確認服務是正常的？
二、如何知道現在系統的狀況？
三、要監控哪些指標？
四、異常的通報方式？
6

7. 7

8. 監控的目標
SLA: 99.99%
8

9. SLA: Service Level Agreement
● Yearly / Monthly
● Uptime
● Percentage
9

10. 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

11. When Shutdown or Stop the Services ?
● Abnormal
● Depoyment
● Maintenance
● Security Issues
● Shutdown the Business
11

12. 監 控
12

13. 監 控
Watch
Monitor
Observe
Measure
Control
Command
Handle
Manage
13
Dashboard Console
Targets

14. 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. 15

16. 16
一、如何確認服務是正常的？

17. 想像 Launch 一台 EC2 之後，怎麼確定它好了？
17

18. 18
老闆、主管、其他人：現在系統正常嗎？
怎麼確認是正常的？
花多少時間？

19. Health Check
每個 System or Service 都要有一個方法可以確定狀態
狀態只有三種：
19

20. ● Operator 看得懂，會用
● Tester 看得懂，會用
● Developer 看得懂
● PM 看得懂
● 老闆看的懂
● 老闆的老闆看的懂
● 客戶也看得懂
● 有 API
Health Check … 必須
20

21. 21

22. Levels of Health Check
● Light / Static Health Check
● Layer Health Check
● Deep Health Check
22

23. Levels of Health Check - Example
23
ASG
ELB
(Internet-Facing)
Route 53
Web App
ASG
Web Servers ELB
(Internal ELB)
App ServersThird Party
Services
Health-Checker
Light Health Check
Layer Health Check
Deep Health Check
Service A
Service B

24. 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. 25
Service A Service B
Service C
Service D
Service E
(Third Party)
Service Dependencies (Internal)

26. 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

27. ● 開發好的應用程式，交給其他單位 (Test、Operation) 部署時
，用來確認部署正確性、確認點
● CD 時可以自測
● 跨很多系統時，釐清問題的基本參考點，特別是 Micro
Service 架構
Health Check 的用途
27

28. 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 範圍

29. Recap
29
● 東西能動就好了，什麼叫能動？
● 如何定義 Health Check？
● 從哪一些層面切入？
● 如何設計 Health Check？

30. 30

31. 二、如何知道現在服務的狀況
31
此時此刻

32. 你正在參加 AWS User Group
怎麼知道現在系統的狀況？
你現在可以知道哪些資訊？
用什麼方式？
32

33. 33Dashboard
(侏羅紀公園)

34. ● Operator：你、我
● Developer：你、我
● PM / 業務 / 老闆：
○ 系統正常嗎？
○ 現在流量多少？
○ 線上多少人？
○ 訂單成立多少？
34
需要知道監控資訊的人

35. ● 透過 Dashboard
○ 值班人員需要有電腦
○ Dashboard 可能資訊太多
○ Dashboard 要開電腦
● 可不可用手機取得系統狀況？
○ Health Check
○ Key Metrics
35
取得監控資訊的方式

36. 36
Static Health Check Layer Health Check ELB Info

37. 37
CloudWatch Reporter
CloudWatch
Reporter / 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

38. 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

39. Recap
39
● 如何隨時掌握系統資訊？
● 誰需要這樣的資訊？
● 這系統放哪？
● 資訊跟 Health Check 的關係？

40. 40

41. 41
三、監控哪些指標？
怎麼知道哪些？指標從哪來？

42. 42
EC2 CloudWatch Metrics

43. 43
ELB/ALB CloudWatch Metrics

44. 44
如果我想要看的指標
CloudWatch 沒有怎麼辦？

45. 我想知道： Nginx Connection Avarage
45

46. 我想知道：系統的 TCP Connection Status
46

47. 我想知道：HTTP and HTTPS 的狀況
47

48. 我想知道：Nginx HTTP 2XX, 3XX, 4XX Requests
48

49. 49
希望這些指標是即時的

50. 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. 怎麼知道有哪一些指標？
這些指標從哪來的？
51

52. 52http://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html

53. 為什麼 ALB 會有這些指標？
怎麼知道要看這些？
哪來的？
53

54. 系統測試、效能測試
54

55. 系統測試
55
經過系統測試之後，發現、定義的數據與資訊，最後會轉化成監
控指標。這些數據與資訊包含商業資訊、系統性資訊等。
● 系統測試時發現，需要注意 Quene Task 的資訊，像是 Sum of Producing、Sum
of Quene、Sum of Consuming
● 監控重要機器：特定 EC2 被關機的時候，透過 CloudWatch Event 觸發 Actions
● 商務邏輯指標：線上人數、即時交易量、購物車排隊數量 ...

56. 56
CloudWatch Events

57. 經過效能測試之後，發現、定義的系統性數據與資訊。
● JVM Heap Size
● TCP Connections
● Surge Quene - ELB
效能測試
57

58. 58Source: http://booklook.morningstar.com.tw/pdf/0139022.pdf
健檢報告的指標，都是經過無數 臨床經驗 (監控)
與科學實驗 (測試) 得來的。

59. 59
監控指標跟山一樣多

60. 整理 - 監控哪些指標
60
● CloudWatch 提供的指標
● CloudWatch 沒有提供的指標 - Custom Metrics
● 探索未知的指標，包含系統性、商業性
○ 系統是動態的 (Auto Scaling Group)，指標也是動態的。
● 指標會跟山一樣多，需要管理與分類

61. 61
分類監控指標的層級

62. 62
Business
(EC, IoT, Backing)
Login / Logon
Shopping Car
User Sessions
Device Sessions
Invention / Stock
eDM / SMS
Push
Shipping QTY
GA
GMV
ROI
Tracking
Application
Servers /
Services
Tomcat / IIS
Nginx / HAProxy
RDBMS / NoSQL
JVM Heap Size
Node.js
Task Queue
SQS / Kafaka
Cache / CDN
HTTP Requests
HTTP 4XXs / 5XXs
LB Latency
System /
Virtual
Machine
CPU Utilizations
Disk I/O
Disk IOPS / Throughput
Network I/O
Memory Utilizations
Disk Usage
CPU Credit
System Check
Instance Check
Network
Infrastructure
AAA
NAT Gateway
Network ACL
Firewall
AD/DC
LDAP
IAM
DNS
SSL
Level of Metrics
Boss
Managers
Developers
DBA, Arch
Operators
Administrators
Network
Security

63. 這些監控數據放哪？
需要多大的儲存空間？
放存放多久？
花多少成本？老闆買單？
大數據？Hadoop？
Spark？EMR?
WxF ...
63

64. 大數據！？Hadoop？Spark？
64
更多成本！

65. 如果監控系統掛了？
監控的系統的 SLA？
監控系統需要的成本？
怎麼教育訓練其他同事？
找人怎麼找？JD 怎麼寫？
JD 寫出來了，薪水怎麼開？
出的起香蕉只能請到猴子。。。
65

66. About Monitor System
● 監控系統也是系統，需要有 HA / Reliability、自己的 SLA
● 『監控指標』從哪來？需要開發程式蒐集
● 誰來『監控』監控系統？
● 在商業模式還沒成功之前 (賺錢)，監控系統能用就好。
● 監控系統架構再怎麼漂亮，沒有監控到異常，就 GG 了。
● 監控系統是需要付出成本的：費用、人力。
● 監控系統的目的是發現異常、讓系統更穩定，不是大數據。
● 監控是一件困難、複雜的事情
66

67. 67

68. 68
其實，Monitor 也可以很容易

69. CloudWatch Logs
69

70. ● CloudWatch Alarms
● CloudWatch Dashboard
● CloudWatch Logs
● CloudWatch Filters
● CloudWatch Metrics
● CloudWatch Events an Rules
AWS CloudWatch
70

71. 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. 72
CloudWatch Logs
● 可以直接儲存 Log Data，不用管理與維護，用多少付多少
● 可以在 Console 查詢 Log，支援 json, csv 格式
○ 不用擔心查詢資料量太大，機器會掛掉
● 可以設定 Retention 時間，或者永久保存
● 可以將查詢的條件 (Filter) 存成監控指標 (Metric)
○ 以 Dashboard 呈現
○ 作為 Alarms 報警
○ 可程式化

73. 73
EC2 Instances
awslogs 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 0
2017-06-11T08:45:01 app2 NGX 52 0 52 0 0 0
2017-06-11T08:46:01 app1 NGX 53 0 52 0 0 0
2017-06-11T08:46:01 app2 NGX 52 0 51 0 0 0
2017-06-11T08:47:01 app1 NGX 53 0 53 0 0 0
2017-06-11T08:47:01 app2 NGX 53 0 53 0 0 0
2017-06-11T08:48:01 app1 NGX 59 0 59 0 0 0
2017-06-11T08:48:01 app2 NGX 52 0 51 0 0 0
2017-06-11T08:49:01 app1 NGX 48 0 48 0 0 0
Dashboard
Metrics
S3
Amazon ESLambda
SNS Topics
Export
Streaming
Push

74. 74
CloudWatch Logs - Workflow
● 規劃 Log 的目錄結構，與 Log Groups / Log Streams
○ 要跟 Developer 溝通，不要產出沒有結構化的 Log
○ 可以放商業邏輯相關的資訊，做為統計
● 在需要蒐集 Log 的機器安裝 awslogs driver
● 建立 Metric Filters
● 建立 Dashboard or Alarms
● 串接 SNS / Lambda

75. 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

76. 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 sockets
tcp_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

77. CloudWatch Log - awslogs.conf
## awslogs config
[general]
state_file = /var/awslogs/state/agent-state
[/var/log]
file = /var/log/tcp/*.log
log_group_name = /CWL-Demo/Worker
log_stream_name = TcpLog
datetime_format = %Y-%m-%dT%H:%M:%S%z
time_zone = UTC
77
1. 存到 s3://<bucket_name>/awslogs.conf
2. Make as Public
3. 注意時間格式與 timezone

78. ## Install awslogs
AWS_REGION=us-east-1
BUCKET_NAME=cwl-demo
cd /tmp
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 ${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 權限，可以先用 CloudWatchLogsFullAccess
4. 正常會依據 awslogs.conf 產生 Log Groups, Log Streams

79. Log Groups, Log Streams
79

80. 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 Metric
aws 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

81. CloudWatch Metric with AWS Console
81

82. CloudWatch Metric with AWS Console
82

83. 83
Metric Filter
[ts, hostname, scope=SYS, tcp_all, tcp_time_wait, tcp_established, tcp_fin_wait1, tcp_fin_wait2, tcp_close_wait]

84. CloudWatch Custom Metrics
84

85. 85
CloudWatch Dashboard

86. CloudWatch Alarms
86
Metric Filter
[ts, hostname, scope=SYS, tcp_all, ….
Alarms

87. Recap: CloudWatch Logs, Filters, Metric, Alarms
87
EC2 Instances
awslogs 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 0
2017-06-11T08:45:01 app2 NGX 52 0 52 0 0 0
2017-06-11T08:46:01 app1 NGX 53 0 52 0 0 0
2017-06-11T08:46:01 app2 NGX 52 0 51 0 0 0
2017-06-11T08:47:01 app1 NGX 53 0 53 0 0 0
2017-06-11T08:47:01 app2 NGX 53 0 53 0 0 0
2017-06-11T08:48:01 app1 NGX 59 0 59 0 0 0
2017-06-11T08:48:01 app2 NGX 52 0 51 0 0 0
2017-06-11T08:49:01 app1 NGX 48 0 48 0 0 0
Dashboard
Metrics SNS Topics
Push

88. 88
Business
(EC, IoT, Backing)
Login / Logon
Shopping Car
User Sessions
Device Sessions
Invention / Stock
eDM / SMS
Push
Shipping QTY
GA
GMV
ROI
Tracking
Application
Servers /
Services
Tomcat / IIS
Nginx / HAProxy
RDBMS / NoSQL
JVM Heap Size
Node.js
Task Queue
SQS / Kafaka
Cache / CDN
HTTP Requests
HTTP 4XXs / 5XXs
LB Latency
System /
Virtual
Machine
CPU Utilizations
Disk I/O
Disk IOPS / Throughput
Network I/O
Memory Utilizations
Disk Usage
CPU Credit
System Check
Instance Check
Network
Infrastructure
AAA
NAT Gateway
Network ACL
Firewall
AD/DC
LDAP
IAM
DNS
SSL
Level of Metrics
Boss
Managers
Developers
DBA, Arch
Operators
Administrators
Network
Security

89. Log 的規劃
89
● 思考要監控哪一些指標、資訊，寫 Log 時就要想清楚
● Log 的資料結構關係到 Filter (Query) 怎麼下，以及呈現資訊的完整性
● 規劃 Log Groups, Log Stream, 還有 Metrics

90. Recap
● 結構化系統的 Log，留下有意義的資訊
● 用 CloudWatch Logs 取代 put-metric 方法
● 把指標分層級，也做分工
● 找到服務的特徵值
● 『大數據』是行銷要用詞，不要隨便亂跳
90

91. 補充：CloudWatch Logs - Filter events
91
查 Auto Scaling Group 機器的 Log 很好用！

92. 補充：CloudTrail to CloudCloud Logs
92

93. 補充：CloudTrail to CloudCloud Logs
93

94. 94

95. 95
四、異常通報

96. 異常通報常見的問題
● False Alarm (誤報)
● 輕重緩急不分
● 找錯人 → 造成無形的溝通成本
● 狼來了現象 → 最後沒人看
○ 訊息太多
○ Email / 推播塞爆了
○ False Alarm
● 通知方式紊亂
● 權責不分
96

97. 異常通報的維度
● 異常的等級
● 通報的方式
● 通報的對象
97

98. 98
等級：國家級
方法：手機訊息插播、警報聲
對象：全國公民

99. 異常通報的等級
99

100. 戒備狀態 - 美國國家防禦等級
100
Source: https://zh.wikipedia.org/zh-tw/%E6%88%92%E5%A4%87%E7%8A%B6%E6%80%81

101. 101
超級戰艦 Battleship 2012

102. Log Level - bunyan (node.js)
102
https://github.com/trentm/node-bunyan#levels

103. Log Level - Log4j (java)
103
https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/Level.html

104. 異常通報等級的定義
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 分鐘

105. 異常通報的等級與 Health Check
105

106. 異常通報的方法
106

107. 異常通報的方法
107
以下是常見的通報方法
● Email
● Mobile Push ($)
● Slack ($) / Telegram / Line ($)
● SMS ($$)
● Voice Call ($$$)
容易因洗版
而被忽略
不會被洗版、容易抓到人
需要成本、HA

108. 異常通報的等級 x 方法 x 對象
108
等級 方法 對象 案例
Info Email
IM: Slack
Operators 隨選資訊、Reporter
Warning IM: Slack、Telegram Operators、Developers 線上活動
資源到臨界值
Urgent IM: Slack
SMS
Voice Call
Operators、Developers
Managers
系統異常、服務中斷

109. 異常通報系統的設計
● 高可用
● 免維護
● 容易測試與開發
● 容易管理與配置
109

110. EC2
CloudWatch Alarms
Operators
CloudWatch Event
(time-based)
SNS-Adapter
Slack-Notifier
SNS Topic
Info, Warning
Info
Developers
Health-Checker
Auto Scaling
SNS Topic
Urgent SMS
Warning
異常通報系統：CloudWatch + Lambda + Slack
● Urgent: SMS, Slack
● Warning: Slack
● Info 110
Voice Call

111. 111

112. Recap
零、服務的 SLA 是多少？
一、如何確認服務是正常的？
二、如何知道現在系統的狀況？
三、要監控哪些指標？
四、異常的通報方式？
112

113. 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)

114. Health Check
每個 System or Service 都要有一個方法可以確定狀態
狀態只有三種：
114

115. 115
Business
(EC, IoT, Backing)
Login / Logon
Shopping Car
User Sessions
Device Sessions
Invention / Stock
eDM / SMS
Push
Shipping QTY
GA
GMV
ROI
Tracking
Application
Servers /
Services
Tomcat / IIS
Nginx / HAProxy
RDBMS / NoSQL
JVM Heap Size
Node.js
Task Queue
SQS / Kafaka
Cache / CDN
HTTP Requests
HTTP 4XXs / 5XXs
LB Latency
System /
Virtual
Machine
CPU Utilizations
Disk I/O
Disk IOPS / Throughput
Network I/O
Memory Utilizations
Disk Usage
CPU Credit
System Check
Instance Check
Network
Infrastructure
AAA
NAT Gateway
Network ACL
Firewall
AD/DC
LDAP
IAM
DNS
SSL
Level of Metrics
Boss
Managers
Developers
DBA, Arch
Operators
Administrators
Network
Security

116. 異常通報的等級 x 方法 x 對象
116
等級 方法 對象 案例
Info Email
IM: Slack
Operators 隨選資訊、Reporter
Warning IM: Slack、Telegram Operators、Developers 線上活動
資源到臨界值
Urgent IM: Slack
SMS
Voice Call
Operators、Developers
Managers
系統異常、服務中斷

117. Modern Solutions for System Monitor
117
● ELK: Elasticsearch + Logstash + Kibana
● Collected + CloudWatch => 可以取代 Cacti / Nagios
● Telegraf + InfluxDB + Grafrana
● Fluentd + Prometheus + Grafana
● 不要再 Google 下去了，很恐怖
這些工具都要養機器、花錢、監控 (鬼打牆)
有 Ecosystem Know How 要學習

118. Why AWS CloudWatch？
● 可以滿足大部分系統監控的需求
● 部署 awslogs driver 與配置 metrics 簡單
● 不需要自己管理監控系統，不需要擔心監控系統自己會掛掉
● 不需要擔心 Log 儲存空間的問題，或者機器運算成本
● 可以自行定義 Metric、串接 Alarm
● 可以 Metric / Alarm 管理與配置可程式化、進版控 (git)
● CloudWatch Log + Metric + Alarm 搭配 SNS + Lambda 效果奇佳！
118

119. When?
當有數百台機器要監控
橫跨數個 AWS Regions、數個 VPC 要監控的時候
資源是動態的 (Auto Scaling Group)
自己蓋 ELK 、或者裝 Cacti、Nagios 、InfluxDB …
這些機器掛掉的時候、效能不足要升級的時候 …
想想 Rick 講過的 CloudWatch …
119

120. 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

121. 簡報內容構思與緣由
● Study Notes - CloudWatch
● AWS Certified SysOps Administrator - Associate 準備心得
121

122. 參考資料
● 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

123. Related AWS Services
123
● CloudWatch Logs, Metrics, Filters, Events, Roles
● CloudTrail / CloudFormation
● IAM
● CLI / SDK
● Lambda
● SNS
● EC2 / ELB

124. 124