证券交易系统可观测性方案：从交易延迟到故障定位

交易系统对延迟极度敏感，一次故障可能带来真金白银的损失。相比"出问题再查日志"，更有效的做法是提前把可观测性做扎实。这篇文章给出一个可直接落地的方案框架。

以延迟为核心指标的监控体系

交易链路上，延迟是最高优先级指标。建议按环节拆分采集：网关接收、风控校验、撮合、回报，每个环节都记录 latency，并在指标侧聚合 P50/P99/P999：

| stats p50(latency), p99(latency), p999(latency) by step

阈值建议分两级：P99 超过 50ms 告警提示，超过 100ms 立即告警。延迟抖动比绝对值的突然变化更值得警惕，可对 P99 做环比检测，防止"温水煮青蛙"式的缓慢劣化。除了延迟，每个环节还要看错误率和吞吐量，三者一起看才能判断是"变慢"还是"变错"。

用 trace_id 串起一笔订单的一生

每笔订单从客户端下单到回报，用一个 order_id / trace_id 贯穿。故障时只要拿到这个 id，就能在链路追踪页还原它经过的每一个节点、每一跳耗时，判断是网络抖动、下游阻塞还是自身处理慢。这在"偶发延迟、难以复现"的场景里尤其管用——把偶发订单的 trace 存下来，事后回放，往往能定位到普通监控发现不了的间歇性问题。

告警分级与降噪

金融系统告警多、噪音大，容易"狼来了"。建议三层分级：

• P0：撮合不可用、延迟 P99 持续超阈值 5 分钟 → 电话 + 短信
• P1：单节点异常、错误率突增 → 企业微信/钉钉
• P2：资源水位偏高、慢查询增多 → 记录待办，不打扰人

配合告警聚合和静默规则，把同一根因的告警合并成一条，避免告警风暴。分级要和值班排班、升级路径绑定，让每条告警都有明确的"谁来接、接不住找谁"。

故障复盘与容量规划

可观测数据不止用于救火。定期拉取交易高峰期数据做容量分析，提前识别瓶颈；每次故障后导出完整 trace 和指标，形成复盘报告，把经验固化进告警规则。这样系统越跑越稳，而不是每次故障都从头查起。复盘的重点不是追责，而是找出"监控为什么没拦住"，把盲区补上，下一次同类故障就能被提前发现。另外，交易系统有审计留痕的合规要求，日志要能长时间留存、按需导出，这也是方案里必须覆盖的一环。