标题：阿里云监控怎么配告警？从指标采集到通知落地
云上业务最麻烦的情况，是出了故障却没人及时知道。阿里云监控（CloudMonitor）能覆盖云资源指标、应用性能、日志和告警通知。这篇文章按实际配置的顺序来讲：先定监控哪些对象，再接入数据，最后把告警送到值班的人手上。中间会用一个电商后台的例子说明每一步的取舍。
先定好要监控什么
不少团队刚接入监控时会把所有指标全部打开，结果告警每天响个不停，真正要紧的那条反而没人看。比较稳妥的做法是先把监控对象分层，每层只挑几个核心指标起步。一般可以分成四层：
- 基础设施层：ECS 的 CPU、内存、磁盘和网络带宽，RDS 的连接数和慢查询，SLB 的并发连接数与后端健康状态。
- 中间件层：Redis 的命中率和内存使用率，MQ 的消息堆积量，Elasticsearch 集群的健康状态。
- 应用层：接口成功率、平均响应时间、P99 延迟，以及 JVM 的 GC 频率和堆内存。
- 业务层：下单成功数、支付转化率、登录失败次数。业务指标常常比技术指标更早反映出问题。
每层选 3 到 5 个指标就够了。指标太少，故障来了看不到；太多，人会习惯性地忽略告警。先跑一段时间，再根据误报和漏报慢慢增减。
基础指标：ECS 和 RDS 开箱即用
阿里云产品默认会把基础指标上报到云监控，ECS 和 RDS 都不需要额外安装代理。ECS 的基础指标采集间隔是 15 秒或 60 秒。如果要看内存和磁盘使用率这类更细的数据，需要在实例里安装云监控插件（Cloud Monitor Agent），装好后在实例的监控页面就能看到。
有个电商团队在大促前压测，最初只盯着 CPU，阈值设在 80%。压测时 CPU 一直低于 50%，接口却大量超时，原因是数据库连接池被占满了。之后他们把 RDS 的活跃连接数和 ECS 的内存使用率放进同一个看板，压测阶段就找到了这个瓶颈。只看一个指标，很容易得出“机器还很空”的错误结论，所以相关指标最好放在一起看。
应用监控：从接口看用户体验
机器指标正常，用户也可能用不了。应用监控关注的是请求本身。阿里云应用实时监控服务（ARMS）通过探针采集 Java、Python、Go 等语言应用的调用链、慢调用和异常。普通虚拟机上一般是在启动参数里加探针；容器环境通常用 Helm 或 Operator 安装。
接入之后，建议先盯住三类数据：
- 核心接口的成功率。下单、支付这类接口，一般要求保持在 99.9% 以上。
- P99 响应时间。平均值会把长尾问题藏起来，用户感觉到的卡顿通常出在尾部。
- 依赖调用的耗时分布。它能告诉你慢在自己的代码里，还是慢在下游服务上。
同一个电商团队接入 ARMS 后发现，订单详情接口在高峰期 P99 会升到 3 秒以上。调用链显示，大部分耗时花在一个没有缓存的商品查询上。加上 Redis 缓存后，P99 降到 300 毫秒左右。
日志和自定义指标
有些问题只能从日志里查。阿里云日志服务（SLS）可以采集应用日志和 Nginx 访问日志，并支持类 SQL 的查询和统计。比如统计每分钟支付失败的次数，再把结果转成时序指标，接入云监控做告警。
业务量、队列长度这类数据，可以通过云监控的 API 或 SDK 上报为自定义指标。自定义指标是计费的，上报频率和维度数量要控制好。尤其要避免用用户 ID、订单号这类高基数的值做标签，否则成本涨得很快。
告警怎么设计
告警是监控的出口，也最容易失控。下面几条比较实用：
- 分级通知：P0 级直接电话通知值班人员，P1 级发到企业微信或钉钉群，P2 级只进工单或日报，不打扰人。
- 设置持续时长：比如 CPU 连续 5 分钟超过 85% 才触发。瞬时毛刺很常见，不设时长，告警就会一直响。
- 合并重复告警：同一个问题在一段时间内只通知一次，并配合静默规则，避免值班人员半夜被同一条告警反复叫醒。
- 每条告警配一份处理说明：写清楚排查方向和负责人。没有处理说明的告警，收到后往往不知道下一步做什么。
一个常见的反面例子是，团队把日志盘的磁盘使用率阈值设为 70%。日志盘长期在 75% 左右波动，每天都有大量无效告警，最后没人愿意看。后来他们把阈值调到 85%，同时加上增长速率判断，比如“按当前速度 24 小时内写满”。告警数量下降了七成以上，剩下的告警响应也快了。
用复盘让监控越来越准
建议每周看一次告警记录，统计误报率、平均响应时长，以及反复出现的问题。对于重复发生的故障，可以写成自动化预案，比如通过云监控的事件总线触发弹性伸缩或自动扩容。每次复盘时还要问一句：这次故障有没有被监控覆盖？没覆盖的，就补上对应的指标。
小结
阿里云监控本身的配置不复杂，花时间的地方是想清楚监控什么、怎么分层、告警怎么设。可以先从基础设施和核心接口开始，用真实业务数据校准阈值，再逐步加上日志和业务指标。这样比一开始就追求全覆盖更踏实。
