云上业务出问题时，最麻烦的常常是没人知道。比如凌晨两点数据库连接数被打满，如果没有告警，等到第二天用户投诉才发现，损失多半已经扩大。阿里云监控平台（CloudMonitor）就是用来补这块的。这篇文章结合实际使用经验，说说它能做什么，怎么设置告警，以及一个真实场景里是怎么落地的。
阿里云监控平台能帮你看到什么
它把云资源和应用的观测放在一起，指标采集、图表展示、告警通知、事件记录都在一个地方。对中小团队来说，最直接的好处是省事。ECS、RDS、SLB、OSS 这些常用产品的基础指标不用额外部署，开通后就能看到，团队可以把时间花在业务指标上。
功能主要分三块。
- 基础监控覆盖 CPU、内存、磁盘、网络等底层指标，默认免费，一般是分钟级粒度。适合用来判断机器是不是出了问题。
- 自定义监控通过 API 或 SDK 上报订单量、支付成功率、接口耗时这类业务数据。这部分需要开发配合，但价值最大。
- 告警与事件支持阈值告警、组合告警和异常检测，通知可以发到短信、邮件或钉钉机器人。
几个关键能力怎么用
先把指标和标签理顺
跨多个可用区、多套环境部署时，资源很快就会乱。建议从一开始统一打标签，常见做法是 env、team、service 三个维度。之后按实例筛选、绑定告警策略、做成本分摊，都会方便很多。标签规范如果等到资源多了再补，工作量会翻几倍。
基础指标不够，要补业务指标
服务器 CPU 只有 30%，不代表业务正常。支付接口的成功率可能已经从 99.9% 掉到 95%，这种问题只看机器指标基本发现不了。所以需要把订单、支付、接口耗时这些关键节点的数据通过自定义指标上报上来，才能看到用户真正的体验。
告警阈值是最容易做坏的地方
阈值定得太低，告警天天响，值班的人很快就麻木了。定得太高，真出问题时又来不及。比较稳的做法有三条。
- 关键指标设两级告警。比如 CPU 超过 70% 发普通通知，超过 90% 直接电话提醒。
- 加上持续时长条件，比如连续 3 个周期超过阈值才触发，能过滤掉瞬时毛刺。
- 按严重程度分级，并绑定到具体的责任人或值班群。否则所有告警都发到一个大群里，很可能没人看。
一个电商团队的实际例子
某中型电商团队在大促时遇到过一次典型问题。活动开始后，订单接口明显变慢，但 ECS 的 CPU 和内存都正常，大家一度怀疑是网络抖动。折腾了一个多小时才查到原因：RDS 的最大连接数被占满，新请求排队，接口跟着超时。
事后他们做了三件事。
- 在 RDS 监控里加上连接数、慢查询数量和主从延迟的告警。这次问题正是缺了这一块。
- 把订单接口的 P99 耗时和失败率做成自定义指标上报，让业务体验直接进入监控视野。
- 为大促单独做了一个告警看板，关键指标集中在一页上。值班同学打开就能判断整体状态，不用在多个控制台之间来回切。
之后的一次活动里，连接数告警在峰值前大约 15 分钟就触发了，团队及时扩容了数据库规格，高峰期平稳过去。这个例子说明，监控除了发现问题，还能给人留出反应时间。
落地时的几个注意点
指标不是越多越好。每多一个指标，就多一份维护成本。建议先围绕核心链路定十到二十个关键指标，跑稳之后再慢慢扩。
告警要能闭环。每条告警都应该对应一个明确的处理动作。如果某条告警每次都只是看看、然后关掉，说明它要么该删，要么阈值该调。告警疲劳是很多团队都会遇到的隐形问题。
每次故障之后，花几分钟回头看一下：当时的监控够不够用，有没有盲区。监控体系会随业务一起变化，定期检查比一次配置好更实际。
