证券交易系统的可观测性建设：从毫秒级延迟到全链路追踪

交易系统为什么难排查

交易链路从行情接入、风控校验、订单路由到报盘回报，环节多，延迟预算以毫秒计。一次偶发的 200ms 抖动，等用户投诉再查往往已经过去几小时，现场早没了。可观测性的价值，在于把"事后复盘"变成"实时可见、可回溯"。

用链路追踪定位毫秒级抖动

交易系统的调用链要打全：行情网关 → 风控 → 撮合/路由 → 报盘 → 回报，每一步都埋 span 并记录耗时。当某请求延迟异常，按 trace id 展开就能直接看到是哪一跳慢：

order-place (12ms)
 ├─ risk-check  (3ms)
 ├─ route-order (2ms)
 ├─ order-ack   (180ms)   ← 抖动点
 └─ notify      (1ms)

上例里 order-ack 慢，就进一步下钻该服务的日志，判断是网络重传、对端报盘网关排队，还是 GC 停顿。span 告诉你"哪里慢"，日志告诉你"为什么慢"。

有个前提要说清楚：交易量级下，全量追踪每笔请求代价很高。用头部采样（head-based sampling）——总是采样慢的、失败的、走关键路径的请求，其余丢弃。固定 100% 采样会把后端压垮，却对真正要关心的那几笔罕见异常没有任何分辨率提升。

守住开盘与收盘两个关键窗口

开盘和收盘是事故高发期，也是监控告警的重点：

• 开盘：盯订单量突增时的错误率、网关连接数、报盘延迟；
• 收盘：盯未回报订单数、风控超时、日志积压。

告警阈值要区分时段：同样的错误率，开盘竞价阶段可能正常，平峰时就是故障。炬鲸 OBSERVE 支持按时间段配置不同阈值，避免误报和漏报——把开盘、收盘、平峰设成三套阈值，比一套固定值靠谱得多，也不会开盘时狂响、午后漏报。

日志与审计合规

交易日志不只是排查工具，更是合规留痕。审计要求日志不可篡改、可追溯、保存期限明确。落地时注意三点：

1. 采集后的日志做只读归档，防止误删、篡改；
2. 关键操作（委托、撤单、风控拦截）打结构化日志，字段固定，便于检索与对账；
3. 与告警联动，风控拦截率异常、撤单量突增时第一时间通知合规与运维。

一条务实的建议

交易系统别追求"全量采集一切"。先聚焦延迟和错误率这两个最能反映业务健康度的指标，把链路打全、告警配准，跑顺之后再逐步扩展其他维度。可观测性投入要能直接回答一个问题：这一笔订单慢在哪、错在哪——答不上来，采集再多也是噪音。每加一个仪表盘、一条告警、一段埋点，都要能回到这个问题上，否则就不该占这个位置。