金融交易链路可观测方案：从交易单号到根因的排查闭环

金融交易系统的可观测，难点不在采集，而在「单笔慢交易」这种被统计淹没的故障。这篇文章给一套完整方案：怎么采样、怎么告警、怎么从交易单号一路查到根因，顺便把合规要求一起解决。

交易系统的可观测难点

交易链路短则五六跳，长则十几跳，一笔支付要经过网关、风控、账务、清算多个系统，每一跳都有自己的日志和数据库。出问题时的典型困境是：知道有一笔交易慢了，但不知道慢在哪一跳。比如客户投诉「刚才那笔支付转了 10 秒才成功」，你拿着单号却要在四个系统的日志里来回翻。传统按错误率告警的方式，对「单笔慢交易」几乎无能为力——它会被海量正常交易从统计上淹没。更麻烦的是，交易系统对 trace 的完整性要求高：丢了一个 span，整条链路就拼不起来，只剩碎片拼不出答案。

全链路采样策略

交易系统不能丢 trace，但全量采集成本太高。推荐分层采样：核心交易链路 100% 采集，非核心读接口按 10% 采样，健康检查类请求直接丢弃。三个落地要点：一是采样决策要在入口网关统一做，避免各服务各自采样导致链路断裂；二是把 trace_id 与交易单号双向绑定，排查时能用单号反查 trace，也能从 trace 回到单号；三是把采样率做成动态配置，大促期间临时调高，不用改代码。span 属性也要约定好，每跳都带上交易单号、金额、渠道这些业务字段，告警和排查才有抓手。对于「慢交易」这类低频但关键的事件，还可以在采样之外叠加「尾部采样」——先把数据全量缓存一小段时间，把超过延迟阈值的 trace 挑出来保留，其余丢弃，用很小的成本保住慢交易全貌。

交易级告警与基线

别只用固定阈值，固定阈值要么误报要么漏报。给每类交易建立基线：P50/P95/P99 延迟、成功率，偏离基线 3 倍标准差就告警。单笔交易超过 P99 阈值且涉及金额大于阈值时，触发高级别告警并保留完整 trace 上下文。告警规则示例：

alert: trade_slow
expr: histogram_quantile(0.99, trade_duration) > baseline_p99 * 2
for: 1m
labels:
  severity: warning

for 子句很关键：它过滤掉一次性抖动，只在持续劣化时才告警，而不是被单个倒霉请求触发。基线要按环境分开建立，生产和预发的延迟画像差别很大。通知也要分级：P99 劣化发到值班群，涉及大额交易的告警直接电话升级。

排查闭环：从单号到根因

收到告警后，用交易单号查出 trace_id，展开调用链定位慢跳，再下钻到该跳的日志和 SQL，一条线走完，不用在多个系统之间来回切换。配合审计留痕，所有查询、导出都有记录，满足金融合规对可追溯性的要求。别忘了监管对日志留存的要求——交易相关日志通常要留存 6 个月以上，归档策略要提前设计好，别等审计来查才发现没存。这套闭环把一次慢交易的定位时间从小时级压到分钟级，也让复盘有据可查、能直接交给审计。

这套方案落地后，建议每季度做一次演练：从历史告警里挑几笔慢交易，让值班同事从单号开始独立排查一遍，计时看能否在 10 分钟内定位到根因。演练暴露出来的断点，就是下一步要补的地方。