2、核心指标设计：延迟、吞吐量、错误率、饱和度

监控系统到底该看什么？

很多人一上来就堆指标，CPU、内存、网络、磁盘……全堆上去。结果呢？告警风暴，一天几百条，最后全被忽略了。

我个人习惯，先抓四个核心指标：延迟、吞吐量、错误率、饱和度。这四个指标，能覆盖90%以上的系统问题。

2.1 延迟（Latency）—— 你的系统到底有多慢？

延迟，说白了就是「用户等多久」。量化交易里，延迟就是金钱。我见过一个团队，延迟从2毫秒涨到5毫秒，他们没在意。结果呢？套利策略直接亏了三天才发现。

延迟的测量方式：

• 端到端延迟：从行情数据到达，到策略发出订单，再到交易所确认。这是用户感知的延迟。
• 组件级延迟：每个环节单独测。比如行情解码延迟、策略计算延迟、网络传输延迟。
• 百分位延迟：别只看平均值。P50、P99、P999才是关键。P99延迟高，说明有长尾问题。

2.2 吞吐量（Throughput）—— 系统能扛多少？

吞吐量，就是系统每秒能处理多少笔交易、多少条行情。你想想看，如果行情来了每秒10万笔，你的系统只能处理5万笔，那剩下的5万笔去哪了？丢了？还是排队？

吞吐量的关键点：

• 峰值吞吐量：系统能承受的最大值。别拿平均值糊弄人，行情爆发时往往是平均值的10倍。
• 可持续吞吐量：长时间运行下，系统能稳定处理的量。很多系统峰值能扛，但跑半小时就崩了。
• 吞吐量与延迟的关系：吞吐量接近极限时，延迟会急剧上升。这叫「拐点」。我建议你提前找到这个拐点。

2.3 错误率（Error Rate）—— 系统在犯错吗？

错误率，这个指标最直接。但很多人只盯着「系统异常」和「报错日志」。其实，量化交易里的错误，远不止这些。

错误率的分类：

我见过最坑的一次：系统日志里一条错误都没有，但策略亏了200万。为什么？因为行情数据源切换时，时间戳格式变了，策略没发现。所以，错误率监控要覆盖「业务语义」层面。

2.4 饱和度（Saturation）—— 系统快撑不住了？

饱和度，是「系统还有多少余量」。这个指标最容易被忽视。很多人等到系统崩了才去查，其实饱和度早就报警了。

饱和度的典型表现：

• CPU 使用率：超过80%就要警惕。超过90%，延迟会开始飙升。
• 内存使用率：接近上限时，GC频率增加，或者开始使用交换分区（Swap），性能断崖式下跌。
• 网络带宽：接近上限时，丢包率上升，重传增加。
• 连接池/线程池：池子满了，新请求开始排队或直接拒绝。
• 磁盘 I/O：读写队列长度持续增长，说明磁盘扛不住了。

2.5 黄金信号与 USE 方法的结合

这四个指标不是孤立的。它们之间有关系：

• 延迟上升 → 可能是吞吐量接近极限，也可能是错误率增加导致重试。
• 吞吐量下降 → 可能是系统饱和了，也可能是某个组件出错了。
• 错误率增加 → 可能是资源饱和导致的连锁反应。
• 饱和度预警 → 往往是延迟和错误率恶化的前兆。

我个人的监控策略是：先看饱和度，再看错误率，最后看延迟和吞吐量。为什么？因为饱和度是「因」，延迟和错误率是「果」。你盯着延迟报警，往往已经晚了。饱和度报警，你还有时间处理。

2.6 知识体系图

2.7 实战建议

最后，给你几个实战建议：

1. 不要贪多：先盯这四个指标，跑通了再加别的。我见过有人一开始就监控200个指标，结果一个都没看住。
2. 设置基线：每个指标都要有「正常范围」。没有基线，报警就是瞎报。
3. 关联分析：延迟高了，别只看延迟。去看看饱和度，看看错误率。往往能找到根因。
4. 自动化响应：饱和度达到严重阈值时，自动切换备用节点或降级服务。别等人去处理，来不及。