内容提要
本文介绍了云原生工具在云计算环境中创建监控和告警的方法,包括使用亚马逊云科技的CloudWatch进行指标收集和配置监控、告警,通过Dashboard实时查看关键指标,以及通过Lambda函数调用Python SDK创建告警并通过钉钉群消息和短信通知相关人员。同时,还介绍了定期触发Lambda函数进行持续告警,并通过EventBridge实现短信通知。最后,强调了监控和告警的重要性。
延伸解读
监控指标选择:为何聚焦Top10与突增余额
文章针对数百台EC2和托管服务,选择CPU、内存、EBS使用空间等Top10指标,便于快速定位资源消耗最高的实例。特别关注EBS突增余额(BurstBalance),因Hadoop集群使用st1盘存在IO和吞吐量突增限制,监控可提前发现性能瓶颈,避免业务受影响。这种设计体现了从海量资源中抓取关键异常的思路。
告警自动化:Lambda与SDK应对规模挑战
面对数百台机器,手动创建告警不现实。文章通过Lambda调用CloudWatch的list_metrics和put_metric_alarm API,自动为每个磁盘指标创建告警,并关联SNS主题触发钉钉通知。代码中设置了AlarmActions和OKActions,实现告警和恢复时均发送消息,确保状态变化可追踪。这种自动化方式大幅提升运维效率。
持续告警机制:EventBridge定期扫描未处理告警
CloudWatch告警状态变为ALARM时仅发送一次通知,若未处理则不会重复提醒。文章利用EventBridge每10分钟触发Lambda,通过describe_alarms获取所有处于ALARM状态的告警,并根据告警类型(如磁盘、内存、Aurora等)构建不同消息,通过钉钉和短信再次通知。这确保了告警不被遗漏,直到问题解决。
通知渠道整合:钉钉与短信双保险
文章将告警消息发送到SNS主题,再触发Lambda处理并转发到钉钉群,同时针对重要告警(如磁盘、内存、CPU)调用阿里云短信服务发送短信。短信内容包含时间、状态、告警名称、实例信息等关键字段。双渠道通知提高了告警的触达率,尤其适合需要快速响应的生产环境。
Q&A
CloudWatch 默认能收集内存和磁盘指标吗?如果不能,需要怎么做?
默认情况下,CloudWatch 不能收集内存、磁盘等指标,需要安装 CloudWatch Agent 并进行相关配置。为了避免每台 EC2 都单独安装配置,可以先制作包含 CloudWatch Agent 及配置的 AMI,后续基于该 AMI 启动 EC2 实例。
如何用 CloudWatch 查询并展示 CPU 使用率 Top10 的 EC2 实例?
在 CloudWatch 控制台进入“指标 → 全部指标 → 多来源查询 → 编辑器”,输入查询语句:SELECT AVG(CPUUtilization) FROM SCHEMA("AWS/EC2", InstanceId) GROUP BY InstanceId ORDER BY AVG() DESC LIMIT 10,点击“运行”即可获得本区域最近 3 小时 CPU 使用率排名前 10 的 EC2 资源,然后通过“操作 → 添加到控制面板”将其添加到 Dashboard。
如何通过 Lambda 函数批量创建 CloudWatch 告警?
通过 Lambda 函数调用 Python SDK(boto3)实现。使用 list_metrics API 列出所有需要监控的指标(如 disk_used_percent),然后遍历指标调用 put_metric_alarm API 创建告警。创建时可配置 AlarmActions 和 OKActions 指向同一个 SNS topic,告警状态变化时触发 SNS 通知。
CloudWatch 告警触发后如何通知到钉钉群?
告警触发后发送消息到 SNS topic,SNS 触发一个 Lambda 函数,该函数解析告警消息并构建 markdown 文本,然后调用钉钉机器人的发送 API 将消息推送到企业钉钉群。
CloudWatch 告警一直未处理,如何实现持续重复通知?
CloudWatch 告警状态变为告警中只会发送一次消息。可以通过 EventBridge 定期(如每 10 分钟)触发 Lambda 函数,扫描所有处于告警状态的告警,根据告警类型构建消息并发送到钉钉群以及短信,直到告警被处理。
监控 EBS 突增余额(BurstBalance)有什么作用?
Hadoop 集群使用大量 st1(HDD)盘,st1 有 IO 和吞吐量突增余额限制。通过监控 EBS 突增余额 Top10,可以实时观察哪些 st1 磁盘已达到性能瓶颈,从而快速调整上层应用读写均衡或将频繁读写的磁盘替换为 gp3,规避性能下降风险。