金融交易系统故障定位：链路追踪 + 日志关联的落地方案

交易系统的可观测难点

交易系统难排查，难在三个地方：

1. 链路长、跨系统多：一笔交易从网关、风控、账户、清算到核心账务，可能横跨十几个服务，任何一个环节超时都可能导致整笔失败。
2. 对时延敏感：排查手段本身不能拖慢交易。埋点要轻，采样要可控，日志不能阻塞业务线程。
3. 合规留存：交易日志通常要留存 5 年以上，且要能快速检索取证，存储成本和检索性能都要精打细算。

这三条决定了金融场景的可观测方案不能照搬互联网大厂的「全量采集、事后分析」，而要做取舍。目标不是堆最多的遥测数据，而是用最短路径回答「这笔交易为什么失败」，同时不拖慢交易、不撑爆存储。

全链路追踪：从网关到账务核心

落地的关键是统一 trace_id。在网关入口生成 trace_id，通过 HTTP 头、消息队列 header 层层传递，保证一笔交易在所有系统里是同一个 id。炬鲸 OBSERVE 支持 OTLP 协议，Java/Go 服务用 SDK 或 Agent 自动接入，老系统通过日志采集端（如 Vector）从日志里解析 trace_id 补全链路。

链路断裂最常见的地方是协议边界：HTTP 转消息队列、消息队列到批处理、批处理再回调，任何一跳忘了透传 trace context，链路就断在那一层。排查时先审计这些边界，因为被遗忘的跳往往正是最先出问题的地方。

针对时延敏感，建议：

• 采样率分级：核心链路 100% 采样，非核心按比例采样
• 异步上报，失败不阻塞业务
• 对热点 span 关注尾延迟（P99），别只看平均值——20ms 的平均值会掩盖千分之一的 800ms 异常，而那正是真正丢单的请求

金融场景还有个特殊点：异步结算、对账这类批处理任务没有实时请求上下文可继承，需要单独建立链路关联。批处理任务从队列里取到一笔交易时，把该交易的 trace_id 记为 span 属性，异步这条腿才能在链路视图里挂回原始交易。

日志与 Trace 关联的排查实战

故障发生时，标准动作是三步：

1. 从监控看到某服务的 P99 延迟突增，下钻到错误日志
2. 在日志详情页点「查看链路」，定位到是哪个下游调用变慢（比如清算接口从 20ms 涨到 800ms）
3. 在链路里对比同一时段成功与失败请求的差异，锁定是参数问题还是下游容量问题

这个流程的关键是日志和 trace 的双向关联都通畅：日志能跳链路，链路里的 span 能反查日志。少了任何一边，排查就得靠人肉 grep。在交易系统里，这个差距是用钱衡量的——每多花一分钟人工排查，就是渠道多一分钟不可用或降级。这套动作要在演练环境反复练习，而不是等故障了才第一次上手。

合规留存与告警分级

交易日志留存时间长，建议冷热分层：近 7 天热数据可秒级检索，7 天到 2 年转温存储，2 年以上归档到对象存储，需要时再恢复检索。归档前做索引快照，保证取证时能还原给监管。

告警要分级，避免告警疲劳：

• P0：账务核心、清算链路不可用，电话 + 短信直达值班
• P1：核心交易错误率超阈值，企业微信 + Webhook
• P2：非核心服务异常，仅记录看板，不打扰

告警规则要挂在服务维度而非机器维度，否则扩缩容后规则容易失效。这套方案在多家券商和支付机构的交易线路上验证过，核心是「快定位、轻打扰、能留证」。