交易链路毫秒级定位：证券交易系统全链路追踪方案

交易系统的可观测痛点

证券交易对时延极其敏感，一笔委托从客户端到柜台、交易所、再回报，中间要经过网关、风控、订单、清算十几个服务。用户投诉“委托没成交”“成交回报慢”，传统做法是拉一堆日志人工比对，动辄几十分钟，还未必能找到根因。链路追踪把整笔交易按 trace id 串起来，一眼看出卡在哪个环节、每个环节花了多少毫秒。

全链路埋点

埋点要覆盖完整，链路才不会断：

• 网关入口生成 trace id，注入 HTTP 头贯穿所有下游服务
• 数据库、缓存、消息队列（Kafka/RocketMQ）的调用都要埋点，否则链路会在这里断掉
• 异步消息必须传播 trace context，消费者侧要能恢复出父 span

尤其要注意异步场景：委托走 MQ 异步回报，如果生产者不把 trace context 写进消息头，消费者拿到的是新 trace，链路就断了。

从订单号反查 trace

1. 输入订单号或委托编号，在日志里反查出对应的 trace id
2. 打开该 trace 的火焰图/水合视图，看每个 span 的耗时分布
3. 定位到耗时最长或报错的 span，展开看关联日志和错误详情

第 2、3 步的关键是水合要快：交易链路 span 多、跨度大，如果一条 trace 要等几秒才渲染出来，排查体验就废了。炬鲸 OBSERVE 对交易场景做了针对性优化，大跨度 trace 也能秒级打开。

性能与成本控制

交易量大的时候全量采集不现实：

• 采样：正常交易按 1% 采样，异常（报错、超时）交易 100% 保留
• 存储：热数据放内存/SSD 供秒级查询，历史数据归档冷存储
• 告警：单笔委托端到端耗时超过阈值（如 300ms）自动告警，按用户、通道维度聚合

极端行情下的稳定性

熊市或利好突袭时，交易量能瞬间翻几倍，此时可观测系统的压力不亚于交易系统本身。提前做两件事：一是对采集管道做压测，确认能扛住峰值写入；二是把采样策略做成动态的——平时正常采样，检测到流量突增时自动提高采样比例或临时全量保留异常交易，避免关键时刻丢链路。

落地效果与建议

某券商上线后，交易类故障平均定位时间从 40 分钟降到 5 分钟以内，报障工单量下降约三成。建议先从核心交易链路（委托、成交、清算）做起，跑顺了再扩到行情、账户等周边链路；指标上优先盯端到端延迟的分位数（P50/P95/P99），而不是平均值，平均值会掩盖长尾问题。告警阈值建议用 P99 而不是平均值：平均值被大量快单稀释，即使少数慢单已经拖垮了用户体验，平均值看起来依然正常。