证券交易系统的可观测性落地：一个毫秒级排查案例

背景：开盘即告警

某券商核心交易通道在周一开盘 9:30 的瞬间，委托下单接口 P99 延迟从平时的 60ms 飙到 900ms，触发了延迟告警，随后部分委托返回超时。交易系统对毫秒敏感，每多一秒抖动都可能造成客户投诉甚至合规风险。这个案例的价值在于：它展示了一条没有专属可观测平台的团队，是如何被一个「连接池耗尽」的老问题反复击倒的，以及用对工具之后排查路径如何被缩短到十几分钟。

交易系统的可观测难点

交易链路和普通 Web 服务有三个不同：一是高峰高度集中，开盘和收盘几分钟内吞吐是平时的几十倍；二是链路长，一个委托要经过接入网关、风控、资金校验、报盘、交易所回执多个环节；三是排查窗口极短，问题拖到收盘才查清就等于没有意义。因此交易场景的埋点必须覆盖每一跳，且告警阈值要按「分钟级」而不是「小时级」设计。

交易场景该盯哪些指标

别只盯 CPU 和内存。交易系统真正要紧的是业务指标：每通道的报单吞吐（笔/秒）、报单延迟（含网络往返）、撤单成功率、成交回报时延、以及委托状态机里每一步的耗时分布。这些指标要按「通道号」「委托类型」「客户类型」三个维度拆分，出问题时才能一眼看出是哪个通道、哪类委托在慢。基础指标（CPU、GC、连接池、磁盘 IO）作为辅助，用于解释业务指标为什么异常。

先看指标，锁定范围

值班同事先在 OBSERVE 里看了三张图：下单接口的 P99 延迟、单机 CPU 使用率、数据库连接数。前两者在 9:30 同时冲高，但 CPU 只到 60%，并没有打满；可疑的是数据库连接数曲线在 9:30 前已经顶到连接池上限并持续徘徊。这提示瓶颈不在计算，而在资源等待——这是交易系统里最容易被忽略、又最致命的一类问题。

再用 Trace 定位到具体调用

取一个慢请求的 trace_id，展开调用链后发现：订单服务调用风控服务很快（8ms），但「保存委托」这一步的数据库连接获取花了 720ms。结合指标基本可以锁定——连接池耗尽，线程在等连接，而不是查询本身慢。链路追踪在这里的价值是：把「慢」从「整个请求慢」分解到「具体某一步慢」，从而排除了风控、报盘等环节的嫌疑。

用日志坐实根因

按 trace_id 过滤日志，看到大量 Timeout waiting for idle connection 报错，且都集中在开盘前 5 秒。原因清楚了：开盘前行情预热脚本和批量撤单任务同时启动，占满了连接池；开盘瞬间的真实委托进来只能排队等连接。三件套的闭环是：指标告诉你在哪个维度出问题，Trace 告诉你是哪一跳慢，日志告诉你为什么慢。

落地改进

• 给批量任务单独分配连接池，与实时交易隔离，避免批处理抢占在线资源。
• 把「连接等待时间」作为核心指标单独监控，超过 50ms 就告警，而不是等 P99 延迟飙升才发现。
• 埋点层面：交易链路的每个环节打上业务属性（委托类型、通道号、客户类型），告警按通道维度聚合，一眼看出是哪个通道出事。
• 告警分层：把延迟告警拆成「预警」（>200ms）和「严重」（>500ms）两档，配不同的通知渠道和响应人。
• 留存合规：交易日志和委托流水按监管要求保留足够时长并做防篡改，OBSERVE 支持冷热分层存储，在合规和成本之间取平衡。

总结下来，交易系统的可观测性没有捷径——先把业务指标定义清楚，再让 Trace 和日志具备可下钻的关联能力，告警按通道和分层设计。工具到位之后，剩下的就是把埋点当成日常习惯。