核心指标定义：延迟、吞吐量、成功率、错误率、报价偏差率
做监控系统这么多年，我最大的体会是——指标选不对，告警全白费。你想想看，一个报价路由系统，每天处理几百万笔交易，如果连该看什么都搞不清楚，那跟闭着眼睛开车有什么区别？
今天我们就来聊聊，报价路由系统里最核心的五个指标。我个人习惯把它们分成两类：性能指标和质量指标。延迟和吞吐量属于前者，成功率、错误率、报价偏差率属于后者。嗯，咱们一个一个说。
一、延迟：P50 / P95 / P99
延迟，说白了就是一个请求从发出去到收到响应，花了多长时间。但问题来了——你该看哪个值？平均值？最大值？
我建议你千万别看平均值。为什么？因为平均值会骗人。举个例子：
- 99个请求都是10ms完成
- 1个请求卡了10秒
平均值算出来才100ms出头，看起来挺正常。但那个倒霉的用户已经等了10秒，早就不耐烦了。
所以，我们一般看百分位延迟：
| 指标 | 含义 | 我的经验值 |
|---|---|---|
| P50 | 50%的请求在这个时间内完成 | 代表"一般体验"，通常<50ms |
| P95 | 95%的请求在这个时间内完成 | 代表"大多数体验"，通常<200ms |
| P99 | 99%的请求在这个时间内完成 | 代表"长尾体验"，通常<500ms |
重点来了：P99 是监控的重中之重。如果 P99 开始飙升，说明系统里出现了严重的慢请求，可能是某个上游服务挂了，也可能是数据库扛不住了。
我在项目中遇到过一件事，印象特别深。有一次线上告警，P99 从 300ms 飙到了 2s，但 P50 才 80ms。一开始大家都没当回事，觉得"大部分用户还行"。结果呢？那 1% 的用户全是机构大客户，直接投诉到老板那里去了。从那以后，我再也不敢忽视 P99 了。
二、吞吐量：QPS / TPS
吞吐量，就是系统每秒能处理多少请求。在报价路由系统里，我们通常用两个指标：
- QPS（Queries Per Second）：每秒查询次数，适合读场景
- TPS（Transactions Per Second）：每秒事务数，适合写场景
你可能会问：报价路由系统该用哪个？我个人习惯两个都看。因为一次报价请求，往往包含多次查询和一次事务提交。
一个小技巧：监控吞吐量时，别只看峰值。要同时看基线值和峰值。基线值告诉你系统平时有多忙，峰值告诉你系统能扛多高。如果峰值接近系统上限的 80%，就该考虑扩容了。
我记得有一次大促，QPS 从平时的 5000 涨到了 30000。监控系统疯狂告警，但吞吐量曲线一直很平稳。为什么？因为提前做了限流和扩容。这就是监控的价值——让你心里有底。
三、成功率
成功率，就是成功返回结果的请求占总请求的比例。公式很简单：
成功率 = 成功请求数 / 总请求数 × 100%但这里有个坑——什么叫"成功"？ 是 HTTP 200 就算成功？还是业务逻辑正确才算成功？
我建议你区分两层：
- 网络层成功率：只要没超时、没断连，就算成功
- 业务层成功率：报价结果正确、交易成功执行，才算成功
注意：很多团队只看网络层成功率，结果业务层已经崩了还不知道。我曾经接手过一个系统，网络成功率 99.9%，但业务成功率只有 85%。因为报价引擎返回了"成功"，但价格算错了。你说这算成功吗？
所以，我的建议是：两个成功率都要监控，但告警阈值要分开。网络层低于 99.9% 就告警，业务层低于 99% 就要拉响了。
四、错误率
错误率和成功率是硬币的两面。但错误率更细，因为它能告诉你错在哪里。
我一般把错误分成几类：
| 错误类型 | 举例 | 处理方式 |
|---|---|---|
| 超时错误 | 上游报价源 5s 无响应 | 重试或降级 |
| 限流错误 | QPS 超过阈值被拒绝 | 检查是否需要扩容 |
| 数据错误 | 报价格式异常、字段缺失 | 记录日志，人工排查 |
| 业务错误 | 报价偏差超过允许范围 | 立即告警，暂停该源 |
为什么要分这么细？因为不同的错误，处理方式完全不同。超时错误可以重试，数据错误重试也没用。如果不分类，你看到错误率高了，根本不知道该怎么办。
我的经验：错误率监控一定要做按维度拆分。按上游源拆分、按接口拆分、按机房拆分。否则一个上游源挂了，错误率从 1% 涨到 5%，你都不知道是哪个源出了问题。
五、报价偏差率
这个指标是报价路由系统特有的，也是最容易忽略但最致命的指标。
报价偏差率，就是系统给出的报价与市场公允价格之间的差异比例。公式：
报价偏差率 = |系统报价 - 市场参考价| / 市场参考价 × 100%举个例子：市场参考价是 100 元，系统报了 101 元，偏差率就是 1%。
你可能会想：差 1% 而已，问题不大吧？
嗯，这要看场景。如果是散户交易，1% 可能还能接受。但如果是机构客户，一次交易几千万，1% 就是几十万的损失。客户不找你麻烦才怪。
注意：报价偏差率过高，往往不是技术问题，而是数据源问题。可能是某个上游报价源的数据延迟了，也可能是计算逻辑出了 bug。我曾经遇到过，一个报价源的缓存没刷新，导致偏差率持续 5% 长达 10 分钟——那 10 分钟，公司亏了上百万。
所以，我建议报价偏差率的告警阈值设得严一些：
- 警告阈值：偏差率 > 0.5%，持续 30 秒
- 严重阈值：偏差率 > 2%，立即告警
六、这些指标之间的关系
五个指标不是孤立的。它们之间互相影响，我画了一张图帮你理解：
从这张图你能看到：
- 延迟和吞吐量是性能指标，它们互相制约——延迟高了，吞吐量自然上不去
- 成功率和错误率是质量指标，它们直接反映系统稳不稳定
- 报价偏差率是业务特有指标，它独立于其他指标，但一旦出问题，影响最大
我个人习惯把这五个指标做成一个仪表盘，放在同一个页面上。这样一眼就能看出系统整体健康度。如果五个指标全是绿的，那基本可以放心喝茶了。但只要有一个飘红，就得赶紧排查。
最后一个小建议：指标不是越多越好。我见过有人把几十个指标堆在仪表盘上，结果真正出问题时，根本不知道看哪个。五个核心指标，足够了。先把这五个管好，再考虑加别的。
公众号:蓝海资料掘金营，微信deep3321