证券核心交易系统的可观测性改造实践

证券核心交易系统的可观测性，和普通互联网应用不是一个量级的问题。

交易系统的观测难点

• 延迟敏感：委托到回报的端到端延迟以毫秒计，监控本身带来的开销都要被审视。
• 链路长、组件杂：一笔委托要经过接入网关、风控、撮合、清算、回报多个环节，跨多个进程甚至跨机房。
• 强合规：日志要可审计、可留存（通常 5 年以上），篡改要能发现，监管检查时能快速调出任意一笔委托的完整上下文。

这三点决定了：这里的可观测性改造，不能只装个采集 Agent 就完事。

用链路追踪串起一笔委托

改造的第一件事，是把“一笔委托”变成一条可追踪的 trace。关键做法：

1. 统一 trace 上下文：在接入网关生成 trace_id，通过消息头/请求头往下游传播，风控、撮合、清算每个环节都挂在同一个 trace 下。
2. 业务字段注入 span：把 order_id、account_id、security_code 作为 span 属性写入，排查时能按“订单号”直接反查整条链路，而不是靠时间瞎猜。
3. 关键点打标：在撮合、风控拒绝、回报推送这些关键节点打上语义化的 span 事件，记录耗时和结果码。

改造后，客服报“某笔单子没成交”，运维可以拿订单号在炬鲸里搜 trace，秒级看到这笔单在哪个环节卡住、耗时多少、结果码是什么，排查时间从小时级降到分钟级。

日志留存与审计合规

交易日志的合规要求，比“能查到”高得多：

• 完整性：日志从产生到落盘不得丢失，采集端要做本地缓冲与断点续传。
• 防篡改：开启日志的哈希链/签名，任何一条被改动都能校验出来，满足审计对“不可抵赖”的要求。
• 分级留存：交易明细日志留存 5 年以上（冷热分层，热数据近实时可查，冷数据归档到低成本存储）；普通运行日志 90 天即可。

炬鲸提供“日志审计模式”，对指定日志流开启签名与防篡改校验，导出时带完整证据链。

告警分级与 SLO

交易系统的告警不能“一刀切”。先定义 SLO，再挂告警：

• 错误率：撮合成功率 ≥ 99.99%，风控拒绝不算错误。
• 延迟：委托到回报 P99 ≤ 200ms。
• 可用性：撮合服务月度可用性 ≥ 99.99%。

告警分级：

| 级别 | 触发条件 | 响应要求 |
| --- | --- | --- |
| P0 | 撮合可用性跌破 99.99%、延迟 P99 超阈值 2 倍 | 5 分钟内拉起应急，电话+短信 |
| P1 | 单服务错误率 > 1%、队列积压超阈值 | 15 分钟内响应 |
| P2 | 磁盘/内存水位超 80%、慢查询增多 | 30 分钟内处理 |

每个级别绑定明确的 SLO 指标，告警规则直接挂在 SLO 上，而不是散落的阈值。

观测数据的分层采集

交易系统的观测数据分三层采集，避免互相干扰：

• 基础设施层：主机、网络、中间件的指标用轻量 Agent 采，秒级粒度，不侵入业务进程。
• 应用层：链路与业务日志由 SDK 直接上报，走 OTLP，与应用进程同生命周期。
• 旁路层：撮合等核心进程的本地日志文件由 Agent 异步采集，尽量不增加主进程开销。

三层数据在炬鲸里按 trace_id 和时间戳关联，排查时能从“一笔委托”一路下钻到“某台机器的 CPU 抖动”。

落地经验

• 先链路后指标：交易系统先打通链路，很多指标问题会随着链路清晰自动暴露。
• 压测先行：改造前后各跑一轮全链路压测，对比延迟开销，确保观测本身不成为瓶颈。
• 合规留档从第一天做：日志留存和防篡改别等验收前才补，第一天就按审计标准配置。
• 监管口径对齐：留存周期、可检索字段提前和合规部门确认，避免上线后返工。

证券交易系统的可观测性，本质是把“一笔委托的完整生命周期”变得可追踪、可审计、可回溯。这是合规要求，更是排查效率的硬需求。