AWS 监控与报警 aws CloudWatch 自动恢复硬件故障实例 Auto Recover

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中的日志功能(收集应用程序日志,并加以统计分析