3、核心指标定义：延迟指标（微秒级）、吞吐量指标、订单簿健康度、成交率与滑点
各位同学，今天我们来聊聊监控系统里最核心的东西——指标定义。
说实话，很多团队一上来就堆 Grafana 面板，CPU、内存、网络全往上怼。但做高频交易，你真正该盯的，其实是这五个指标。我当年刚入行时也犯过这毛病，盯着系统负载看了三天，结果发现延迟早就爆了。嗯，咱们直接进入正题。
3.1 延迟指标：微秒级的生死线
延迟，说白了就是一笔订单从发出到确认的时间。在高频交易里，这个数字通常用微秒（μs）来衡量。1 微秒 = 0.000001 秒。你想想看，一个 tick 可能就几十微秒，你慢了，单子就抢不到。
我个人习惯把延迟拆成三段来监控：
- 网络延迟：从交易服务器到交易所网关的往返时间。这个受物理距离影响最大，所以很多团队会搞「主机托管」，直接把服务器放到交易所机房里。
- 内核延迟：数据包从网卡到用户态程序的时间。这里有个坑——Linux 默认的网络协议栈对高频交易来说太慢了。我建议用 DPDK 或者 Solarflare 的 OpenOnload 来绕过内核。
- 应用延迟：你的策略代码处理一笔订单的时间。这个就看代码优化了，C++ 写得好能压到 1-2 微秒，Python 嘛……嗯，你懂的。
核心监控指标：
- P50 延迟：中位数，代表典型性能
- P99 延迟：99% 的订单都能在这个时间内完成
- P99.9 延迟：尾延迟，这个最要命。我曾经遇到过 P50 只有 5μs，但 P99.9 飙到 500μs 的情况，查了半天发现是垃圾回收在作祟。
避坑指南：我曾经在监控里只看了平均延迟，结果系统偶尔卡顿完全没发现。后来加上了 P99.9 监控，才抓到那个每 10 分钟触发一次的定时任务。记住：在高频交易里，平均延迟是骗人的，尾延迟才是杀手。
3.2 吞吐量指标：你能扛多少单？
吞吐量，就是系统每秒能处理多少笔订单。这个指标跟延迟是「跷跷板」关系——你吞吐量上去了，延迟往往会跟着涨。
我一般会监控两个层面的吞吐量：
- 订单接收吞吐量：交易所每秒能接收多少笔订单。这个受限于交易所的 API 限流，比如 CME 的某些接口限制 50 笔/秒。
- 订单处理吞吐量：你的策略每秒能生成并发出多少笔订单。这个取决于你的计算能力和网络带宽。
这里有个常见的误区：很多人以为吞吐量越高越好。其实不然。你想想看，如果你的策略每秒能发 10 万笔订单，但交易所只收 1000 笔，那剩下的 9.9 万笔全堵在本地队列里，延迟直接爆炸。
警告：吞吐量监控一定要配合「队列深度」来看。如果发现本地待发送队列持续增长，说明你的系统已经「消化不良」了。我建议设置一个告警：当队列深度超过 1000 时，自动暂停策略。
3.3 订单簿健康度：市场的「心电图」
订单簿，就是交易所里所有买单和卖单的集合。它的健康度直接决定了你的策略能不能顺利执行。
我个人习惯看这几个维度：
- 买卖盘口深度：买一和卖一的价格差（spread），以及每个价位上的挂单量。如果 spread 突然变大，说明市场流动性不足。
- 订单簿斜率：这个是我自己常用的一个指标。说白了就是看价格每变动一个 tick，挂单量变化多少。斜率越大，说明市场越「硬」，你的大单子越容易造成滑点。
- 订单簿更新频率：每秒订单簿变化多少次。如果频率突然下降，可能是交易所出问题了，也可能是市场在「暴风雨前的宁静」。
实战案例：我记得有一次，监控系统突然报警说订单簿更新频率从 1000 次/秒降到了 10 次/秒。我第一反应是交易所挂了，结果查了半天发现是网络交换机的一个端口在丢包。嗯，从那以后我就在网络层加了双链路冗余。
3.4 成交率与滑点：你的策略到底赚不赚钱？
成交率，就是你发出的订单中有多少最终成交了。滑点，就是实际成交价和预期价格之间的差值。这两个指标直接关系到你的策略盈亏。
我一般这样定义：
| 指标 | 定义 | 监控频率 | 告警阈值 |
|---|---|---|---|
| 成交率 | 成交订单数 / 发出订单数 | 实时 | < 60% 告警 |
| 滑点（bps） | |实际成交价 - 预期价格| / 预期价格 * 10000 | 每笔统计 | > 0.5 bps 告警 |
| 部分成交率 | 部分成交订单数 / 总成交订单数 | 每小时 | > 20% 告警 |
为什么成交率这么重要？你想想看，如果你的策略发了 100 笔订单，只成交了 30 笔，那剩下的 70 笔要么被撤单了，要么被市场「吃」掉了。撤单本身也要消耗系统资源，而且频繁撤单会被交易所标记为「垃圾流量」，甚至可能被封号。
个人经验：我曾经优化过一个策略，把成交率从 40% 提到了 75%，但滑点从 0.2 bps 涨到了 0.8 bps。最后发现是订单价格设得太「激进」了。说白了，成交率和滑点是一对矛盾——你想成交快，就得接受更高的滑点；你想滑点小，就得等更久。这个平衡点，得靠实盘数据慢慢调。
3.5 指标间的联动关系
最后说一句，这些指标不是孤立的。我见过太多人盯着单个指标看，结果被误导了。
举个例子：
- 延迟升高 → 订单发出慢 → 成交率下降 → 策略被迫提高报价 → 滑点上升
- 吞吐量过大 → 队列堆积 → 延迟飙升 → 订单超时 → 成交率暴跌
- 订单簿健康度恶化 → spread 扩大 → 滑点上升 → 策略亏损
所以我的习惯是：在 Grafana 上做一个「指标联动面板」，把这五个指标放在同一个时间轴上。一旦某个指标异常，立刻看其他四个有没有跟着变。这样能快速定位问题根因。
总结一下：
- 延迟看 P99.9，别信平均值
- 吞吐量要配合队列深度看
- 订单簿健康度是市场的「体温计」
- 成交率和滑点是一对冤家，得一起看
- 五个指标联动分析，才能看到全貌
好了，这一章就到这里。下一章咱们聊聊怎么用 Prometheus + Grafana 把这些指标真正落地到监控面板上。到时候我会手把手教你怎么写 Exporter，怎么配告警规则。嗯，敬请期待。