Tag: Amazon CloudWatch


全新 – Amazon CloudWatch 高精度自定义指标和警报

Amazon CloudWatch 自 2009 年年初以来一直是 AWS 的重要组成部分。CloudWatch 与 Auto ScalingElastic Load Balancing 三个产品包组合在一起发布,它已发展成为功能极强、面向 AWS 云中运行的 AWS 资源和应用程序的监控服务。CloudWatch 自定义指标 (早在 2011 年发布) 可用在 CloudWatch 中存储业务和应用程序指标、以图形方式查看这些指标,并基于 CloudWatch 警报启动操作。不用说,这些年来,我们的 CloudWatch 增强了很多的功能!最近的一些增强功能包括延长指标保留期 (以及一项用户界面更新)、控制面板控制面板 API/CloudFormation 支持以及控制面板上的警报

一开始,指标是按照五分钟的时间间隔存储的;后来,在 2010 年,应客户请求缩短到一分钟 (也称为详细监控)。这是一个广受欢迎的改变,但现在我们可以做得更好。我们的客户在流式传输视频、开展限时抢购、每天上百次部署代码,并随着情况的变化非常快速地扩展和缩减应用程序。对于所有这些情况,一分钟为时间间隔还是太长了。这样有可能错过重要的瞬间高峰;分散 (然而事实上相关) 的事件难以跨越时间进行关联,并且在发生故障时的 MTTR (平均修复时间) 过高。

全新的高精度指标
今天,我们将增加对高精度自定义指标的支持,我们还计划以后逐渐增加对 AWS 服务的支持。现在您的应用程序可以以 1 秒的精度将指标发布到 CloudWatch。在发布指标数秒后您就可以在屏幕上滚动查看这些指标,您还可以设置高精度 CloudWatch 警报,可以精细到每 10 秒评估一次。

想象一下可用内存较少时发出警报。这通常是一种瞬时的情况,如果取样不够频繁,将很难捕获到。使用高精度指标,您可以在数秒内查看、检测 (通过警报) 到这种情况并相应地执行操作。

在此例中,右侧的警报不会触发,您也不会知道出现了问题。

发布高精度指标
您可以用两种不同的方式发布高精度指标:

  • APIPutMetricData 函数现在接受可选 StorageResolution 参数。将此参数设置为 1 可发布高精度指标;省略它 (或设置为 60) 可按照标准的 1 分钟精度发布指标。
  • collectd 插件 – collectd 的 CloudWatch 插件已更新,现在支持高精度指标的收集和发布。您需要在该插件的配置文件中设置 enable_high_definition_metrics 参数。

CloudWatch 指标随时间累积;随着指标存在时间变长,精度将大大降低。下面是时间设置:

  • 1 秒指标可用 3 小时。
  • 60 秒指标可用 15 天。
  • 5 分钟指标可用 63 天。
  • 1 小时指标可用 455 天 (15 个月)。

当您调用 GetMetricStatistics 时,可以指定 1、5、10、30 或 60 秒的任意倍数作为高精度指标。您可以指定 60 秒的任意倍数作为标准指标。

快速演示
我选用我最近的 EC2 实例,它安装了最新版本的 collectd 和 Python 插件:

$ sudo yum install collectd collectd-python

然后我下载该插件的设置脚本,让它变成可执行文件,然后运行:

$ wget https://raw.githubusercontent.com/awslabs/collectd-cloudwatch/master/src/setup.py
$ chmod a+x setup.py
$ sudo ./setup.py

我已创建一个合适的 IAM 角色,并将它添加到我的实例中;在设置过程中自动检测到了它。有人要求我启用高精度指标:

collectd 在数秒内开始运行并发布指标。我打开 CloudWatch 控制台查看:

然后我放大,详细查看指标:

我还以 10 秒的时间间隔创建一个警报来检查 memory.percent.used 指标。这样我可以更方便地检测短时间内使用很多内存的情况:

现在提供
现在,高精度自定义指标和警报在所有公共 AWS 区域都可用,并且很快还会支持 AWS GovCloud (US)

目前您每个月可以免费存储 10 个指标;有关更多信息,请参阅 CloudWatch 定价页面。高精度指标的定价与标准精度指标相同,如果需要使用更多指标,用量套餐可以为您节省费用 (对于每个指标)。高精度警报价格为每月每个警报 0.30 美元。

新功能- Collectd的Amazon CloudWatch插件

原文:https://aws.amazon.com/blogs/aws/new-cloudwatch-plugin-for-collectd/

作者:Jeff Barr


我在2011年已介绍过Cloud Watch的特性,“您可以在Cloud Watch中查看图表、设置告警、并根据这些指标启动自动化操作,所使用的这些AWS资源指标会被存储于Cloud Watch中 。”您目前已有能力在Amazon Cloud Watch中存储一段时间范围内的业务、应用及系统的指标数据(参阅“Amazon Cloud Watch定制新指标”了解更多信息)。

今天我们将简化系统统计信息的采集过程,使用一个新的 CloudWatch plug for colletd将采集数据发送至CloudWatch中 。并通过collectd 多种类型信息的统计采集能力与cloudwatch存储、展示、警报和告警的功能的整合,您可以更好地获取EC2实例、本地硬件以及运行于其上应用程序的运行状态及其性能信息。该插件已经作为一个开源项目发布,我们期待您的反馈。

Collectd守护进程采用C语言编写,具有高性能和可移植性。它支持上百个插件 ,允许您收集有关ApacheNginx Web服务器性能统计数据、memory usage uptime等信息。

安装与配置

为了演示这些功能,我在EC2实例上安装并配置了Collectd服务及新Cloudwatch插件。

首先我创建了一条IAM策略,它具备将指标数据写入CloudWatch的权限:

然后我创建了一个IAM角色,允许EC2(运行collectd程序的实例)使用上述所建的策略:

如果我计划使用Collectd 插件从本地服务器或运行中的EC2实例收集统计信息,那请跳过这些步骤,采用创建一个具有适当权限的IAM用户作为替代方法。在我完成上述工作后,会将该用户的证书放在本地服务器或EC2实例中。

在策略和角色配置完毕后,选择该角色来启动一个EC2实例

登录并安装Collectd :

$ sudo yum -y install collectd

然后获取插件和安装脚本,设置脚本为可执行,并运行该脚本:

$ chmod a+x setup.py

$ sudo ./setup.py

回答一些交互问题确认安装过程无误,在完成配置之后就可启动Collectd :

Installing dependencies ... OK

Installing python dependencies ... OK

Copying plugin tar file ... OK

Extracting plugin ... OK

Moving to collectd plugins directory ... OK

Copying CloudWatch plugin include file ... OK

Choose AWS region for published metrics:

1. Automatic [us-east-1]

2. Custom

Enter choice [1]: 1

Choose hostname for published metrics:

1. EC2 instance id [i-057d2ed2260c3e251]

2. Custom

Enter choice [1]: 1

Choose authentication method:

1. IAM Role [Collectd_PutMetricData]

2. IAM User

Enter choice [1]: 1

Choose how to install CloudWatch plugin in collectd:

1. Do not modify existing collectd configuration

2. Add plugin to the existing configuration

Enter choice [2]: 2

Plugin configuration written successfully.

Stopping collectd process ... NOT OK

Starting collectd process ... OK

$

在Collectd运行并且插件安装配置完成后,下一步是确定感兴趣的统计信息,并配置插件将它们发布至CloudWatch中(每个指标的采集成本也是一个需考虑因素)。

文件/opt/collectd-plugins/cloudwatch/config/blocked_metrics包含已收集但尚未发布到CloudWatch的指标列表:


$ cat /opt/collectd-plugins/cloudwatch/config/blocked_metrics

# This file is automatically generated - do not modify this file.

# Use this file to find metrics to be added to the whitelist file instead.

cpu-0-cpu-user

cpu-0-cpu-nice

cpu-0-cpu-system

cpu-0-cpu-idle

cpu-0-cpu-wait

cpu-0-cpu-interrupt

cpu-0-cpu-softirq

cpu-0-cpu-steal

interface-lo-if_octets-

interface-lo-if_packets-

interface-lo-if_errors-

interface-eth0-if_octets-

interface-eth0-if_packets-

interface-eth0-if_errors-

memory--memory-used

load--load-

memory--memory-buffered

memory--memory-cached

如您对内存消耗关注,可添加了一行到

/opt/collectd-plugins/cloudwatch/config/whitelist.conf

memory--memory-.*

Collectd配置文件(/etc/collectd.conf)中包含Collectd附加设置及插件设置。不需要做任何修改。

重新启动Collectd,以便所做的调整生效:

$ sudo service collectd restart

为了模拟内存消耗,可执行了一些消耗内存的程序,然后打开CloudWatch Console来查找并显示自定义指标:

该截图包括了对CloudWatch控制台即将推出增强功能的预览;如果看起来不一致也不必担心(请关注获取更多信息)。
如果监控一个生产实例,您还可以安装更多Collectd插件。以下是Amazon Linux AMI可用插件列表:

$ sudo yum list | grep collectd
collectd.x86_64                        5.4.1-1.11.amzn1               @amzn-main

collectd-amqp.x86_64                   5.4.1-1.11.amzn1               amzn-main

collectd-apache.x86_64                 5.4.1-1.11.amzn1               amzn-main

collectd-bind.x86_64                   5.4.1-1.11.amzn1               amzn-main

collectd-curl.x86_64                   5.4.1-1.11.amzn1               amzn-main

collectd-curl_xml.x86_64               5.4.1-1.11.amzn1               amzn-main

collectd-dbi.x86_64                    5.4.1-1.11.amzn1               amzn-main

collectd-dns.x86_64                    5.4.1-1.11.amzn1               amzn-main

collectd-email.x86_64                  5.4.1-1.11.amzn1               amzn-main

collectd-generic-jmx.x86_64            5.4.1-1.11.amzn1               amzn-main

collectd-gmond.x86_64                  5.4.1-1.11.amzn1               amzn-main

collectd-ipmi.x86_64                   5.4.1-1.11.amzn1               amzn-main

collectd-iptables.x86_64               5.4.1-1.11.amzn1               amzn-main

collectd-ipvs.x86_64                   5.4.1-1.11.amzn1               amzn-main

collectd-java.x86_64                   5.4.1-1.11.amzn1               amzn-main

collectd-lvm.x86_64                    5.4.1-1.11.amzn1               amzn-main

collectd-memcachec.x86_64              5.4.1-1.11.amzn1               amzn-main

collectd-mysql.x86_64                  5.4.1-1.11.amzn1               amzn-main

collectd-netlink.x86_64                5.4.1-1.11.amzn1               amzn-main

collectd-nginx.x86_64                  5.4.1-1.11.amzn1               amzn-main

collectd-notify_email.x86_64           5.4.1-1.11.amzn1               amzn-main

collectd-postgresql.x86_64             5.4.1-1.11.amzn1               amzn-main

collectd-rrdcached.x86_64              5.4.1-1.11.amzn1               amzn-main

collectd-rrdtool.x86_64                5.4.1-1.11.amzn1               amzn-main

collectd-snmp.x86_64                   5.4.1-1.11.amzn1               amzn-main

collectd-varnish.x86_64                5.4.1-1.11.amzn1               amzn-main

collectd-web.x86_64                    5.4.1-1.11.amzn1               amzn-main

需了解事项

如果您使用的是5.5或更新版本的Collectd ,则会在默认情况下发布四个指标:

  • df-root-percent_bytes-used – disk utilization
  • memory–percent-used – memory utilization
  • swap–percent-used – swap utilization
  • cpu–percent-active – cpu utilization

如果您不希望发布它们,您可以从whitelist.conf文件中删除这些指标。

在Amazon Linux AMI,Ubuntu,RHEL和CentOS的软件仓库中,目前提供了较旧版本的Collectd; 如果从源代码或自定义repo进行构建安装,请注意默认行为的变化。

更多

除了本次所展示的内容外, 您可以安装更多的插件,然后配置whitelist.conf来向CloudWatch发布更多的指标。同时您可以创建CloudWatch警报 ,自定义仪表盘等。

要开始使用,请访问AWS Lab on GitHub,并下载collectd plugin for CloudWatch

译者介绍

 

倪晓峻,AWS专业服务顾问,负责基于AWS云计算项目的咨询和设计,具有超过十五年以上企业客户服务经验,致力于AWS服务在国内和全球的项目实施。在企业级解决方案,混合云架构,运营集成等领域有着广泛的设计与实践经验。在加入AWS之前曾任职VMware;HPE专业服务顾问,从事云计算/虚拟化架构设计及运维咨询工作,两次获得省部级科技进步奖励,参与OGC ITIL V3中文版的审定工作 。

 

 

新增 – 面向 Amazon CloudWatch 控制面板的 API 和 CloudFormation 支持

我们在几年前发布了 CloudWatch 控制面板。在专为这次发布撰写的文章中,我介绍了如何以交互方式创建控制面板,以便以图形形式显示所选的 CloudWatch 指标。发布之后,我们增加了其他功能,包括全屏模式、深色主题、控制 Y 轴的范围、简化的重命名、持久性存储和新的可视化选项

新 API 和 CLI

虽然控制台支持非常有利于交互式使用,但许多客户要求我们提供对控制面板及其中小部件的编程式创建和操作的支持。这些客户想要动态构建和维护控制面板,从而在创建和销毁相应的 AWS 资源时添加和删除小部件。其他客户则希望在两个或多个 AWS 账户中设置和维护一组一致的控制面板。

我非常高兴地宣布,面向 CloudWatch 控制面板的 API、CLI 和 AWS CloudFormation 支持现已推出,您可以立即开始使用!

我们新增了四个 API 函数 (和等效的 CLI 命令):

ListDashboards / aws cloudwatch list-dashboards – 用于提取账户内所有控制面板的列表,或共享通用前缀的子集。

GetDashboard / aws cloudwatch get-dashboard – 用于提取单个控制面板的详细信息。

PutDashboard / aws cloudwatch put-dashboard – 用于创建新控制面板或更新现有控制面板。

DeleteDashboards / aws cloudwatch delete-dashboards – 用于删除一个或多个控制面板。

控制面板概念 我将要向您展示如何使用这些函数和命令。在转入正题之前,我应该介绍几个重要的控制面板概念和属性。

全局 – 控制面板是 AWS 账户的一部分,但未与特定 AWS 区域关联。每个账户最多可以包含 500 个控制面板。

命名 – 每个控制面板都有一个在 AWS 账户内唯一的名称。名称最长可达 255 个字符。

网格模式 – 每个控制面板都由网格单元格组成。网格包括 24 个单元格,高度可根据需要调整。控制面板中的每个小部件可位于一组特定的网格坐标上,大小可跨越一个整数的网格单元格。

小部件 (可视化) – 每个小部件可以显示文本或一组 CloudWatch 指标。文本通过 Markdown 指定;指标可以显示为单个值,或以折线图或堆积面积图的形式显示。每个控制面板最多可以包含 100 个小部件。显示指标的小部件还可以与 CloudWatch 警报相关联。控制面板有 JSON 表示形式,现在您可以在控制台中看到并编辑它。只需单击 Action 菜单并选择 View/edit source 即可:

下面是我的控制面板源:

您可以使用此 JSON 作为您自己的应用程序的起点。如您所见,控制面板中每个小部件的 widgets 数组中都有一个条目;每个条目描述一个小部件,从其类型、位置和大小开始。

使用 API 创建控制面板

假设我要在特定区域为我的每个 EC2 实例创建一个含有小部件的控制面板。我会使用 Python 和适用于 Python 的 AWS 软件开发工具包,然后按如下所示开始创建 (请原谅我的代码不够专业):

import boto3
import json

cw  = boto3.client("cloudwatch")
ec2 = boto3.client("ec2")

x, y          = [0, 0]
width, height = [3, 3]
max_width     = 12
widgets       = []

接着,我直接对实例进行迭代,以便为每个实例创建 widget 词典,并将其附加在 widgets 数组中:

instances = ec2.describe_instances()
for r in instances['Reservations']:
    for i in r['Instances']:

        widget = {'type'      : 'metric',
                  'x'         : x,
                  'y'         : y,
                  'height'    : height,
                  'width'     : width,
                  'properties': {'view'    : 'timeSeries',
                                 'stacked' : False,
                                 'metrics' : [['AWS/EC2', 'NetworkIn', 'InstanceId', i['InstanceId']],
                                              ['.',       'NetworkOut', '.',         '.']
                                             ],
                                 'period'  : 300,
                                 'stat'    : 'Average',
                                 'region'  : 'us-east-1',
                                 'title'   : i['InstanceId']
                                }
                 }

        widgets.append(widget)

我更新循环内的位置 (xy),并形成一个网格 (如果我不指定位置,则小部件会从左向右、从上至下进行排列):

        x += width
        if (x + width > max_width):
            x = 0
            y += height

处理完所有实例后,我创建一个 JSON 版本的小部件数组:

body   = {'widgets' : widgets}
body_j = json.dumps(body)

接下来,我创建或更新我的控制面板:

cw.put_dashboard(DashboardName = "EC2_Networking",
                 DashboardBody = body_j)

运行代码后,会获得以下控制面板:

CloudWatch 团队建议,以编程方式创建的控制面板应包括文本小部件 (用于说明控制面板是自动生成的) 以及指向所使用的源代码或 CloudFormation 模板的链接。这样可防止用户在外部对控制面板进行手动更改。如前所述,每个指标小部件还可以与一个 CloudWatch 警报相关联。您可以通过编程方式或使用 CloudFormation 模板来创建警报,如示例 CPU 使用率警报。如果您决定这样做,则警报阈值会显示在小部件中。要详细了解此操作,请阅读 Tara Walker 近期发布的文章 Amazon CloudWatch 发布了控制面板警报功能。更进一步的操作是,我可以使用 CloudWatch Events 和 Lamba 函数来跟踪某些资源的创建与删除,并在发生更改时更新控制面板。要了解如何执行此类操作,请阅读使用 AWS Lambda 让 CloudWatch 控制面板保持最新

使用 CLI 访问控制面板 我还可以通过命令行访问和操作我的控制面板。例如,我可以生成一个简单的列表:

$ aws cloudwatch list-dashboards --output table
----------------------------------------------
|               ListDashboards               |
+--------------------------------------------+
||             DashboardEntries             ||
|+-----------------+----------------+-------+|
||  DashboardName  | LastModified   | Size  ||
|+-----------------+----------------+-------+|
||  Disk-Metrics   |  1496405221.0  |  316  ||
||  EC2_Networking |  1498090434.0  |  2830 ||
||  Main-Metrics   |  1498085173.0  |  234  ||
|+-----------------+----------------+-------+|

然后,我删除 Disk-Metrics 控制面板:

$ aws cloudwatch delete-dashboards --dashboard-names Disk-Metrics

此外,也可以检索用于定义控制面板的 JSON:

使用 CloudFormation 创建控制面板

控制面板还可以在 CloudFormation 模板中进行指定。下面是一个简单的 YAML 格式的模板 ( DashboardBody 仍以 JSON 指定):

Resources:
  MyDashboard:
    Type: "AWS::CloudWatch::Dashboard"
    Properties:
      DashboardName: SampleDashboard
      DashboardBody: '{"widgets":[{"type":"text","x":0,"y":0,"width":6,"height":6,"properties":{"markdown":"Hi there from CloudFormation"}}]}'

我将模板放置在一个文件中,然后使用控制台或 CLI 创建堆栈:

$ aws cloudformation create-stack --stack-name MyDashboard --template-body file://dash.yaml
{
    "StackId": "arn:aws:cloudformation:us-east-1:xxxxxxxxxxxx:stack/MyDashboard/a2a3fb20-5708-11e7-8ffd-500c21311262"
}

下面是控制面板:

现已推出

此功能现已推出,您可以立即开始使用。您可以免费创建 3 个控制面板,每个控制面板最多包含 50 项指标;如果创建的控制面板超过 3 个,则每月需支付 3 USD (相关价格信息,请访问 CloudWatch 定价页面)。您每月最多可以免费调用 100 万次新 API 函数;如果超出此范围,则每调用 1000 次需支付 0.01 USD。

-Jeff

利用Amazon CloudWatch 搭建无人值守的监控预警平台

资源与应用服务层监控

Amazon CloudWatch 监控和预警平台可以帮助客户统一管理和运维AWS云端和本地资源、服务和业务系统;使用 Amazon CloudWatch 可以收集和跟踪指标,收集和监控日志文件,设置警报。您可通过使用 Amazon CloudWatch 全面地了解资源使用率、应用程序性能和运行状况。使用这些分析结果,您可以及时做出反应,保证应用程序顺畅运行。

Amazon CloudWatch 的基本概念

请参考AWS 官方文档了解 Amazon CloudWatch的核心概念和术语,比如指标、命名空间、维度、时间戳、单位、统计数据、时间段、聚合、警报等。

基于CloudWatch 的监控预警平台架构

CloudWatch 提供了一套标准的API接口,用户可以利用该平台发布自定义应用、业务或者更加详细的系统指标。用户发布到Amazon CloudWatch 的指标是按时间排序的数据点集合,数据点本身可以来自于任何应用程序或者业务活动;指标通过名称、命名空间和维度进行唯一定义;维度可以帮助你设计数据点的分组特征或者类别,发布指标数据点时必须必须指定维度,比如虚机的CPU使用率,用户可以查看单独某个虚机的监控指标也可以按AutoScaling组来查看,这里的单个虚机或者AutoScaling组就是同一数据点的不同的维度。用户可以使用秒级甚至千分之一秒的频率发布自定义指标,但是Amazon CloudWatch 还是会将数据聚合到1分钟为最小粒度。

基于指标数据,用户可以翻译业务的波动异常到相应的指标,从而创建警报来和相应的操作来自动化应对各种异常情况,操作包括弹性伸缩(Auto Scaling)机制来应对访问流量变化或者Amazon SNS 主题订阅绑定的邮件通知、HTTP请求的调用和消息队列异步处理。

指标数据用户可以直接通过AWS 控制台进行的图形化按时间筛选、查看和分享;同时,用户也可以通过API接口获取指标数据进行第三方的处理和展示。CloudWatch默认保存两周的指标数据(海外区域部分可以支持免费存储最多15个月的统计数据,详情请查看AWS CloudWatch文档)。

本文的架构中,自定义指标收集不需要自己编程而是利用collectd守护进程进行监控和获取,同时利用CloudWatch Plugin for collectd直接将自定义指标发布和存储到CloudWatch中,用户随后可以基于自定义指标的进行自动化警报处理从而实现无人值守的统一监控平台。

什么是CloudWatch Plugin for collectd

CloudWatch一直支持用户发布自定义指标来存储、监控自己关心的业务、应用和系统健康状况;AWS最新发布了CloudWatch Plugin for collectd开源项目,该插件整合了collectd强大的收集各种类型统计数据的能力,帮助客户简化了开发收集自定义指标的相关工作,开箱即用地支持发布Apache、Nginx Web服务器应用指标,内存监控指标等监控数据到CloudWatch进行统一存储、展示和预警。

什么是collectd

collectd是一个基于C语言的守护进程,主要任务就是用来收集统计信息,它提供各种了存储方式来存储不同值的机制。它支持超过100种各类插件,下面大概列出一些比较常见的插件类型,具体的请参考collectd官方网站

  • Web应用:Apache、nginx
  • 数据库:MySQL、Oracle、PostgreSQL、memcached
  • 网络:OpenVPN、Ping、TCPConns、
  • 系统:Memory、Disk、FileCount、vmem、uptime、df

安装配置CloudWatch Plugin for collectd

下面的步骤以BJS区域的EC2为例来说明如何安装配置和使用CloudWatch Plugin for collectd:

用户授权

该插件支持IAM Role或者 IAM User两种方式的授权,按照AWS最佳实践,我们推荐使用IAM Role的方式进行授权。所以,开始之前,我们先创建一个IAM Role并赋予相应的权限。

创一个角色名字为role4collectd

然后在该角色的权限页面,创建角色策略,赋予该角色拥有发布指标的权限。

启动实例并绑定角色

如果你想在已经启动的EC2或者你自己的机器上启用该插件,可以忽略该步骤并创建一个具备CloudWatch发布指标权限的IAM User。

本文启动一个新的EC2实例并绑定上一步创建好的角色:

安装插件

登陆到EC2并更新系统。

[ec2-user@ip-10-0-0-6 ~]$ sudo yum -y install collectd
已加载插件:priorities, update-motd, upgrade-helper
正在解决依赖关系
--> 正在检查事务
---> 软件包 collectd.x86_64.0.5.4.1-1.11.amzn1 将被 安装
--> 解决依赖关系完成

下载CloudWatch Plugin for collectd 安装文件并执行,安装脚本会自动读取EC2的Meta Data,因此选项都可以默认选择,比如区域,EC2绑定的IAM Role等等。

[ec2-user@ip-10-0-0-6 ~]$ sudo -s
[root@ip-10-0-0-6 ec2-user]# wget https://raw.githubusercontent.com/awslabs/collectd-cloudwatch/master/src/setup.py
[root@ip-10-0-0-6 ec2-user]# chmod +x setup.py
[root@ip-10-0-0-6 ec2-user]# ./setup.py
[root@ip-10-0-0-6 ec2-user]# ./setup.py
Installing dependencies ... OK
Installing python dependencies ... OK
Downloading plugin ... OK
Extracting plugin ... OK
Moving to collectd plugins directory ... OK
Copying CloudWatch plugin include file ... OK

Choose AWS region for published metrics:
1. Automatic [cn-north-1]
2. Custom
Enter choice [1]:

Choose hostname for published metrics:
1. EC2 instance id [i-cc97bc74]
2. Custom
Enter choice [1]:

Choose authentication method:
1. IAM Role [role4collectd]
2. IAM User
Enter choice [1]:
Choose how to install CloudWatch plugin in collectd:
1. Do not modify existing collectd configuration
2. Add plugin to the existing configuration
Enter choice [2]:
Plugin configuration written successfully.
Stopping collectd process ... NOT OK
Starting collectd process ... OK

collectd和CloudWatch plugin for collectd到此就已经安装完成了。

定义发布到CloudWatch的指标

要在CloudWatch中存储和查看collectd收集的指标数据,需要完成两件事情(1)安装相应的collectd插件(2)在CloudWatch plugin配置文件中添加指标白名单。

查看CloudWatch plugin的指标白名单,版本collectd 5.5以下默认CloudWatch白名单指标是空的,也就是默认不会发布任何collectd的指标到CloudWatch:

[ec2-user@ip-10-0-0-6 ~]$ sudo cat /opt/collectd-plugins/cloudwatch/config/whitelist.conf

对于可用的collectd的指标数据类型,我们可以查看以下文件来确认,该文件包含没有发布到CloudWatch的指标类型,该文件是系统自动维护,不要人为进行修改:

blocked_metrics  plugin.conf      whitelist.conf
[ec2-user@ip-10-0-0-6 ~]$ sudo cat /opt/collectd-plugins/cloudwatch/config/blocked_metrics
# This file is automatically generated - do not modify this file.
# Use this file to find metrics to be added to the whitelist file instead.
cpu-0-cpu-user
cpu-0-cpu-nice
cpu-0-cpu-system
cpu-0-cpu-idle
cpu-0-cpu-wait
cpu-0-cpu-interrupt
cpu-0-cpu-softirq
cpu-0-cpu-steal
interface-lo-if_octets-
interface-lo-if_packets-
interface-lo-if_errors-
interface-eth0-if_octets-
interface-eth0-if_packets-
interface-eth0-if_errors-
load--load-
memory--memory-used
memory--memory-buffered
memory--memory-cached
memory--memory-free

假定我们对于内存相关指标比较感兴趣,可以将memory开头的指标类型添加到CloudWatch白名单:

[ec2-user@ip-10-0-0-6 ~]$ sudo vim /opt/collectd-plugins/cloudwatch/config/whitelist.conf
输入如下信息:

memory--memory-.*

重启collectd服务:

注:在BJS区域的EC2上默认安装和配置后,我们从日志会发现报错,主要原因是默认安装后的脚本不支持BJS区域,详细的错误识别请参考以下步骤。

打开debug模式:

重启collectd服务:

查看日志:

从下面的错误信息可以看到,脚本默认发布指标到如下的endpoint:https://monitoring.cn-north-1.amazonaws.com/, 但BJS区域的CloudWatch endpoint和海外区域的命名规则有差异,详细的AWS BJS区域服务的终端节点可以参考:中国(北京)区域

为了解决BJS区域终端节点的支持问题,我们需要更新插件的Python脚本文件使其支持BJS区域:

1.confighelper.py文件:该文件默认安装后的目录是 /opt/collectd-plugins/cloudwatch/modules/configuration

更新如下函数,

参考修改后的代码如下:

2. requestbuilder.py 文件:该文件默认安装后的目录为/opt/collectd-plugins/cloudwatch/modules/client

该类的主要功能是构建签名版本4的PutMetricData API请求,因此会使用到endpoint信息,具体请参考在线文档

更新如下函数,

参考修改后的代码如下:

重启collectd服务:

查看以 [AmazonCloudWatchPlugin] 开头的日志内容,从日志可以看出,我们添加到白名单的memory相关的日志包含四个不同的指标,每分钟发布一次:

登录AWS 控制台,打开到CloudWatch页面,左侧导航最底端有个自定义指标的选择框,下拉就可以选择collectd来查看刚刚发布的指标内容:

安装启用收集Apache监控数据插件

如果未安装配置好Apache Web服务器,可以参考 教程:在 Amazon Linux 上安装 LAMP Web 服务器 来搭建好该Web服务器环境。

通过以下命令可以查询 Amazon Linux AMI带有的collectd的插件列表:

apache的状态信息来自于自身的mod_status模块,collectd解析出例如传输的bytes大小,接受到的请求数量等指标;详情请参考该插件介绍页面;安装collectd apache 监控插件:

修改collectd的配置,默认安装的文件位置 /etc/collectd.conf:

LoadPlugin apache
<Plugin apache>
  <Instance “local”>
    URL “http://localhost/server-status?auto”
  </Instance>
</Plugin>

以下是针对httpd-2.2版本的参考配置,默认的配置文件位于/etc/httpd/conf/httpd.conf:

将apache相关状态指标加入到CloudWatch collectd插件配置的白名单列表,更新文件 /opt/collectd-plugins/cloudwatch/config/whitelist.conf :

重新启动相关服务:

这样我们就完成了安装配置新的collectd的apache插件,同时将apache的相关监控指标添加到CloudWatch的白名单,这样我们就可以无缝整合collectd的收集数据能力和CloudWatch统一存储、展示和预警能力,下图就是apache web应用相关的指标在CloudWatch中展示的结果:

基于CloudWatch指标创建警报

既然我们通过插件收集了很多系统和应用的指标,那如果发生一些异常或者超过预先定义的阈值的时候,我们如何去应对和处理呢?理想情况我们能够尽可能自动化来应对这些警报,即搭建“无人”值守的监控预警平台。下图是基于某一个采集指标定义警报及处理警报的操作的截图;当一个警报发生时,你可以定义一个或多个操作来应对和处理;你可以采取的操作类型有,发送邮件通知,发布消息到SNS服务,添加Auto Scaling操作,以及EC2实例操作;这里的EC2实例操作包含停止、终止、重启或恢复,任何EC2实例指标(在 AWS/EC2 命名空间中)或者包含“InstanceId=”维度的任何自定义指标都可以在警报中触发EC2实例操作。

一些限制

很多用户在开始接触CloudWatch的时候就非常关心性能问题,目前发布指标API PutMetricData 每秒可处理 150 个事务 (TPS),这是您每秒可以发出而不会受到限制的操作请求的最大数量,但可以在线请求提高限制;PutMetricData 同时支持GET和POST操作,请求最大大小分别为8KB和40KB。每个指标最多可以有10个维度;

总结

本文和大家一起学习了如何基于CloudWatch及collectd相关插件构建无人值守的监控预警平台;CloudWatch默认提供了AWS资源的基本监控数据,同时提供了CLI和REST API的方式供用户自行扩展自定义业务和系统指标数据; CloudWatch plugin for collectd 是AWS最新发布的一个开源插件,大家可以进一步通过学习该项目的源代码掌握如何基于Python扩展和集成AWS的服务。

作者介绍:

薛军

AWS 解决方案架构师,获得AWS解决方案架构师专业级认证和DevOps工程师专业级认证。负责基于AWS的云计算方案架构的咨询和设计,同时致力于AWS云服务在国内的应用和推广,在互联网金融、保险、企业混合IT、微服务等方面有着丰富的实践经验。在加入AWS之前已有接近10年的软件开发管理、企业IT咨询和实施工作经验。

Amazon CloudWatch Events监控您应用的安全

每个应用程序时刻都在产生事件,Amazon CloudWatch Events能帮助您针对应用的事件进行有针对性的响应和处理,及时响应,并处理错误事件,存储和分析潜在的告警信息。在接下来的篇幅里,我将利用AWS的CloudWatch Events,Lambda,SNS,SQS等服务向您展示如何及时分析与处理应用事件。

在这个场景中,我将应用事件划分分三个等级(当然,在您的具体业务场景中,您可以根据实际情况划分任意多的等级),Green,Yellow,Red。Green代表应用正常,您不需要进行任何动作。Yellow表示您应用的健康检查失败,通过Lambda来处理该类型事件。Red表示您的应用在至少一台服务器上已经失败,立即通知运维部门处理。

以下是该场景中的架构示意图:

1. 最左边为您的应用服务器群,他们将各自的事件发送给CloudWatch Events;

2. 在CloudWatch Events中设置Rule来进行区分,并将对应的事件发送相应的目标,如Lambda,SNS,SQS;

3. 目标在收到事件后进行相应的处理;

具体步骤:

1.   创建3个目标,Lambda,SNS,SQS;

1.1, 目标1,创建Lambda函数,SampleAppDebugger;

1.2, 目标2,创建SNS主题,RedHealthNotifier;

1.3, 目标3,创建SQS消息队列,ReportInspectionQueue;

 

2.   创建CloudWatch Events Rule

2.1, 将以下内容保存为YellowPattern.json;

2.2, 使用以下命令创建名为myCustomHealthStatusYellow的规则;

2.3, 使用以下命令创建目标;

2.4, CloudWatch Event需要将事件发送给Lambda,所以需要给Lambda添加适当权限允许CloudWatch这么做;

3.   重复上面的步骤创建第2条规则,并设置目标为SQS和SNS,特别注意,不要忘记给SNS,SQS设置相应权限以允许CloudWatch发送事件过来;

3.1, 使用以下命令创建名为myCustomHealthStatusRed的规则,这里的RedPattern.json文件其实是将2.1步骤中的YellowPattern.json是一样的,只是将内容中的Yellow替换成了Red;

3.2, 创建两个目标,SQS,SNS;

3.3, 添加权限允许CloudWatch Events发送事件;

其他SNS,SQS权限设置相关,请参考该官方链接:http://docs.aws.amazon.com/zh_cn/AmazonCloudWatch/latest/events/resource-based-policies-cwe.html#sns-permissions

4.   进行测试,手动放入一些Red事件(我设置了个小脚本,每次运行都会放入61个事件),看看SQS及SNS情况;

这里我运行了三次脚本,所以SQS中有183条消息

看看邮箱中是否会收到邮件

5.   测试Yellow事件及Lambda反应;

Lambda被触发的次数

作者介绍:

郑进佳

亚马逊AWS解决方案架构师,在加入AWS之前,在多家跨国公司有着超过7年的架构设计和项目管理的经验,对AWS云端高可用架构有着深刻的理解,以及对企业级应用如何迁移到云端的架构设计有实战方面的经验。