本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。
为EC2实例和本地服务器配置 CloudWatch 代理
许多组织在物理服务器和虚拟机上运行工作负载(VMs)。这些工作负载通常以不同的方式运行OSs,每个工作负载在捕获和摄取指标方面都有独特的安装和配置要求。
如果您选择使用EC2实例,则可以高度控制您的实例和操作系统配置。但是,这种更高的控制和责任级别要求您监控和调整配置,以实现更高的使用效率。您可以通过建立日志和监控标准以及应用标准的安装和配置方法来捕获和摄取日志和指标,从而提高运营效率。
将 IT 投资迁移或扩展到 AWS 云端的组织可以利用它 CloudWatch 来实现统一的日志和监控解决方案。 CloudWatch 定价意味着您需要为要捕获的指标和日志按增量付费。您还可以使用与 Amazon 类似的 CloudWatch 代理安装过程来捕获本地服务器的日志和指标EC2。
在开始安装和部署之前 CloudWatch,请务必评估系统和应用程序的日志和指标配置。确保为要使用的定义需要捕获OSs的标准日志和指标。系统日志和指标是日志和监控解决方案的基础和标准,因为它们是由操作系统生成的,对于 Linux 和 Windows 来说是不同的。除了特定于 Linux 版本或发行版的指标和日志文件外,Linux 发行版中还提供了重要的指标和日志文件。不同的 Windows 版本之间也会出现这种差异。
配置代 CloudWatch 理
CloudWatch 使用特定于每个操作系统的代理EC2和CloudWatch 代理配置文件捕获 Amazon 和本地服务器的指标和日志。我们建议您在开始在账户中大规模安装 CloudWatch 代理之前,先定义组织的标准指标和日志捕获配置。
您可以组合多个 CloudWatch 代理配置以形成复合 CloudWatch 代理配置。一种推荐的方法是在系统和应用程序级别定义和划分日志和指标的配置。下图说明了如何将满足不同要求的多种 CloudWatch配置文件类型组合成复合 CloudWatch配置:
还可以根据特定的环境或要求对这些日志和指标进行进一步分类和配置。例如,您可以为不受监管的开发环境定义精度较低的较小日志和指标子集,为受监管的生产环境定义更大、更完整且精度更高的日志和指标集。
为EC2实例配置日志捕获
默认情况下,Amazon EC2 不监控或捕获日志文件。取而代之的是,日志文件由安装在您的EC2实例上的 CloudWatch 代理软件捕获并提取到 CloudWatch 日志中 AWS API,或 AWS Command Line Interface (AWS CLI)。我们建议使用 CloudWatch 代理将日志文件采集到 Amazon EC2 和本地服务器的 CloudWatch 日志中。
您可以搜索和筛选日志,也可以提取指标,并根据日志文件中的 CloudWatch模式修补运行自动化。 CloudWatch 支持纯文本、空格分隔以及JSON格式化过滤器和模式语法选项,其中 JSON-格式的日志提供了最大的灵活性。要增加筛选和分析选项,应使用格式化的日志输出而不是纯文本。
CloudWatch 代理使用配置文件来定义要发送到的日志和指标 CloudWatch。 CloudWatch 然后将每个日志文件捕获为日志流,并将这些日志流分组到一个日志组中。这可以帮助您对EC2实例中的日志执行操作,例如搜索匹配的字符串。
默认日志流名称与EC2实例 ID 相同,默认日志组名称与日志文件路径相同。日志流的名称在 CloudWatch 日志组中必须是唯一的。您可以在日志流和日志组名称中使用instance_id
hostname
local_hostname
、、或ip_address
进行动态替换,这意味着您可以在多个EC2实例中使用相同的 CloudWatch 代理配置文件。
下图显示了用于捕获日志的 CloudWatch 代理配置。日志组由捕获的日志文件定义,并且包含每个EC2实例的单独日志流,因为{instance_id}
变量用于日志流名称且EC2实例IDs是唯一的。
日志组定义其所包含的日志流的保留期、标签、安全性、指标筛选器和搜索范围。基于日志文件名的默认分组行为可帮助您搜索和创建指标,并对账户和区域中的EC2实例中特定于日志文件的数据发出警报。您应该评估是否需要进一步细化日志组。例如,您的账户可能由多个业务部门共享,并且拥有不同的技术或运营所有者。这意味着您必须进一步细化日志组名称以反映分离和所有权。这种方法使您可以将分析和故障排除重点放在相关EC2实例上。
如果多个环境使用一个帐户,则可以将每个环境中运行的工作负载的日志记录分开。下表显示了包括业务部门、项目或应用程序以及环境在内的日志组命名惯例。
日志组名称 | /<Business unit>/<Project or application name>/<Environment>/<Log
file name> |
日志流名称 | <EC2 instance ID>
|
您也可以将一个EC2实例的所有日志文件分组到同一个日志组中。这样可以更轻松地在一组日志文件中搜索和分析单个EC2实例。如果您的大多数EC2实例都为一个应用程序或工作负载提供服务,并且每个EC2实例都有特定的用途,则此功能非常有用。下表显示了如何格式化您的日志组和日志流命名以支持这种方法。
日志组名称 | /<Business unit>/<Project or application name>/<Environment>/<EC2
instance ID> |
日志流名称 | <Log file name> |
为EC2实例配置指标捕获
默认情况下,您的EC2实例启用基本监控,并且 CloudWatch 每五分钟自动向其发送一组标准指标(例如CPU,网络或存储相关指标)。 CloudWatch 指标可能因实例系列而异,例如,突发性能实例具有CPU积分指标。Amazon EC2 标准指标包含在您的实例价格中。如果您对EC2实例启用详细监控,则可以在一分钟内接收数据。周期频率会影响您的 CloudWatch成本,因此请务必评估您的所有实例还是仅需要对部分EC2实例进行详细监控。例如,您可以对生产工作负载启用详细监控,但对非生产工作负载使用基本监控。
本地服务器不包含任何默认指标 CloudWatch ,必须使用 CloudWatch 代理 AWS CLI、或 AWS SDK来捕获指标。这意味着您必须在 CloudWatch 配置文件中定义要捕获的指标(例如,CPU利用率)。您可以创建包含本地服务器标准EC2实例指标的唯一 CloudWatch 配置文件,并在标准 CloudWatch 配置之外应用该文件。
中的@@ CloudWatch 指标由指标名称和零个或多个维度进行唯一定义,并且在指标命名空间中进行唯一分组。 AWS 服务提供的指标的命名空间以AWS
(例如AWS/EC2
)开头,非AWS 指标被视为自定义指标。您使用 CloudWatch 代理配置和捕获的指标都被视为自定义指标。由于创建的指标数量会影响您的 CloudWatch 成本,因此您应该评估所有实例还是仅部分EC2实例需要每个指标。例如,您可以为生产工作负载定义一整套指标,但对非生产工作负载使用这些指标的较小子集。
CWAgent
是 CloudWatch 代理发布的指标的默认命名空间。与日志组类似,指标命名空间组织了一组指标,以便可以在一个地方找到它们。您应该修改命名空间以反映业务部门、项目或应用程序以及环境(例如/<Business unit>/<Project or application
name>/<Environment>
)。如果多个不相关的工作负载使用同一个帐户,则此方法很有用。您也可以将命名空间命名约定与 CloudWatch 日志组命名约定相关联。
指标还通过其维度进行标识,这些维度可以帮助您根据一组条件对其进行分析,并且是记录观测值所依据的属性。Amazon EC2 为带有InstanceId
和AutoScalingGroupName
维度的EC2实例提供了单独的指标。如果您启用详细监控,则还会收到带有ImageId
和InstanceType
维度的指标。例如,除了为该InstanceId
维度EC2提供单独的CPU利用率指标外,Amazon 还为CPU使用率提供了单独的EC2InstanceType
实例指标。这可以帮助您分析每个唯一EC2实例的CPU利用率,以及特定EC2实例类型的所有实例。
添加更多维度可以提高您的分析能力,但也会增加总体成本,因为每个指标和唯一的维度值组合都会生成一个新的指标。例如,如果您针对该InstanceId
维度创建内存利用率百分比的指标,则这是每个EC2实例的新指标。如果您的组织运行数千个EC2实例,则会导致成千上万的指标并导致更高的成本。要控制和预测成本,请务必确定指标的基数以及哪些维度增加的价值最大。例如,您可以为生产工作负载指标定义一组完整的维度,但为非生产工作负载定义一小部分维度。
您可以使用该append_dimensions
属性向 CloudWatch 配置中定义的一个或所有指标添加维度。您也可以动态地将ImageId
、InstanceId
、和InstanceType
,附加AutoScalingGroupName
到 CloudWatch 配置中的所有指标。或者,您可以通过使用特定指标的append_dimensions
属性为该指标附加任意维度的名称和值。 CloudWatch 还可以聚合您使用aggregation_dimensions
属性定义的指标维度的统计数据。
例如,您可以聚合该InstanceType
维度所使用的内存,以查看每种实例类型的所有EC2实例使用的平均内存。如果您使用在某个区域中运行的t2.micro
实例,则可以确定使用该t2.micro
类的工作负载是过度利用还是未充分利用所提供的内存。未充分利用可能是工作负载使用具有不必要内存容量的EC2类的迹象。相比之下,过度利用可能是工作负载使用内存不足的 Amazon EC2 类的迹象。
下图显示了使用自定义命名空间、添加的维度和聚合的示例 CloudWatch 指标配置InstanceType
。