证券交易系统全链路可观测：从下单到成交的毫秒级追踪

交易系统的可观测难点

券商核心交易链路通常是：客户端 → 网关 → 风控 → 撮合 → 清算，中间还有行情、账户、报盘等多个系统。一次下单要穿过十几个服务，任何一环抖动都会放大成委托延迟甚至报单失败。传统监控只看每个服务自己的 CPU 和日志，链路一断就抓瞎，定位问题靠"逐个服务翻日志"，平均半小时起步。

三个核心业务指标

对交易系统，最值得盯的不是资源指标，而是业务指标：

• 委托耗时（order_latency）：从网关收到委托到报盘确认的端到端时间，P99 必须守住，比如 50ms。
• 撮合成交率（fill_rate）：委托中最终成交的比例，突然下跌往往意味着风控误杀或撮合异常。
• 拒绝率（reject_rate）：按拒绝原因分桶，是风控拦截、参数错误还是系统异常，一眼区分。

这三个指标用 OBSERVE 的 PromQL 就能定义，配上分位数聚合：

histogram_quantile(0.99, sum(rate(order_latency_bucket[5m])) by (le))

全链路追踪与分层采样

交易系统是典型的高并发低延迟场景，全量采样存储扛不住。做法是分层采样：正常请求按 1% 采样，但标记了"大单"或"异常"的请求 100% 采集。OBSERVE 支持按 span 属性动态采样，把 order_amount > 1000000 或 reject_reason != '' 的链路全量保留。

排障时，先看告警里的 trace_id，点进火焰图定位到具体 span，再下钻看这条 span 关联的日志和 SQL。撮合超时、数据库锁等待、网络重传，一层层剥到根因，不用逐个服务翻日志。

分级告警策略

交易系统的告警要分级、要可行动：

• P1：委托耗时 P99 超过阈值 3 分钟，或拒绝率突增，直接电话 + 短信。
• P2：单节点 CPU 打满、磁盘写延迟升高，先自动摘流再通知。
• P3：趋势性告警，比如撮合耗时连续 30 分钟缓慢上升，提前介入。

告警信息里带上 trace_id 和当时的服务拓扑，收到告警的人不用再问"现在什么情况"。

落地效果与建议

这套体系在一家券商跑通后，平均故障定位时间（MTTD）从 45 分钟降到 6 分钟，报单失败率下降 40%。关键经验是：先建业务指标再建链路，别一上来就铺全量追踪，那样成本高还抓不住重点。