[SEO 副标题]
本指南演示如何自动设置 Amazon CloudWatch 控制面板,以监视 AWS 上的网络资源并发出警报。它使用 AWS 标签和 API 功能高效地收集所需的信息,以配置控制面板,提供在 AWS 环境中进行集中监视的能力。这种自动化方法可帮助您节省建立全面网络可视性所需的时间和精力,同时使该流程更能适应 AWS 基础设施的变化。
共有三张架构图:第一张图说明了部署 CloudWatch 控制面板的概要性自动化流程。第二张图展示了配置监视时的详细信息。最后一张图展示了触发 CloudWatch 警报时的事件流。
请注意:[免责声明]
架构图
-
概览
-
监视
-
警报
-
概览
-
此架构图说明了为实现网络监视和警报而部署 Amazon CloudWatch 控制面板的概要性自动化流程。后续标签页提供了关于监视(标签页 2)和警报(标签页 3)配置的更详细信息。
第 1 步
一组 AWS 云资源在 Amazon CloudWatch 数据存储中持续存储相关指标。第 2 步
用户启动使用配置文件的指南资源收集器脚本。第 3 步
指南资源收集器从 AWS Resource Groups 标记 API 参考中获取与配置文件匹配的资源。第 4 步
指南资源收集器将资源数据保存在 JSON 文件中。第 5 步
用户启动 AWS Cloud Development Kit(AWS CDK),合成 AWS CloudFormation 模板。CloudFormation 模板使用了 AWS 的监视最佳实践。第 6 步
要求用户确认部署该模板。确认后,AWS CDK 将部署包含 CloudWatch 控制面板的合成模板。 -
监视
-
此架构图展示了如何生成和部署“事件转发器堆栈”,要配置受监视资源所在的 AWS 账户,这是必不可少的。需要对这些账户进行配置,将 CloudWatch 警报事件转发至中央“监视”账户。
第 1 步
用户运行“cdk deploy”命令,生成 CloudFormation 模板,并在指定的“监视”账户中部署基础架构。第 2 步
用户记录部署的输出,其中包含中央自定义 Amazon EventBridge 事件总线和 AWS Lambda 函数执行角色的 Amazon 资源名称(ARN)。第 3 步
用户提供从上一步获得的 ARN,以生成“事件转发器堆栈”的 CloudFormation 模板,这是配置来源账户所必需的。第 4 步
用户使用 CloudFormation StackSets,将“事件转发器堆栈”的 CloudFormation 模板部署到预期的来源账户(可单独部署,也可跨多个账户和区域部署)。 -
警报
-
此架构图展示了触发 CloudWatch 警报时的事件流。警报事件会转发到 Amazon EventBridge 事件总线,并由 AWS Lambda 函数处理。“View”和“List”Lambda 函数在 CloudWatch 控制面板中检索和渲染警报数据。
第 1 步
当指标超过 CloudWatch 警报中定义的阈值时,AWS 云资源将发送该指标。第 2 步
触发警报后,CloudWatch 会在相应账户的 EventBridge 默认总线上发出“CloudWatch 警报状态更改”事件。第 3 步
默认总线上的 EventBridge 规则会将事件转发至中央自定义 EventBridge 事件总线。第 4 步
在中央事件总线中定义的 EventBridge 规则将事件调度给用于分析事件的“Event Handler”Lambda 函数。
第 5 步
“Event Handler”Lambda 函数承担一个 AWS Identity and Access Management
(IAM)角色,该角色已由来源账户中设置的“事件转发器”CloudFormation 堆栈部署。然后,它会查询受监视的资源和 CloudWatch 警报,以获取其他详细信息。第 6 步
“Event Handler”Lambda 函数将其他详细信息与事件合并,并将合并的信息存储在 Amazon DynamoDB 警报表中。第 7 步
CloudWatch 控制面板包含自定义 CloudWatch 小部件,每次刷新控制面板时都会触发执行两个 Lambda 函数(“View”和“List”)。第 8 步
“View”和“List”Lambda 函数检索并筛选警报数据,然后生成 HTML 代码,以在相应的 CloudWatch 自定义小部件中渲染。第 9 步
“View”和“List”Lambda 函数将 HTML 代码返回至 CloudWatch 小部件,然后小部件在 CloudWatch 用户界面上渲染代码(包括相关指标)。
开始使用
Well-Architected 支柱
当您在云中构建系统时,AWS Well-Architected Framework 可以帮助您了解所做决策的利弊。框架的六大支柱使您能够学习设计和操作可靠、安全、高效、经济高效且可持续的系统的架构最佳实践。使用 AWS 管理控制台中免费提供的 AWS Well-Architected Tool,您可以通过回答每个支柱的一组问题,根据这些最佳实践来检查您的工作负载。
上面的架构图是按照 Well-Architected 最佳实践创建的解决方案示例。要做到完全的良好架构,您应该遵循尽可能多的 Well-Architected 最佳实践。
-
卓越运营
本指南的自动化部署和管理使用了 CloudWatch、Lambda、DynamoDB 和 AWS Systems Manager Parameter Store。具体而言,CloudWatch 用于实现指标的存储、监视和可视化,同时,Lambda 负责事件的处理和警报的可视化。DynamoDB 用于存储事件数据,而 Parameter Store 可管理指标和控制面板配置。总之,这些服务以经济实惠的方式为跨区域应用程序的可管理性、监视和自动化提供了支持。
-
安全性
IAM 用于控制对本指南中部署的资源的访问权限,其角色和策略的作用范围被限制为最低权限。Lambda 函数以最低权限运行,而 EventBridge 具有基于资源的策略,可防止未经授权的访问。这些安全措施符合 AWS 最佳实践,通过限制访问和降低未经授权活动的风险,保护资源和数据。
-
可靠性
无服务器 Lambda 函数的使用、DynamoDB 可靠和可扩展的功能,以及 CloudWatch 的监视和警报功能增强了此指南的整体可靠性。具体而言,CloudWatch 可支持快速检测和问题响应,而 Lambda 和 DynamoDB 则可以存储和可视化警报数据,以改善对整个环境的监视。
-
性能效率
EventBridge 是一项 AWS 托管服务,可向 Lambda 函数提供近乎实时的事件交付。Lambda 是一项无服务器服务,可自动横向缩减和扩展,以满足应用程序的性能需求。DynamoDB 用于在保持按需效率的同时,实现数据的快速查询。通过连接组件、最大限度地减少手动任务,并通过 CloudWatch 提供可观测性,这些服务共同实现了自动化的按需性能优化。
-
成本优化
DynamoDB 通过采用按需收费模式,为本指南中使用的数据提供经济实惠的存储。 Lambda 根据调用计费,使成本与实际使用量保持一致。CloudWatch 用于有效监视和管理资源。此外,DynamoDB、Lambda 和 CloudWatch 是无服务器服务,本身具有弹性能力,可以根据需要自动横向扩展和缩减。
-
可持续性
DynamoDB 无服务器架构有助于仅存储事件驱动的数据,从而节省数据存储所需的资源。同样,Lambda 的无服务器架构有助于确保仅使用必要的计算资源,并在任务完成后释放这些资源,从而减少浪费并提高资源利用效率。此外,CloudWatch 的事件监视功能可用于识别潜在的 AWS“资源浪费”,进一步提高资源利用率。
相关内容
免责声明
示例代码;软件库;命令行工具;概念验证;模板;或其他相关技术(包括由我方人员提供的任何前述项)作为 AWS 内容按照《AWS 客户协议》或您与 AWS 之间的相关书面协议(以适用者为准)向您提供。您不应将这些 AWS 内容用在您的生产账户中,或用于生产或其他关键数据。您负责根据特定质量控制规程和标准测试、保护和优化 AWS 内容,例如示例代码,以使其适合生产级应用。部署 AWS 内容可能会因创建或使用 AWS 可收费资源(例如,运行 Amazon EC2 实例或使用 Amazon S3 存储)而产生 AWS 费用。
本指南中提及第三方服务或组织并不意味着 Amazon 或 AWS 与第三方之间存在认可、赞助或从属关系。AWS 的指导是一个技术起点,您可以在部署架构时自定义与第三方服务的集成。