使用Cloudwatch Agent监控系统运行情况

一、前言

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 start

6、查看日志

服务启动前,建议另外开辟一个窗口,执行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还有更多丰富功能,可进一步挖掘。