AWS 監控與報警 aws CloudWatch 自動恢復硬件故障實例 Auto Recover
20180702 Chenxin
常用項目
創建EC2后:
需要添加的報警
主機狀態檢查(主機存活)
CPU利用率
內存使用率(含buffer,cache)
磁盤使用率
並修改"正常,警報,不足(缺失)"時的郵件告知.cloudwatch收集數據時,遇到以下狀態,均配置發送報警郵件:
正常 (實例恢復了)
警報 (實例故障)
不足 (實例異常)
周期盡可能選擇1分鍾,或者更低的監控頻率.cloudwatch反應貌似有些慢,大約需要5分鍾或更長.
賬單的報警
打開"我的賬單控制面板"->"首選項",勾選"接收賬單警報".
使用cloudwatch的賬單報警
在cloudwatch控制台,左側導航頁面的"警報"-"賬單",定義了2個cloudwatch,當此時開銷的估算費用超過2$(和4$)的時候,發送郵件報警.
這里輸入的報警收件人,需要對方接收到aws的確認郵件並手動點擊確認訂閱才會生效,否則狀態一直為"等待狀態".
使用賬單自身功能(應該是比較老的方式,之后可能會全部改用cloudwatch)
另外還有1個可以定義賬單報警的地方(應該是比較老的方式),直接在賬單控制面板的"預算"導航欄,定義當前開銷達到%,或者$時,發出警報(預算20$,達到30%,即6$的時候,發出郵件警報).
加州沒有EC2實例,但為何在創建加州的警報的時候,可在創建的時候看到EC2可以創建48個告警呢?
是否使用cloudwatch的代理模式進行監控,還是直接進行呢?
在弗州創建的EC2報警,其他地區看不到.
EC2磁盤與內存的監控報警(aws的文檔在EC2的文檔里面)
參考: https://docs.aws.amazon.com/zh_cn/AWSEC2/latest/UserGuide/mon-scripts.html
安裝支持插件
yum install -y perl-Switch perl-DateTime perl-Sys-Syslog perl-LWP-Protocol-https
如果您運行的是 Amazon Linux 2，可能還需要安裝 perl-Digest-SHA.x86_64
下載aws提供的perl監控數據收集腳本
cd /opt;
curl https://aws-cloudwatch.s3.amazonaws.com/downloads/CloudWatchMonitoringScripts-1.2.2.zip -O
unzip CloudWatchMonitoringScripts-1.2.2.zip
cd aws-scripts-mon/
cp -aprf awscreds.template awscreds.conf
配置密鑰
進入AWS控制台.IAM>用戶>chenxin>安全證書>創建訪問密鑰.
將密鑰寫入 awscreds.conf
AWSAccessKeyId=XXXXXXXXXXXXXXX
AWSSecretKey=YYYYYYYYYYYYYYYYYY
修改密鑰讀取權限 chmod 600 awscreds.conf
測試:
執行簡單試運行而不將數據發布到 CloudWatch
/opt/aws-scripts-mon/mon-put-instance-data.pl --mem-util --verify --verbose
收集所有可用內存指標並將其發送到 CloudWatch，將緩存和緩沖區內存計為“已用”
/opt/aws-scripts-mon/mon-put-instance-data.pl --mem-used-incl-cache-buff --mem-util --mem-used --mem-avail
啟動磁盤和內存監控報警(可以手動執行)
*/5 * * * * /opt/aws-scripts-mon/mon-put-instance-data.pl --disk-space-util --disk-path=/ --mem-used-incl-cache-buff --mem-util --mem-used --mem-avail --from-cron
最終使用
*/5 * * * * /opt/aws-scripts-mon/mon-put-instance-data.pl --disk-space-util --disk-path=/ --mem-util --mem-used --mem-avail --from-cron
查看監控圖和創建報警
進入控制台CloudWatch>指標Metrics>全部指標>自定義命名空間 Linux System .選中后,點擊"繪成圖表的指標",在"操作"中,有創建報警的圖標.
可以創建1個超標后的報警,以及1個恢復后的"報警"(郵件).
對於缺失數據的處理,可能是因為宕機導致,默認也修改為"超出閥值"動作處理(發送報警).
參數說明
mon-put-instance-data.pl
--verify 不向cloudwatch發送數據,只本地執行腳本
--verbose 顯示腳本執行結果的詳細信息
--from-cron 從 cron 調用腳本時，請使用該選項。使用該選項時，會阻止所有診斷輸出，但錯誤消息會發送到用戶賬戶的本地系統日志。
其他說明:
當我們通過mon-put-instance-data.pl將數據上傳到cloudwatch后,metric生成.如果我們不想要了,是無法手動刪除的,需要cloudwatch經過2周時間,才會不再顯示這個metric.
EC2主機存活報警
官方推薦:
使用EC2控制台的"警報狀態"那列,點擊"創建狀態檢查警報".然后選擇"狀態檢查失敗(任意)",間隔1分鍾.來實現.
創建后,到cloudwatch去修改詳細配置,配置"缺失"數據的處理方式(作為"不良")以及狀態恢復后的郵件告知.
或者(不推薦):
因EC2控制台上的CPU監控(cloudwatch自帶)向cloudwatch發送數據比較快(可能是aws內部監控機制),故主機存活監控,可以采用CPU監控來實現.
而不要采用內存或磁盤的監控報警.
CPU監控對數據缺失默認5分鍾就可以表現在cloudwatch控制台,而內存和磁盤需要10分鍾左右的時間才會顯示"數據缺失".
創建 Amazon CloudWatch 警報(配置)
"對於3 最大3" 的解釋
當用於 3 個數據點的藍線 達到或超過 紅線位於 15 分鍾 范圍內時(1次5分鍾,3次合計15分鍾)，將觸發此警報.這里5分鍾為時間段,15分鍾為評估期,第一個3為觸發警報的數據點個數.
再如,"對於1 最大3": 當用於 1 個數據點的藍線 達到或超過 紅線位於 15 分鍾 范圍內時，將觸發此警報(用於對波動觸發的報警)
說明
- Period (時間段) 是為創建指標的各個數據點而對該指標進行評估的時間長度。它以秒為單位。如果您選擇一分鍾作為時間段，則每分鍾具有一個數據點。
- Evaluation Period (評估期) 是確定警報狀態時要評估的最近數據點的數量。
- Datapoints to Alarm (觸發警報的數據點數) 是評估期內必須超出閾值才能觸發警報進入 ALARM 狀態的數據點數量。超出閾值的數據點不必是連續的，只是必須全部在等於 Evaluation Period (評估期) 的上一個數據點數量之內。
在下圖中，警報閾值設為 3 個單位。警報配置為進入 ALARM 狀態，並且 Evaluation Period (評估期) 和 Datapoints to Alarm (觸發警報的數據點數) 均為 3。也就是說，當最近三個連續時間段內的所有三個數據點均超出閾值時，警報會進入 ALARM 狀態。在該圖中，在第三個到第五個時間段發生了這種情況。在第六個時間段，數值降至閾值以下，因此其中一個時間段被評估為未超出閾值，且警報狀態更改為 OK。在第九個時間段，再次超出閾值，但僅一個時間段超出閾值。因此，警報狀態保持為 OK。
當將 Evaluation Period (評估期) 和 Datapoints to Alarm (觸發警報的數據點數) 配置為不同的值時，您將設置“M out of N”警報。Datapoints to Alarm (觸發警報的數據點數) 為 (“M”)，而 Evaluation Period (評估期) 為 (“N”)。評估間隔是數據點數乘以時間段。例如，如果為 1 分鍾時間段配置 5 個數據點中的 4 個數據點，則評估間隔為 5 分鍾。如果為 10 分鍾時間段配置 3 個數據點中的 3 個數據點，則評估間隔為 30 分鍾。
對於出現硬件故障的實例通過報警觸發"恢復"操作(Auto Recover功能)
參考: https://docs.aws.amazon.com/zh_cn/AWSEC2/latest/UserGuide/UsingAlarmActions.html
限制: 只支持VPC狀態的EC2實例類型.僅用於StatusCheckFailed_System.
恢復操作僅受到以下項支持(截止2019/01/08)：
- C3、C4、C5、M3、M4、M5、R3、R4、T2 和 X1 實例類型
- VPC 中的實例
- 具有 default 或 dedicated 實例租賃的實例
- 僅使用 Amazon EBS 卷的實例（不配置實例存儲卷）
如果實例需要 AWS 參與才能修復的硬件故障，您可自動恢復實例。恢復的實例與原實例相同，包括實例 ID、私有 IP 地址、彈性 IP 地址以及所有實例元數據。
當 StatusCheckFailed_System 警報觸發且恢復操作啟動時，您在創建警報及關聯的恢復操作所選擇的 Amazon SNS 主題將向您發出通知。
在實例恢復過程中，實例將遷移並重啟，且內存中的數據將丟失。當該過程完成后，會向您 SNS 主題發布信息,包括恢復嘗試的狀態以及任何進一步的指示。
您將注意到，實例會在已恢復的實例上重啟。
恢復操作僅適用於 StatusCheckFailed_System，而不能用於 StatusCheckFailed_Instance。
注意:
如果手動stop實例,那么也會觸發該警報,會將該實例進行硬件遷移,並重啟.
配置: 每當: 系統狀態檢查失敗 (StatusCheckFailed_System) 是: >= 1 對於: 3,最大為3 數據點 (注意,默認每個數據點需要5分鍾,3個就是15分鍾)
因為時間過長,可以考慮使用 "對於:2 最大為2"的時間間隔.
在模擬測試的時候,並沒有成功,但有收到aws的郵件提醒(但郵件里並沒有有價值的東西),如下:
We are unable to execute the 'Recover' action on Amazon EC2 instance i-049a34e7aee982e50 that you specified in the Amazon CloudWatch alarm AWS-CLI-TEST-system-check.
You may want to check the alarm configuration to ensure that it is compatible with your instance configuration. You can also attempt to execute the action manually.
These are some possible reasons for this failure and steps you can try to resolve it: ...
EC2 實例狀態，如果是 0/2，說明底層硬件出現故障(最常見的故障)
狀態檢查是1/2，說明底層硬件正常，但是操作系統出現故障.
其他
報警狀態變更會延遲7-8分鍾,什么原因?即便修改為詳細報警模式,也一樣.aws的回答是確實如此.
如何監控自己的應用程序
cloudwatch中的日志功能(收集應用程序日志,並加以統計分析