证券核心交易系统的可观测性落地实践

交易系统的特殊性

交易链路和普通 Web 系统最大的区别：峰值不规律（集合竞价、收盘前几分钟）、延迟敏感（一笔委托超过几百毫秒就是事故）、故障窗口极短（盘中不能停机排查）。这意味着可观测系统必须做到三件事：采集开销足够低、数据实时可查、告警按交易时段区分优先级。

架构设计

采用分层采集：应用内用 OpenTelemetry SDK 埋点（委托、撤单、成交回报三类关键 span），网关层抓全量请求，数据库和消息中间件（以及金证/恒生的柜台系统接口）用旁路抓包或日志解析。所有数据统一进 OBSERVE，链路和日志用同一个 trace_id 关联。

关键设计是采样策略：正常请求 5% 采样，但错误请求、超过 200ms 的慢请求 100% 保留——用 tail-based 采样实现，避免漏掉关键异常。

关键指标与阈值

盘中监控的核心指标就五个：

| 指标 | 说明 | 告警阈值 |
|---|---|---|
| 委托时延 P99 | 从接入到柜台响应 | > 300ms |
| 成交回报延迟 | 柜台回报到客户端 | > 500ms |
| 报错率 | 5xx / 业务拒绝 | > 0.5% |
| 消息积压 | 队列消费 lag | > 1000 条 |
| 数据库连接数 | 连接池占用 | > 80% |

阈值要按交易时段分档：集合竞价和收盘前允许短暂抖动，开盘后必须严格。告警分级：P0（影响交易）电话 + 短信，P1（性能劣化）IM 群，P2（趋势预警）邮件。

一个盘前慢查询案例

某券商上线新版本后，开盘前压力测试发现委托时延 P99 从 80ms 涨到 400ms。用 OBSERVE 的链路查询按 trace_id 展开，定位到慢在“资金校验”这一步调用了新接入的风控服务，而风控服务每次请求都做一次全表扫描。进一步看日志，发现是风控服务的缓存没生效——新版本改了一个配置项，缓存 key 拼错了。修复配置后 P99 回落到 90ms。整个过程从发现到定位不到 15 分钟，没有重启任何交易进程。

故障演练

每季度做一次“双盲”演练：随机注入故障（数据库主从切换、队列堆积、某服务 CPU 打满），让值班人员只靠 OBSERVE 定位。考核标准不是“多久修复”，而是“多久定位到根因”。三个月下来，平均定位时间从 40 分钟降到 8 分钟。

建议

金融可观测的关键不是堆仪表盘，而是把“定位根因”变成可度量的流程：指标触发告警 → 链路下钻 → 日志确认根因，三步要在一个界面里闭环。如果还停留在“告警响了然后人肉翻日志”，说明可观测还没真正落地。