2、核心监控指标设计：黄金信号与交易系统特有指标
大家好，我是你们的运维架构师。今天我们来聊聊监控指标设计——说白了，就是到底该盯哪些数字。
我记得刚入行那会儿，监控面板上铺满了上百个指标，CPU、内存、磁盘、网络……看着挺唬人，但系统一出问题，根本不知道从哪看起。后来我慢慢悟出一个道理：监控不是越多越好，而是越准越好。
2.1 黄金信号：四个你必须盯死的指标
Google 的 SRE 团队总结过四个黄金信号，我这些年用下来，确实管用。它们分别是：延迟、流量、错误、饱和度。
| 黄金信号 | 含义 | 我常用的监控方式 |
|---|---|---|
| 延迟 | 请求从发出到收到响应的时间 | P50、P95、P99 分位延迟 |
| 流量 | 系统承载的请求量 | QPS、TPS、带宽使用率 |
| 错误 | 请求失败的比率 | HTTP 5xx、超时、业务错误码 |
| 饱和度 | 系统资源被占用的程度 | CPU、内存、连接池、磁盘 IO |
我的经验之谈：这四个信号要一起看，别只看一个。比如延迟高了，可能是流量大了，也可能是资源饱和了。单看一个指标，很容易误判。
延迟（Latency）
延迟是用户体验最直接的体现。我个人习惯把延迟拆成两部分看：网络延迟和服务处理延迟。
举个例子，有一次交易系统响应变慢，我一开始以为是数据库扛不住了。结果一查，是网络交换机的一个端口丢包严重。嗯，这就是只看服务端指标容易踩的坑。
流量（Traffic）
流量指标告诉你系统当前有多忙。对于电子交易系统，我建议重点关注订单流入速率和行情推送速率。
我曾经遇到过一个场景：某次大促，流量瞬间飙升到平时的 10 倍，但监控只报了 CPU 升高，没报流量异常——因为流量指标没设告警。后来我学乖了，流量告警必须单独配。
错误（Errors）
错误不光是 HTTP 500。你想想看，一个请求返回了 200，但业务逻辑其实是失败的——比如下单成功但扣款失败。这种业务错误往往比系统错误更隐蔽。
避坑指南：我曾经只监控 HTTP 状态码，结果业务方反馈「订单提交失败」，我这边监控一片绿。后来我把业务错误码也纳入了告警体系，才堵住这个漏洞。
饱和度（Saturation）
饱和度是系统还能扛多少压力的指标。我常用的判断方式是：当资源使用率超过 80% 时，就要开始关注了。超过 90%，基本就是红色警报。
但要注意，不同资源的饱和度阈值不一样。比如 CPU 可以跑到 95% 还能撑一会儿，但数据库连接池到了 80% 就可能开始排队了。
2.2 交易系统特有指标
黄金信号是通用的，但电子交易系统还有自己的一套「专属指标」。这些指标直接关系到交易能不能正常完成、资金对不对得上。
订单吞吐量（Order Throughput）
订单吞吐量就是系统每秒能处理多少笔订单。这个指标我一般用每秒订单数（OPS）来衡量。
为什么它重要？因为交易系统的峰值流量往往集中在开盘、收盘那几分钟。如果吞吐量上不去，订单就会积压，用户就会骂娘。
成交率（Fill Rate）
成交率 = 成交订单数 / 提交订单数。这个指标反映了市场的流动性，也反映了撮合引擎的效率。
我记得有一次成交率突然从 60% 掉到 30%，排查下来发现是撮合引擎的一个缓存失效了，导致每次撮合都要重新加载数据。嗯，这种问题光看系统指标是发现不了的。
撮合延迟（Matching Latency）
撮合延迟是交易系统的核心指标。它指的是从订单进入撮合引擎到撮合完成的时间。
我建议把撮合延迟拆成几个阶段来监控：
- 订单接收延迟：从客户端发起到服务端收到
- 撮合计算延迟：撮合引擎实际计算的时间
- 结果推送延迟：从撮合完成到推送给客户端
这样一旦延迟升高，你能快速定位是哪个环节出了问题。
资金对账差异（Fund Reconciliation Difference）
这个指标是交易系统的「命门」。说白了，就是系统记录的账和实际资金流水是否一致。
我的血泪教训：有一次资金对账差异达到了 0.01 元，我以为是精度问题没在意。结果第二天差异变成了 1000 元。后来发现是某个订单的扣款和退款逻辑有 bug。从那以后，任何资金对账差异，哪怕只有 1 分钱，我都会立刻拉警报。
2.3 如何定义 SLO / SLI / SLA
这三个概念很多人容易搞混。我用自己的话给你解释一下：
- SLI（Service Level Indicator）：你实际测量的指标值。比如「过去 5 分钟的平均延迟是 200ms」。
- SLO（Service Level Objective）：你给自己定的目标。比如「99% 的请求延迟低于 500ms」。
- SLA（Service Level Agreement）：你跟用户签的合同。比如「如果延迟超过 500ms 的比例超过 1%，赔你钱」。
说白了，SLI 是「你测了什么」，SLO 是「你承诺了什么」，SLA 是「你赔什么」。
如何定义 SLO？
我建议从用户视角出发。你想想看，用户最关心什么？对于交易系统，用户最关心的是：
- 订单能不能及时提交
- 成交结果能不能及时看到
- 资金对不对得上
所以我的 SLO 一般这样定义：
| 指标 | SLO 目标 | 测量周期 |
|---|---|---|
| 订单提交延迟 | P99 < 100ms | 30 天滚动 |
| 撮合延迟 | P99 < 50ms | 30 天滚动 |
| 资金对账差异 | 差异金额 = 0 | 每次对账 |
| 系统可用性 | 99.99% | 月度 |
小技巧：SLO 别定得太高。99.99% 听起来很牛，但维护成本极高。我一般建议从 99.9% 开始，稳定了再往上提。你想想看，为了那 0.09% 的可用性，可能要花几倍的运维成本，值不值？
SLI 的测量方式
SLI 怎么测？我常用的方法有两种：
- 服务端埋点：在代码里打点，记录每次请求的延迟、状态码等
- 客户端探测：用模拟用户的方式，定期发送请求并测量
我个人更推荐两者结合。服务端埋点数据全，但可能漏掉网络层面的问题；客户端探测能模拟真实用户，但样本量有限。
SLA 的注意事项
SLA 是合同，写进去就要做到。我见过不少团队，SLA 写得天花乱坠，真出了问题赔不起。
避坑指南：我曾经参与过一个项目，SLA 里写了「系统可用性 99.999%」，结果一年下来有两次故障，每次赔了几十万。后来我们把 SLA 改成了 99.99%，虽然数字低了，但实际更合理。
2.4 知识体系总览
下面这张图是我自己整理的监控指标设计框架，你可以参考一下：
这张图把今天讲的内容串起来了。左边是黄金信号，右边是交易特有指标，下面是 SLO/SLI/SLA 的定义。你设计监控体系时，可以按照这个框架来搭。
好了，这一章的内容就到这里。记住一句话：监控不是为了看数据，而是为了发现问题。指标再多，不看、不分析、不行动，等于白搭。