一、前言
1、背景
AWS对EC2的监控通过Cloudwatch在虚拟化层完成，也就是KVM的Hypervisor层完成。这一层，只能看到CPU占用率、磁盘IO、网络流入流出等数据，不能看到虚拟机Guest OS层面的数据。例如看不到内存使用率，看不到C盘使用率，系统进程数等。为了打开系统级监控，需要安装Cloudwatch的agent。如下图为监控效果。
Cloudwatch支持的各种AWS服务清单在这里。Cloudwatch除了支持AWS上的监控，也支持客户on-premise数据中心内安装agent进行统一监控。
2、多种安装模式
命令行安装。最常见的安装方式，是SSH登录到命令行上，从EC2的ssh环境中下载安装包，并执行安装配置。参考文档在这里。
System Manager 安装。当虚拟机数量较多，存在批量更新、资产管理、合规要求的时候，使用System Manager就是个很好的选择。System Manager还可以发起over-ride网络安全组的session（更类似VNC Console但不是物理console）直接对虚拟机操作。System Manager可以远程批量部署软件包，当然就也可以发起对Cloudwatch的安装命令。参考文档在这里。
Cloudformation 安装。CloudFormation用于资源的编排管理，特别适合快速部署一整套实验环境的上线。参考文档在这里。
本文将使用最传统的第一种方式：命令行安装。安装完毕后，可以把这个虚拟机转换为镜像即AMI上，后续创建新的EC2可以直接使用。
3、多种采集监控模式
实现监控采集主要有通过CLI发布或者通过Agent发布两种。
AWS CLI向Cloudwatch发布自定义数据。这种配置方式，是在EC2内部安装AWS CLI，设置好API Access Key，然后直接运行aws cloudwatch put命令上传数据。周期性的上传，可以把这条命令加入到Crontab中实现。实现文档在这里。
通过Agent采集特定规格的数据。这种发布方式，是在agent内具有一系列特定的模块实现特定数据采集，然后通过agent将采集过来的数据发布出去。局限：如果agent内没有提供现成module的数据就采集不到了。不过不用担心，官方提供的采集module很全，这些指标足以支撑大部分运维场景。详细清单参考这里。如下截图是清单中的CPU部分。
此外，Agent也可以进一步做应用层面的采集，参考这里。
Agent还支持其他系统来的数据汇总，参考这里。
以上是背景知识，了解下就可以，跳过以上背景知识也可以，按照如下方法配置。
二、安装并设置Agent
前边提到了，用CLI可以直接向Cloudwatch发布自定义数据。本文不使用这种方法，而是使用Cloudwatch Agent内标准的采集功能。
1、配置IAM角色
Cloudwatch Agent访问模式是直接从EC2上把采集到的数据传输到Cloudwatch，全过程不使用AWS CLI命令行，因此在对应的EC2上无需安装CLI工具，也无需写入Access Key。那么，在安装软件前，需要在IAM上赋予正确的权限。
设置IAM有一个注意点，1个虚拟机只能绑定1个IAM Profile。在此前的文章中我们提到，通过IAM Profile给EC2授权，让EC2无需密码可以写入特定S3 Bucket。这种方式就是将EC2绑定了特定的IAM Profile。那么问题来了，如果这个EC2已经绑定了别的IAM Profile，那么就不能再更换了，否则别的系统就会缺少权限不运行了。由此，需要查清楚EC2当前使用的IAM Role，或者给当前IAM Role基础上增加Policy，或者新建一个Role，但是把刚才那个Role带有的Policy都一个不少的补充进来。
如下截图，查看下当前在使用的IAM Profile。
从EC2的IAM Profile里边，看好了是哪一个Role正在生效之后，要给这个Role增加一个Policy。
例如，查询当前EC2，已经在使用名为lxy-cwagent-demo的role了，接下来要给这个role补充一个权限，即CloudWatchAgentAdminPolicy这个Policy。如下截图。
这个Policy名字叫做CloudWatchAgentAdminPolicy，虽然听着很吓人名字带着admin，但是不是一个权限很大的policy，不具有破坏效果。我们来review下它的内容。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"cloudwatch:PutMetricData",
"ec2:DescribeTags",
"logs:PutLogEvents",
"logs:DescribeLogStreams",
"logs:DescribeLogGroups",
"logs:CreateLogStream",
"logs:CreateLogGroup"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ssm:GetParameter",
"ssm:PutParameter"
],
"Resource": "arn:aws:ssm:*:*:parameter/AmazonCloudWatch-*"
}
]
}通过以上JSON可以看出，我们给EC2实例正在使用的Role附加了一个名为CloudWatchAgentAdminPolicy的Policy，这个Policy本身定义就是查询和写入日志，是比较人畜无害的，而不是想象的名字上戴着admin就具有了删除权限。
在配置过程中，如果仔细看IAM的Policy中名字包含CloudWatch的搜索结果的话，除了这个CloudWatchAgentAdminPolicy之外，还有一个Policy叫做CloudWatchAgentServerPolicy 。这个Policy和CloudWatchAgentAdminPolicy是高度的相似的。为了调查他们，我们可以在IAM界面上，直接启动JSON方式的Editor浏览具体的权限参数。
对比后发现二者区别在于，CloudWatchAgentAdminPolicy在Action部分比CloudWatchAgentServerPolicy多处了一个PutParameter的权限。而恰巧，我们通过Cloudwatch Agent上传监控数据，就是一个PutParameter行为。那么由此得出结论，IAM里边预定义的CloudWatchAgentServerPolicy这个Policy是用于一般的EC2读取数据的，不是用来发布和写入数据的。为了配置IAM Role用于上传监控数据，我们必须使用CloudWatchAgentAdminPolicy附加到当前EC2正在使用的Role上。另外，我们也确认了这个名字上包含有admin关键字的权限不会产生过大的风险。
至此IAM Role添加完成。如下截图。
最后一步是把EC2绑定上刚才设置好的这个Role。千万记得，别配置了半天，忘记绑定了。如下截图。选择好新的Role。
步骤1的IAM准备完成。
2、安装
要开始安装Agent了。首先从官网下载。官网的网址在这里。
下载到EC2上。
执行 rpm -ivh 安装。
rpm -ivh amazon-cloudwatch-agent.rpm安装完成后，进入/opt/aws/amazon-cloudwatch-agent/bin目录。如下截图。
这里可以看到有一个配置向导，叫做“amazon-cloudwatch-agent-config-wizard”，这是在AWS官方文档中被推荐的。
这个配置向导走完之后，会生成一个config.json文件，保存在/opt/aws/amazon-cloudwatch-agent/bin目录下。但是，这个配置程序并不会把配置文件放到conf目录下。此外，配置向导配置的内容比较长比较复杂，我们这里将使用自己定义的一个配置文件。
3、配置
从rpm新安装好之后，默认配置文件在这里。（这个文件无扩展名）
/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.d/default配置文件default的替换为我们要植入和采集的参数，具体如下。
{
"agent": {
"metrics_collection_interval": 60,
"run_as_user": "cwagent"
},
"metrics": {
"metrics_collected": {
"mem": {
"measurement": [
"mem_used_percent"
]
},
"disk": {
"measurement": [
"used_percent"
],
"resources": [
"*"
]
},
"diskio": {
"measurement": [
"io_time"
],
"metrics_collection_interval": 30,
"resources": [
"*"
]
},
"netstat": {
"measurement": [
"tcp_established",
"tcp_syn_sent",
"tcp_close"
],
"metrics_collection_interval": 60
}
},
"namespace": "LinuxOS",
"append_dimensions": {
"ImageId": "${aws:ImageId}",
"InstanceId": "${aws:InstanceId}",
"InstanceType": "${aws:InstanceType}",
"AutoScalingGroupName": "${aws:AutoScalingGroupName}"
}
}
}
这里大部分内容都是不能调整的，是Cloudwatch Agent的模版和预定义参数。如果想调整监控项目，参考这里的文档。
4、自定义Namespace
AWS官方文档上对如何自定义Namespace写的很含糊，只说这是一个optional可选的参数。定义Namespace的文档描述在这里。这篇文档和上边那一篇参考资料是同一篇，只是一个网页的不同标签和分节。
新安装好的环境上，default配置文件里边是没有namespace的。这个参数的default值叫做“CWagent”。如果不人为指定这个值，直接启动CloudWatch的Agent开始向Cloudwatch传输数据，是可以正常工作的。但在CloudWatch的图形界面上，采集的参数将被归类到Customized Namespace下名为“CWagent”的分组内。这就让很多有强迫症的人不舒服了，我一定要自己定义一个Namespace。或者按照多个业务定义多个namespace。
如上一章节给出的完整配置文件中，Namespace定义取名为“LinuxOS”，配置完成后我们就会在Cloudwatch的界面上看到这个名字。
修改配置文件过程中注意，大部分参数建议都是用60秒的间隔。低于60秒采集间隔的叫做高精度函数，参考这里。改好配置文件后，保存退出。
5、重启服务
执行如下命令，停止服务。
/opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -m ec2 -a stop执行如下命令，启动服务。
/opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -m ec2 -a start6、查看日志
服务启动前，建议另外开辟一个窗口，执行tail命令查看日志输出，查看日志情况。命令如下。
tail -f /opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log执行结果如下。如下截图是配置OK的情况的正常输出。截图中mem、netstat、disk、diskio都是配置正常被加载进来的module。如果配置文件某一个section错误，那么对应的模块就load不进来。所以对比加载模块，可以快速定位是否配置正确。
如果配置有不正确的话，就会在日志中看到具体的报错，例如配置文件格式错误，没有权限写入等报错信息。
例如，如果报告如下错误：
ec2tagger: Unable to initialize EC2 Instance Tags : +UnauthorizedOperation: You are not authorized to perform this operation.一般可能的原因是EC2的IAM Profile设置不正确，没有绑定正确的Policy。错误代码如下截图中红色框的部分。
提供正确的IAM后，问题解决。综上所述，看Log对于排错非常重要，配置完成后先看log，无报错后再继续。
三、查看监控数据
以上Agent的配置文件设置完毕，且启动后日志没有报错后，就可以来Cloudwatch查看监控数据了。从Console上进入Cloudwatch的主界面。如下截图。
点击Metrics进入后，从右侧下方可以看到所谓的“Namespace”。Cloudwatch不安装Agent情况下，监控的hypervisor一层的信息都属于“AWS Namespace”，安装了Agent后的监控数据，属于Custom Namespace。在上述配置文件中，我们定义的名字“LinuxOS”就在这里。如下截图。
接下来从Namespace LinuxOS中，进一步选取要看的参数，点击某一个分组，如下截图。
展开参数集之后，前边是要看的EC2实例名字，后边是要看的参数名。选中他们，就可以在图表上投射出来数据。下图中橘色的曲线是因为刚配置好，所有没有历史数据，就从配置好的那一刻生效。
接下来就可以把这些图表加入自己定制的dashboard了，结合应用的特点展现自己需要的指标。
定制dashboard方法主要是console上的GUI图形界面操作，本文就不再描述了，参考这里的文档。
四、小结
本文讲述了如何配置Cloudwatch Agent实现Guest OS层面的数据采集。Cloudwatch Agent还有更多丰富功能，可进一步挖掘。