手把手教你用阿里云FC和云监控搭建智能告警系统

大家好，今天咱们来聊一个特别实用又有点“技术范儿”的话题——怎么用阿里云函数计算（FC）和云监控搭一套属于自己的智能告警系统。别一听“技术”就打退堂鼓，其实整个过程比你想象中简单多了！尤其是如果你已经在用阿里云的服务，那这套组合拳简直是如虎添翼。

先说说我为啥要搞这个。前段时间我负责的一个线上服务突然访问量暴增，结果没几分钟服务器直接崩了。后来查日志才发现，CPU早就飙到98%以上，但没人收到通知。你说气人不？从那以后我就下定决心：必须搞个自动报警机制，不能再靠“人肉盯屏”了。

经过一番折腾，我发现阿里云的函数计算（Function Compute，简称FC）+ 云监控（CloudMonitor）这对组合，简直就是为这种场景量身定制的。不仅能实时监控资源状态，还能在异常发生时自动触发函数发短信、推微信、甚至打电话！关键还特别省钱，毕竟FC是按调用次数计费，平时“躺着不动”完全不花钱。

为什么选阿里云FC + 云监控？

你可能会问：市面上监控工具这么多，为啥非得用阿里云这套？我给你三个理由：

• 原生集成，省心省力：都是阿里云自家产品，权限打通、配置联动一气呵成，不用折腾跨平台授权。
• 按需执行，成本极低：FC是Serverless架构，函数不运行就不收费。像告警这种低频高价值的场景，简直是为它而生。
• 扩展性强，玩出花样：你可以让告警信息发到钉钉群、企业微信、短信、邮件，甚至调用第三方API做更复杂的处理。

举个例子，我现在的告警系统不仅能告诉我“数据库CPU过高”，还能自动分析最近5分钟的日志，把最可疑的几条错误信息一起打包发给我。是不是很酷？

第一步：创建你的第一个监控告警规则

咱们先从最基础的开始——设置一个简单的监控项。比如你想监控某台ECS实例的CPU使用率。

登录阿里云控制台，找到【云监控】服务，点击左侧菜单的【报警服务】→【报警规则】→【创建报警规则】。接下来选择你要监控的产品类型，比如“云服务器ECS”，然后选具体的实例。

接着设置监控指标，这里我们选“CPU使用率”，统计周期可以设为1分钟，连续1次超过80%就触发。注意，“报警联系人组”一定要提前配置好，不然报警来了也没人收。

到这里，基本的监控就算完成了。但问题来了：默认的通知方式只有短信和邮件，不够灵活。这时候就得请出我们的主角——函数计算FC！

第二步：用函数计算接管告警通知

核心思路是这样的：当云监控检测到异常，不再直接发短信，而是调用一个FC函数。这个函数就像个“智能中转站”，接到消息后自己决定怎么处理——是发钉钉？还是推微信公众号？全由你说了算。

首先去【函数计算】控制台，创建一个新服务。建议给它起个直观的名字，比如“alert-handler”。然后在这个服务下新建函数，运行环境选Python 3.9（上手简单），模板选“空白函数”。

接下来是写代码环节。别紧张，我给你一段可以直接用的示例代码：

def handler(event, context):
    import json
    # 解析云监控推送的事件数据
    alert_data = json.loads(event)
    # 提取关键信息
    instance_id = alert_data.get('instanceId')
    metric_name = alert_data.get('metricName')
    value = alert_data.get('value')
    status = alert_data.get('status')  # OK 或 ALARM
    # 构造消息
    msg = f"【阿里云告警】n状态：{status}n实例：{instance_id}n指标：{metric_name}n当前值：{value}"
    # 这里可以调用钉钉机器人、短信API等发送通知
    send_dingtalk(msg)  # 假设你写了这个函数
    return 'OK'

真正的send_dingtalk函数你得自己补全，主要是调用钉钉机器人的Webhook接口。记得给这个FC函数分配一个能访问公网的角色权限。

第三步：让云监控“呼叫”你的函数

现在函数写好了，怎么让它被触发呢？回到云监控的报警规则页面，在“通知策略”里不要选短信或邮件，而是选择“函数计算”作为通知方式。

然后填入你刚才创建的函数ARN（在FC控制台函数详情页能找到）。保存之后，整个链路就通了！

测试一下：手动把ECS的CPU跑高，或者改低报警阈值到10%，很快你就能在钉钉群里看到自定义格式的告警消息了。那种“我终于掌控全局”的感觉，真的会上瘾。

进阶玩法：给告警加点“智商”

基础版搞定后，我们可以玩点高级的。比如：

1. 告警聚合，避免刷屏

你有没有经历过半夜被几十条“CPU过高”短信轰炸到崩溃？这是因为某些故障会持续几分钟，每30秒报一次。我们可以在FC函数里加个缓存机制，比如同一个实例10分钟内只发一次主告警，后续用“仍在异常中”提醒代替。

2. 自动诊断，附带建议

函数接到告警后，可以顺手调用其他API查相关日志。比如ECS CPU高，就去查对应实例的system log，找出是不是某个进程在疯狂占用资源，然后在通知里加上一句：“建议检查java进程是否内存泄漏”。

3. 分级响应，重要程度不同处理方式不同

不是所有告警都一样紧急。我们可以设置：普通异常发钉钉群，严重故障（如数据库宕机）不仅@负责人，还触发语音电话通知。这在FC里通过判断alert_data里的severity字段就能实现。

踩过的坑和避坑指南

最后分享几个我实战中踩过的坑，帮你少走弯路：

• 权限问题最多：确保FC函数的服务角色有云监控的读取权限，否则拿不到事件数据。
• 冷启动延迟：FC首次调用可能有几百毫秒延迟，对极端敏感的场景要考虑预热。
• 日志排查靠它：所有输出一定要print或写日志，不然出问题根本不知道哪错了。

另外提醒一点：国内手机号接收短信需要实名认证，如果你的阿里云账号没完成企业认证，短信功能可能受限。建议优先用钉钉或企业微信这类渠道。

结语：自动化才是王道

说实话，刚开始搭这套系统花了我两个晚上。但现在回头看，这投资太值了。我不用再担心半夜被叫醒处理问题，因为系统会第一时间通知我，而且附带初步分析。更重要的是，这种主动防御的心态，让我对线上系统的掌控感强了很多。

如果你也在用阿里云，真心建议花半天时间把这套告警系统搭起来。哪怕先做个最简单的版本，也能大大提升你的运维效率。

对了，搭建过程中如果要用到ECS、函数计算或其他云产品，别忘了先领个阿里云优惠券！新用户有很多折扣，老用户也有续费优惠，能省一点是一点嘛。

最后说一句：技术本身不难，难的是迈出第一步。你现在看到的所有“高手”，都是从“连告警都不会配”开始的。