云上业务最怕的是故障已经发生，却没人知道。接口变慢、数据库连接数悄悄涨满、凌晨磁盘写满，这些事如果没及时发现，最后多半会变成用户投诉。阿里云监控就是用来盯这些事的托管服务，指标采集、看板、告警和事件追踪都在里面。
这篇文章从实际使用出发，说明几个核心能力怎么用、告警怎么配，并以一个电商订单服务为例。不讲理论，只说落地时的取舍和踩过的坑。
一、阿里云监控的核心能力
日常用到的主要是下面几块。
- 云产品指标监控，ECS、RDS、SLB、OSS 等产品创建后默认上报基础指标，比如 CPU 使用率、内存、磁盘 IOPS、网络流量和连接数。不用额外装采集组件，打开控制台就能看。
- 自定义监控，通过 API 或 SDK 上报业务指标，例如订单创建成功率、支付回调耗时。基础指标只能告诉你机器忙不忙，业务是否正常要靠这一层补。
- 可视化大盘，把多个指标拼成仪表盘，按服务、环境或团队划分视图。大盘建议只放排障时真正会看的指标，少而准。
- 告警规则与通知，可以设静态阈值，也可以用基于历史趋势的动态阈值。通知渠道包括短信、邮件、钉钉和企业微信。
- 应用实时监控服务（ARMS），面向应用层，提供链路追踪、慢调用分析和异常堆栈定位。它和云监控的基础指标互相补位，单用哪一个都会留下盲区。
二、案例：订单服务的监控缺口
我们拿一个假设的中型电商团队做例子。订单服务跑在 3 台 ECS 上，后端连着一台 RDS MySQL，前面挂着 SLB。上线初期团队只配了 ECS 的 CPU 和内存告警。大促那天，CPU 一直在 40% 左右，看板上一切正常，客服却接到不少下单超时的反馈。
排查下来，问题出在 RDS。连接数被占满，应用线程排队等连接，请求越堆越多，而 ECS 的 CPU 几乎没动。所以数据库连接数、慢查询数、接口成功率这类和业务直接相关的指标，必须纳入监控，只看主机层远远不够。
三、搭建监控体系的五个步骤
1. 先想清楚指标异常会影响什么
配告警之前，先问一句：这个指标一旦异常，用户会感觉到什么？对订单服务来说，优先关注这几类。
- 接口层看 QPS、成功率、P95 与 P99 响应时间
- 数据层看 RDS 连接数、CPU、慢查询数量、主从延迟
- 中间件看消息队列堆积量、缓存命中率
- 业务层看下单成功数、支付成功率、库存扣减失败次数
2. 确认基础云产品监控的粒度
ECS、RDS、SLB 创建后会自动上报基础指标，但采集粒度和保留时长要自己核对。以 RDS 为例，先看默认粒度够不够排障，再确认连接数和慢 SQL 相关指标已经放进视图。如果粒度太粗，一次几秒钟的连接数尖峰在图上根本看不出来。
3. 上报自定义指标
业务指标一般在应用里通过 SDK 或 OpenAPI 上报。下面是一个简化的 Python 示例，把每次下单结果作为自定义指标发出去。
import os
import time
from aliyunsdkcore.client import AcsClient
from aliyunsdkcms.request.v20190101 import PutCustomMetricRequest
# 凭证建议通过环境变量或 RAM 角色注入，避免硬编码
client = AcsClient(
access_key_id=os.environ["ALIBABA_CLOUD_ACCESS_KEY_ID"],
access_key_secret=os.environ["ALIBABA_CLOUD_ACCESS_KEY_SECRET"],
region_id="cn-hangzhou",
)
def report_order_result(success: bool):
request = PutCustomMetricRequest.PutCustomMetricRequest()
metric = {
"MetricName": "order_create_result",
"Dimensions": '[{"serviceName": "order-service"}]',
"Values": '{"value": %d}' % (1 if success else 0),
"Time": str(int(time.time() * 1000)),
}
request.set_MetricList([metric])
client.do_action_with_exception(request)
上报频率别太高。按分钟聚合一次再发，既能避开接口限流，也能控制费用。
4. 设计告警规则
告警是最容易失控的部分。很多团队什么都想报警，结果值班群每天几百条，最后没人看。可以先守住四条。
- 只给直接影响用户的指标配高优先级告警。比如下单成功率连续 3 分钟低于 99%，这种就该叫人。
- 磁盘、连接数这类资源指标放预警级别，给处理留出时间，不必立刻叫醒人。
- 设置持续时长，瞬时毛刺不发通知。一次抖动就响，大家很快会把通知静音。
- 每条告警写清责任人和处理手册链接，收到通知时就知道找谁、先看什么。
回到前面的例子，团队把 RDS 连接数超过上限 80% 设为预警，同时把订单成功率告警提到最高级。之后两次活动，类似情况都在用户感知之前被发现，运维有时间扩连接池，或者先做限流。
5. 定期复盘告警
监控配置上线不是终点。每月翻一次告警记录，看误报有多少、平均多久响应、哪些故障没有被覆盖。误报多的规则调阈值，或者改用动态基线；事故里暴露出的盲区，补上对应指标。
四、常见踩坑
- 只看平均值。平均响应时间会把长尾藏起来，P95 和 P99 要一起看。
- 多账号、多地域各看各的。出事时没人能拼出全局，统一汇总和权限划分要提前规划。
- 告警只走短信。短信之外加上钉钉或企业微信，并设升级规则，无人响应时自动转给下一个人。
- 指标没有主人。每个看板和告警都要有明确负责人，没人管的规则很快就会失效。
写在最后
阿里云监控做的事，是把分散在各处的云资源状态收拢到一起。选指标时从用户影响出发，基础监控兜底，自定义指标补上业务视角，再靠定期复盘把告警压到够用的数量。做完这套之后，最直接的变化通常是值班时被无效告警打扰得少了。
