证券核心交易系统可观测性建设：从分钟级排障到秒级定位

交易系统可观测性的难点

核心交易系统的特点很明确：延迟敏感（毫秒级）、并发峰值集中（开盘/收盘）、链路长（柜台 → 报盘 → 撮合 → 清算）、数据一致性要求高。传统"出问题翻日志"在这里行不通——日志本身可能拖慢交易主链路，而且开盘时没人有时间翻日志。

我们的思路是把可观测性拆成"在线"和"离线"两套：在线信号要求低开销、可实时查询，用于实时告警和快速定位；离线信号用于事后复盘和合规留痕。

三信号的分工

• Metrics：监控线程池、队列深度、订单耗时分布、撮合延迟，采样率 100%，是告警的第一来源。
• Trace：只对抽样请求（默认 5%，关键订单 100%）做链路追踪，覆盖柜台、网关、撮合、风控、清算全链路，用来定位慢在哪一跳。
• Logs：结构化日志，按 traceId 关联，只在关键节点（订单状态变更、异常、风控拒绝）打印，避免热路径刷屏。

开盘高峰的监控设计

开盘前 15 分钟把采样率临时调高到 30%，开盘结束后降回 5%，用 OBSERVE 的动态采样规则自动切换。告警阈值按"相对基线"而不是固定值：CPU、队列深度用同比上周同时段的值做基线，超过基线 2 倍才告警，避免开盘天然高峰误报。

告警分级：P0（下单链路不可用、延迟超阈值）电话 + 短信，P1（降级、队列积压）短信 + 群通知，P2（资源水位）仅记录。

一次真实排障

某交易日开盘 5 分钟，报盘网关延迟从 3ms 涨到 40ms。告警触发后，值班工程师直接从 Trace 面板按延迟排序，发现 90% 的慢请求都卡在风控服务的"名单校验"这一步；再点进对应 span 看日志，发现校验缓存未命中率从 1% 涨到 90%——原因是上游数据同步任务在开盘前失败，缓存没预热。定位到根因用时约 40 秒，回退到前一天快照后恢复。

落地的几条建议

• 关键交易订单做 100% 采样，普通订单按比例采样，用 OBSERVE 的采样策略区分。
• 热路径上的日志级别用 debug 会拖慢主链路，正式环境只开 info/error，debug 用动态开关按需打开。
• 告警必须和链路联动：P0 告警自动附带当时的高延迟链路快照，值班人员打开告警就能看到现场。