先说个丢人的事。去年有一次我半夜被客户电话叫醒，说网站打不开，我爬起来一看，ECS 的 CPU 从晚上十点开始就顶着 100% 跑，硬撑了三个小时才崩。监控其实一直在采数据，只是我没配报警——数据躺在那儿，比没有还气人。
这篇就把云监控最核心的那摊事讲明白：云监控 2.0 到底是什么、报警规则怎么配才不烦人、哪些渠道能收到通知，以及我自己的四条配置原则。
一、云监控 2.0：从"看指标"到"看全链路"
很多人对云监控的印象还停留在"看 CPU 曲线"。现在的云监控 2.0 已经是个一站式可观测平台，把原来分散的几套东西合到一起了：
| 数据源 | 原来归谁管 | 现在 |
|---|---|---|
| 指标（Metrics） | 云监控 CMS | 统一接入 |
| 日志（Logs） | 日志服务 SLS | 统一接入 |
| 链路（Traces） | 应用实时监控 ARMS | 统一接入 |
| 事件（Events） | 各产品自行上报 | 统一接入 |
四个来源汇到一个视图里，最大的好处是不用在四套控制台之间来回切。以前排查一个问题，先看 CPU，再翻日志，再找链路 trace，现在从一张观测图谱上顺藤摸瓜就行。它基于 UModel 做资源建模，能自动发现资源之间的关系——比如你这个报警是 ECS 的，还是它挂着的那块云盘的，图谱上直接连着。
大模型应用观测、日志审计、用户体验监控这些能力 2025-09 也一并发布了，页面打不开这种问题可以从用户端一直看到后端服务。
二、报警规则：配错了比不配还惨
报警规则的核心是三件事：看什么指标、什么条件算异常、通知谁。我把常见指标分个类：
| 类别 | 典型指标 | 建议阈值思路 |
|---|---|---|
| 资源类 | CPU、内存、磁盘使用率 | 磁盘看余量趋势，CPU 看持续时间 |
| 网络类 | 公网出带宽、连接数 | 与日常基线比，不设绝对数 |
| 应用类 | 5xx 错误数、响应时间 | 错误数突变比慢增长更危险 |
| 业务类 | 订单量、支付成功率 | 直接挂钩收入，最该报 |
三个我踩过的坑：
- 阈值拍脑袋。CPU 90% 报不报？批量任务一跑就误报，报两次你就会想把它关掉——狼来了的报警等于没配。正确做法是看基线：平时 20%，那就 70% 持续 5 分钟再报。
- 没有持续时间。瞬时尖峰是正常的，规则里加上"连续 N 个周期"条件，误报能少八成。
- 报警没人认领。通知发到群里，@了所有人等于没 @。渠道和值班表要对上，见下文。
三、通知渠道：别只挂一个
报警规则配好了，通知不到人就是白搭。多渠道冗余是底线：
- 短信/电话：最可靠的兜底，适合 P0 级故障
- 钉钉/飞书/企业微信群：日常值班主渠道，能 @ 到人
- Webhook：接自己的工单系统或值班机器人
我的习惯是同一个规则挂两个渠道：群消息负责日常可见，电话只留给"持续 15 分钟没恢复"的升级规则。这样既不会被半夜吵醒，也不会真出事时群里没人看。
四、免费与合规：企业用的几个定心丸
挑监控产品时我会额外看两件事：数据可靠性和权限隔离。
- 三副本机制：监控数据三个副本分布在不同服务器的不同物理磁盘上，单块盘坏了不丢数据，副本之间强一致。
- RAM/STS 权限体系：可以按资源维度给子用户授权，临时任务用 STS 发有时效的凭证，不用把主账号 AK 交出去。
- 开源兼容：原生支持 Prometheus、Grafana、OpenTelemetry、Elasticsearch——已有监控资产能平滑迁过来，不至于被绑定死。
另外提一句，阿里云是 Gartner 2022 年《应用性能监控与可观测魔力象限》里中国唯一入选的科技公司，选型时这是个不错的参考背书。
五、我的四条配置原则
- 先报警后优化：新机器上线第一周只做一件事——把磁盘和核心业务指标接上报警。
- 报警要能分级：群通知管日常，电话管事故，别一视同仁。
- 规则要有负责人：每条报警写清楚谁处理、处理不了找谁。
- 定期清理误报：每月 review 一次，误报超过三次的规则就改阈值，别懒。
监控这东西，平时看不见价值，出事那一晚值全年。花两小时把报警规则配好，换来的是一整年睡得着觉——这笔账怎么算都划算。
新用户上手可以直接从云监控产品页开始，免费额度足够个人开发者把常用指标全接上。
