越光科技 | 大规模自动化CloudWatch警报清理解决方案

2025-03-10 10:33 黄俊宇
25

您是否在 AWS 区域内有数千个Amazon CloudWatch 警报,并希望快速识别哪些是低值警报或跨区域配置错误的警报?您是否正在寻找方法来识别几天内处于 “ALARM” 或 “IN_SUFFICIENT” 状态且需要重新查看的警报?您是否需要一种清理机制来检查跨区域的低值警报并定期删除它们以优化警报成本?

这期技术博客中,我们将探讨如何在 AWS 账户中跨区域大规模部署 CloudWatch 低值警报清理机制,并讨论通过识别不同类型的配置错误或低值警报来帮助客户优化 CloudWatch 警报成本的机制。连续几天处于 ALARM 或 INSUFFICIENT_DATA 状态的警报被归类为过时警报。未采取任何措施且未被复合警报引用的警报可能价值较低。我们鼓励您检查这些警报以确保它们有用,或者如果您意识到不需要它们,请将其删除。

本实验将使用 cloudformation 堆栈部署服务:

图片

CloudFormation 模板将部署什么?


图片

CloudFormation 模板将把以下资源部署到 AWS 账户中:

  • AWS Lambda 的AWS Identity and Access Management (IAM)角色

    CloudWatchAlarmHealthCheckerRole

    允许写入 CloudWatch 日志和 S3 存储桶,以及访问 CloudWatch API


  • AWS Lambda函数

    CloudWatchAlarmHealthCheckerpy-<堆栈名称>


  • Lambda 函数的 Amazon CloudWatch Log组

    正常命名约定,即 /aws/lambda/<函数名称>

    设置为七天保留

    在这里明确创建,以便它们将随堆栈删除一起被删除


  • 用于上传“可疑警报”和“要删除的警报”电子表格的 Amazon S3存储桶

    S3存储桶名称

    S3 存储桶已将 DeletionPolicy 设置为保留

    允许从 Lambda 访问的 S3 存储桶策略


图片

如何部署 CloudFormation 模板


图片


1.下载 yaml 文件。

https://d2908q01vomqb2.cloudfront.net/artifacts/MTBlog/cloudops-1213/CloudWatchAlarm-HealthCheckerFunction-py-final.yaml

2.导航到您的 AWS 账户中的 CloudFormation 控制台。

3.选择创建堆栈。

图片

4.选择 模板已准备好,上传 模板文件,然后导航到刚刚下载的 yaml 文件。

5.选择 下一步。

图片

6.给堆栈命名(最大长度 30 个字符)

7.给出要创建的S3 存储桶名称(不能有大写字母),这是将要创建的用于上传警报电子表格的 S3 存储桶,然后选择下一步。

图片

8.如果需要,添加标签,然后选择 下一步。

9.滚动到屏幕底部的功能,然后选中 “我承认 AWS CloudFormation 可能会创建具有自定义名称的 IAM 资源”和“创建堆栈”;同时如有需要可配置其他如IAM角色等可选项。

图片

10.等待堆栈创建完成。

图片

11.导航到Lambda控制台 >函数。

12.选择名为CloudWatchAlarmHealthCheckerpy-<stackname>的 Lambda 函数

13.向下滚动到 Lambda 函数的代码部分并选择测试。

14.配置一个测试事件并在下面输入。

JSON

{ "nodata_days": 7, "stale_days": 30, "disabled_actions_days": 60, "max_iterations": 1800, "operating_mode":"report_only", "regions": ["us-east-1", "us-west-1", "us-east-2", "us-west-2", "eu-west-1"] }


下面是每个字段的详细解释:

    nodata_days: 设置在没有数据的情况下,数据可以保持的最大天数。在这个配置中,7表示如果某个资源在 7 天内没有数据,可能会被标记为无效或不再使用。

    stale_days: 表示数据过期的最大天数。这里的30意味着数据在 30 天后将被视为过时,并可能不再被使用或需要进行处理。

    disabled_actions_days: 设置禁用操作的天数。在这里,60表示如果某个操作已禁用超过 60 天,它可能会被标记为需要审查或采取进一步的措施。

    max_iterations: 设置处理过程中允许的最大迭代次数。1800表示最多进行 1800 次迭代处理,这通常用于循环任务或自动化脚本中,确保不会无限制地重复操作。

    operating_mode: 设置当前的操作模式。"report_only"表示系统只会生成报告,而不会采取实际的更改或操作。通常用于审查和调试过程,而不进行实际的执行或修复。

    regions: 指定操作所涉及的 AWS 区域列表。在此配置中,操作将会在以下区域进行:

        1.us-east-1(美国东部北弗吉尼亚)

        2.us-west-1(美国西部北加利福尼亚)

        3.us-east-2(美国东部俄亥俄)

        4.us-west-2(美国西部俄勒冈)

        5.eu-west-1(欧洲爱尔兰)

可以根据您的实际需求更改

图片

执行完毕后,前往S3桶查看;


图片

如下图,可疑警报电子表格包含您账户中跨地区的警报列表:
处于“ALARM”状态超过“stale_days”,且无数据
处于“IN_SUFFICIENT”状态的时间超过“nodata_days”
没有任何相关操作且没有父级的警报、缺少数据的警报。
已连续禁用超过“disabled_actions_days”的警报
'stale_days'、'nodata_days'、'disabled_actions_days' 可由您配置

图片

要删除的警报电子表格包含以下情况的警报:
  •     警报引用了无效的命名空间或不存在的命名空间。
  •     警报针对未知指标
  •     警报引用了对于度量而言不存在的维度。


图片

定价成本


图片

使用此解决方案需要付费,因为它将数据存储在 S3 存储桶中。该解决方案运行 Lambda 代码,在这种情况下,Lambda 函数会进行 API 调用。成本应该很小。例如,您的账户中的 100,000 个警报和 300,000 个指标的成本不到几美分。


所有定价详情均可在Amazon S3AWS Lambda页面上查看。


快来试试这套方案,让你的 AWS CloudWatch 警报管理变得高效有序,为你的云服务运维减负!


联系我们
电话咨询 13711342725
QQ咨询
微信客服