基于Amazon CloudWatch 和Grafana 的云上资源监控与报警解决方案

前言

基于Amazon CloudWatch和Grafana的云上资源监控与报警解决方案是亚马逊云科技专业服务团队 Data Analytics  Foundations 数据分析基座方案的系列博客之一。

背景信息

企业客户在运维云上应用时，除了使用Amazon CloudWatch进行轻量级监控外，他们更希望能有统一的运维看板来监控某一系统/业务部门涉及到的所有亚马逊云服务的组件运行情况。同时，Amazon CloudWatch监控的指标类型与数量繁多，需要投入非常多的精力研究不同指标之于服务的影响。所以，客户期待通过区分优先级的报警机制来避免非紧急非必要指标的过度通知，确保最紧急最重要的指标即时被响应。

方案概述

本文将展现一种以Amazon CloudWatch 监控的指标为数据源，Amazon EventBridge 和AWS Lambda作为运维事件监控和行动触发的组件，Amazon SNS和Amazon SQS 作为摄取云上运维事件的消息队列，Grafana 作为运维主看板的轻量级解决方案。此优化方案将能直观地带来三个优点：首先，在指标设计方面，亚马逊咨询顾问将根据过往经验，成体系地针对客户具体业务情况将需要监控的指标划分多优先级管理，确保最关键的指标一定被及时通知，而其余日常指标不会出现由于过度推送和通知，导致运维人员忽视重要指标的变化；其次，在报警事件运维措施的设计方面，避免了由于在岗人员因为各种原因没有收到和处理云上紧急事件的情况，采用增高严重等级的方式将相关内容逐级通知到领导层，确保任何重要且紧急的安全事件得以关注；最后，在内容展现方面，Grafana能提供更美观和更有交互式体验的运维看板，用户将能配置个性化的维度来监控亚马逊云服务某模块的运行详情。具体的实施架构如下图所示：

实施步骤

(1) 定义您的关键指标及处理方案

对于某业务部门或某App来说，计算引擎的表现一定是监控运维中重要的一环。以下内容以某部门的线上App为例：其计算引擎为Amazon EMR。为了保证App的正常运行，以下三方面是重要的监控场景：

1、当主、从节点处于非健康状态时，需要根据严重性监控报警；当主节点与所有从节点全部处于非可用状态时，Amazon EMR集群整体处于非可用状态，触发严重的报警。

2、当性能指标（如计算资源、内存等）达到瓶颈时，发出报警提醒此现象；其持续显示到达瓶颈时，需要升级报警，运维人员考虑扩容的问题。

3、当Amazon EMR上执行的Spark脚本出现错误时，需要报警提醒；随着脚本出错比例升高，通常存在网络或AWS依赖、代码增改带来的一系列问题，报警方式提升，需要运维人员即时介入修复。

根据事件严重等级的不同，以下表格展示了具体的通知方式。

根据以上三个场景，捕获Amazon CloudWatch 和Amazon EventBridge中的相应指标名称，如下。

(2) 配置Amazon EventBridge事件

确认好需要监控的指标后，通过以下三步使用Amazon EventBridge来捕获相关指标的变化。

Step 1. 通过上述指标和触发条件配置相应Alarm，创建对应Amazon CloudWatch Alarm

Step 2. 撰写Amazon CloudWatch Alarm对应的EventBridge事件规则，并建相应事件规则

Step 3. 配置个性化的Input Transformer，体现警报名称，警报状态，警报等级，描述等内容，并通将其绑定至通知报警的Amazon SNS上。

(3) 报警事件集中处理分发机制

对于上述所有部署的来源于Amazon CloudWatch 或 Amazon EventBridge的报警事件，都会将特定信息：包括事件详情，警报等级，对事件的描述性文字等内容传至Amazon SNS，被特定的AWS Lambda（命名为Incident Manager）集中消费。除了上述信息外，在Incident Manager Lambda中，根据您倾向的通知方式，您可能还需要配置如下环境变量：

• 运维事故第一通知人的联系方式
• 可以向运维群组（Oncall，日常运维）发送群聊信息的Webhook链接
• 可以统一向运维邮箱发送邮件的Amazon SNS的资源ARN

在获取到上述信息后，Incident Manager将会根据严重性等级分配报警事件，执行特定的报警动作。

(4) 报警事件升级机制

当严重性为高（等级1）事件发生时，运维人员理论上会收到OnCall群组通知来立马处理安全事故，避免波及下游业务或将安全事故影响最小化。然而，在实际情况中，运维人员由于主观和客观的原因，不一定能被及时触达。所以当此类事件发生时，有一种升级机制保证运维团队总有人能认领并及时处理此类安全事故。有两种场景可以触发报警事件升级。

场景1. 当警报持续一段时间（如24小时内报警还在持续）还未修复时，触发升级机制

场景2. 当通知方式未触达运维人员时（服务端、客户端错误，邮箱满等情况），触发定时升级机制

对于上述两类场景，我们通过配置Recaller Lambda(如架构中所示)来定时读取消息队列中未能被正常情况消费的消息，并触发报警升级。

(5) 实时收集系统报警

在完成监控与报警指标的配置后，通过AWS Lambda聚合某系统内各服务发生的报警指标信息，并以近实时的方式同步至Amazon CloudWatch自定义命名空间内。

(6) 完成运维看板的开发

运维看板以Grafana为骨架开发，您可以任意选择Grafana应用所在的载体。它可以是：

• Amazon Managed Grafana (全托管的亚马逊云版本Grafana，用户验证时需要通过AWS SSO进行单点登录)
• Amazon EC2 & Grafana（更具灵活性，您需要自己管理Grafana的配置和部署）
• Amazon EKS & Grafana（容器化应用，加快Grafana部署，不需要过多运维配置）

运营看板中的内容以Amazon CloudWatch为数据源，以业务系统为单位分离不同看板。此例中，涉及到的服务有Amazon OpenSearch Service，AWS Step Functions，Amazon EMR等。每个业务线中包含了不同种类的AWS服务栈，看板在最上端展现了是否有高危报警事故正在发生，而下属栏位以AWS服务名做聚合，您可以通过与Grafana交互，轻松展开或收起您想要观看的具体服务指标。

总结

该博客介绍了一套轻量级的云上资源监控与报警方案，此方案展现了一种基于Amazon CloudWatch指标重要性分优先级运维的方案，自动化了云上关键资源指标出现报警后处理的流程，并且将运维看板统一化，优化了其美观性和交互性。

基于Amazon CloudWatch和Grafana的云上资源监控与报警解决方案已作为单独的功能模块整合到专业服务团队Data Analytics Foundations (DAF) 分析基座方案中。如您需要了解Data Analytics Foundations数据分析基座的详细内容或有其它建议或经验，欢迎联系我们。

本篇作者