核心监控指标设计：延迟、吞吐量、准确率与资源
监控指标设计，说白了就是给系统装上一套「体检仪」。
我做了这么多年风控架构，见过太多系统上线后两眼一抹黑的情况。出了问题只能靠猜，靠翻日志，那感觉就像在黑暗中找钥匙。所以今天咱们聊聊，风控系统到底该盯哪些核心指标。
核心原则：监控不是为了看数字，而是为了在出问题前发现苗头。
一、延迟指标：P99 和 P50
延迟是风控系统的「心跳」。你想想看，一个风控决策如果花了 5 秒钟才返回，用户早就点走了。
P50（中位数延迟）：代表一半请求的耗时。这个指标反映的是系统「通常情况」下的表现。
P99（99分位延迟）：代表最慢的 1% 请求的耗时。这个指标才是真正的「杀手」。我个人习惯，P99 比 P50 重要得多。
为什么？因为那 1% 的慢请求，往往是系统瓶颈的预警信号。我在项目中遇到过，P50 一直很漂亮，但 P99 突然飙升到 3 秒以上。查了半天，发现是某个规则引擎的缓存失效了，导致大量请求走了全量计算。
我的经验：建议同时监控 P50、P90、P99 三个分位。P90 可以帮你提前发现趋势，不用等到 P99 爆了才反应过来。
延迟监控的常见维度：
- 按接口维度：决策接口、查询接口、回调接口
- 按规则维度：单条规则执行耗时、规则集整体耗时
- 按数据源维度：数据库查询、缓存查询、外部 API 调用
我曾经踩过一个坑：只监控了接口整体延迟，没拆到规则级别。结果某个规则因为数据量暴增，执行时间从 10ms 涨到了 800ms，但接口整体 P99 只涨了 100ms，完全没引起注意。直到线上出现大量超时，才定位到问题。
避坑指南：延迟指标一定要分层监控。接口层、服务层、数据层，每一层都要有独立的延迟指标。否则你只知道「慢了」，但不知道「哪里慢了」。
二、吞吐量指标：QPS 和 TPS
吞吐量是系统的「肺活量」。QPS（每秒查询数）和 TPS（每秒事务数）是衡量系统处理能力的关键。
这里有个容易混淆的点：QPS 侧重查询类请求，TPS 侧重包含写入的事务类请求。在风控场景中，决策请求通常用 QPS 衡量，而包含数据落地的操作（比如记录决策日志、更新用户标签）用 TPS 更合适。
我建议这样设计：
| 指标 | 适用场景 | 监控粒度 |
|---|---|---|
| QPS | 纯查询、决策请求 | 秒级 |
| TPS | 包含写入的事务 | 秒级 |
| 峰值 QPS | 大促、活动期间 | 分钟级 |
吞吐量监控的核心不是看「现在多少」，而是看「趋势变化」。我习惯设置两个阈值：
- 预警阈值：达到峰值的 70%，开始关注
- 告警阈值：达到峰值的 90%，立即处理
举个例子，系统设计容量是 5000 QPS。当监控显示连续 5 分钟超过 3500 QPS，我就开始排查是否需要扩容。如果冲到 4500 QPS，那基本就是告警级别了。
小技巧：吞吐量指标一定要结合延迟指标一起看。如果 QPS 没变但延迟涨了，说明系统内部出了问题。如果 QPS 涨了延迟也涨了，那可能是容量不够了。
三、准确率指标：误杀率和漏过率
这是风控系统最核心的业务指标。说白了，就是「该拦的拦住了没，不该拦的放过了没」。
误杀率（False Positive Rate）：正常用户被误判为风险的比例。这个指标直接影响用户体验。
漏过率（False Negative Rate）：风险用户未被识别出来的比例。这个指标直接影响资金安全。
这两个指标是跷跷板关系。你压低了误杀率，漏过率可能就上来了。反之亦然。我见过很多团队只盯着误杀率，结果漏过率飙到 5% 以上，损失惨重。
我的建议是：
- 误杀率控制在 0.1% 以下（千分之一）
- 漏过率控制在 0.5% 以下（千分之五）
- 两个指标必须同时监控，不能偏废
重要：准确率指标不能只看整体，要按场景拆分。比如登录场景的误杀率和支付场景的误杀率，容忍度完全不同。登录误杀了可以重试，支付误杀了可能直接丢单。
我曾经遇到过一个案例：整体误杀率只有 0.05%，看起来非常漂亮。但拆开一看，某个特定渠道的误杀率高达 3%。因为那个渠道的用户画像比较特殊，模型没训练好。如果不拆分监控，这个问题根本发现不了。
四、资源指标：CPU、内存、磁盘
资源指标是系统的「体力」。CPU、内存、磁盘，这三样东西任何一个出问题，系统都跑不动。
CPU：关注使用率和负载。我习惯看两个维度：
- CPU 使用率：超过 80% 就要关注
- CPU 负载：超过核数的 70% 就要排查
内存：关注使用量和 GC 情况。Java 应用尤其要注意：
- 堆内存使用率：超过 70% 预警，超过 85% 告警
- GC 频率：Full GC 超过 1 次/分钟就要排查
磁盘：关注使用率和 IO 等待：
- 磁盘使用率：超过 80% 预警，超过 90% 告警
- IO 等待时间：超过 50ms 就要关注
避坑指南：资源指标一定要设置「持续告警」而非「瞬时告警」。CPU 偶尔飙到 90% 可能只是正常波动，但持续 5 分钟以上就说明有问题了。我习惯用「连续 3 个采样点超过阈值」作为告警条件。
五、指标之间的关系
这四个指标不是孤立的。它们之间有着千丝万缕的联系。
举个例子：
- CPU 飙升 → 可能导致延迟增加 → P99 上涨
- QPS 暴涨 → 可能导致内存不足 → GC 频繁 → 延迟上涨
- 磁盘写满 → 日志写不进去 → 决策结果丢失 → 漏过率上升
所以监控的时候，一定要建立「指标关联分析」的能力。看到一个指标异常，要能快速联想到其他指标可能的变化。
我的习惯：做一个「指标关联矩阵」，把四个维度的指标两两关联起来。比如 CPU 和延迟的关系、QPS 和误杀率的关系。这样出问题时，能快速定位根因。
六、知识体系总览
下面这张图，是我对核心监控指标的整体理解。你可以把它当作一个「监控地图」，每次设计监控方案时对照着看。
这张图把四个核心指标和它们的子指标、关联关系都串起来了。每次设计监控方案时，我都会拿出来对照一下，看看有没有遗漏。
好了，核心监控指标就聊到这儿。记住一句话：监控不是为了看数字，而是为了在出问题前发现苗头。下一章咱们聊聊告警策略的设计，怎么设置阈值、怎么避免告警风暴。