不只是CPU和内存：云上业务指标监控与自定义告警实战
去年双11，凌晨两点，一个电商客户的监控大屏一片绿——CPU正常、内存正常、磁盘正常。但客服电话被打爆了：用户说付不了款。
技术团队懵了：所有技术指标都正常啊，怎么可能？
查了半小时才发现，支付网关的API返回了一个新的错误码，代码里没处理，直接把支付请求吞了。技术监控没报错，因为HTTP状态码还是200。
这是技术监控的盲区：技术指标正常，业务可能已经挂了。
今天聊聊业务指标监控。不是那种“监控很重要”的废话，而是帮你理清楚：哪些业务指标值得看？怎么采集？怎么设告警？怎么在用户骂人之前发现问题？
01 技术监控只能看到“机器”，看不到“生意”
CPU、内存、磁盘、网络——这些指标告诉你机器跑得怎么样。但它们不告诉你生意做得怎么样。
CPU正常，但用户登录不上。技术监控看不到。
内存正常，但支付成功率从99%掉到50%。技术监控看不到。
磁盘正常，但购物车加购率暴跌。技术监控看不到。
反常识观点：技术指标正常，不代表业务正常。 甚至有时候，业务已经挂了，技术指标还是绿的。
那家电商就是这样。他们的技术监控只盯着基础设施，没人看业务指标。支付网关改了接口，加了个新错误码，代码没处理，用户支付失败，但HTTP状态码是200。监控系统认为“一切正常”。
业务指标是生意的温度计，技术指标是机器的温度计。两个都要看。
02 哪些业务指标值得看？
业务指标分三类，按重要性排序。
第一类：收入型指标
直接跟钱挂钩。每天GMV、每小时的订单金额、客单价。
这类指标最敏感。GMV突然掉了一半，不用等用户投诉，你就能知道出事了。
第二类：转化型指标
反映用户行为漏斗。登录成功率、搜索点击率、加购率、下单成功率、支付成功率。
转化率突然下降，通常是代码bug、第三方接口故障、或者页面挂了。比收入指标更早发现问题——因为用户还没到付钱那步就卡住了。
第三类：流量型指标
反映用户活跃度。PV、UV、QPS、在线人数。
流量突然暴涨，可能是被攻击，也可能是有热点事件。流量突然暴跌，可能是DNS解析挂了，或者CDN出问题了。
那家电商后来把“支付成功率”和“下单成功率”加到了监控大屏上。双11当天，这两个数字一抖，他们就知道出事了，不等客服反馈。
03 怎么采集业务指标？
业务指标不在系统监控里，得自己埋。
方法一：代码埋点
最简单直接。在业务代码的关键位置，加一行统计代码。
支付成功后，计数器+1；支付失败，另一个计数器+1。然后暴露给监控系统。
方法二：日志解析
如果不想改代码，可以从日志里捞。支付日志、下单日志、登录日志，写个程序定期统计。
缺点是实时性差一点，日志量大时解析成本高。
方法三：中间件拦截
在API网关、消息队列这类中间件里，统计请求和响应。适合统一收集多个服务的指标。
工具选型：
Prometheus + Grafana：开源标配，Counter、Gauge、Histogram三种指标类型，够用了。
云原生：CloudWatch自定义指标、ARMS业务监控，和云服务集成好，但按指标量收费。
那家电商用的Prometheus，支付服务暴露了一个payment_success_total计数器，每成功一笔+1。Grafana上画了个图，按分钟聚合，一目了然。
04 告警：别让数字变成噪音
指标采集了，大屏画了，下一步是告警。但告警不是越多越好。
告警设计的三个原则：
原则一：只对“需要人马上处理”的情况告警。
凌晨三点收到“支付成功率低于95%”的告警，你得爬起来处理。收到“PV比昨天低5%”，可能只是正常波动，不用半夜折腾。
原则二：用动态阈值，别用死值。
“支付成功率低于99%”告警，平时可能天天报，因为凌晨维护时成功率本来就会低。改成“环比前10分钟下降超过5%”再告警，更精准。
原则三：组合条件，减少误报。
“GMV下降”同时“错误日志增加”，大概率真有问题。“GMV下降”但其他指标都正常，可能是大促结束后的自然回落。
那家电商后来设了这么几条告警：
支付成功率环比5分钟下降超过10%，P0级，电话告警。
下单成功率低于95%，P1级，钉钉告警。
每分钟订单数低于历史同期的50%，P1级。
效果：有一次支付网关升级，成功率从99%掉到80%，告警3分钟内触发，技术团队在用户大规模投诉前就定位了问题。
05 从技术监控到业务监控：一个真实案例
去年一个SaaS客户，他们的技术监控很完善，CPU、内存、延迟、错误率，全都覆盖。但老板还是不满意，因为“看监控不知道生意好不好”。
我们帮他们做了几件事：
第一，确定三个核心业务指标：每日活跃租户数、API调用成功率、订阅付费转化率。
第二，代码埋点。在用户登录、API调用、支付回调处加埋点，暴露Prometheus指标。
第三，Grafana大屏。不再只看技术指标，首页放业务指标。老板每天早上来，第一眼看的是“昨日活跃租户”。
第四，业务告警。活跃租户数连续30分钟低于正常水平，告警。API成功率低于99.5%，告警。
三个月后，他们靠业务监控发现了一个问题：周末的API调用成功率只有98%，平时是99.9%。查出来是某个定时任务周末跑批，把数据库连接池占满了。改完配置，成功率恢复正常。老板说：“以前靠用户投诉才知道问题，现在监控告诉我就知道了。”
写在最后
技术监控告诉你机器跑得怎么样，业务监控告诉你生意做得怎么样。两个都要，缺一不可。
别等技术指标都绿了，才发现用户付不了款。把支付成功率、下单成功率、登录成功率这些数字，放到你的监控大屏上，放到你的告警规则里。
那家电商的运维负责人后来总结了一句话：“以前觉得监控是给技术看的，现在觉得监控是给生意看的。机器没坏，但生意坏了，那才是真坏了。”
你的监控大屏上，有生意的温度计吗？
