金融交易全链路追踪：从一笔转账定位到三个慢调用

金融场景的三个痛点

交易链路长：一笔转账从渠道、核心、支付、清算到对账，跨 5 个以上系统，每个系统还可能调消息队列、缓存和外部支付通道。中间环节一多，出问题时最怕两件事：不知道慢在哪一跳，以及查了半天发现各系统的日志对不上同一笔交易。合规上还要求问题能追溯到单笔交易，审计留痕。

方案：统一 Trace ID 贯穿全链路

在网关入口按 W3C Trace Context 标准生成 traceparent 头，所有系统无条件透传，谁都不许改。同时在入口把交易流水号与 trace ID 建立映射写进标签，运维拿到一笔交易号，反查 trace ID，直接看到整条调用链——这解决了「日志对不上」的核心问题。

采样策略分三层：正常交易按 10% 采样；超过 500ms 的慢交易 100% 采样（tail-based sampling）；报错交易 100% 采样。这样既控制存储成本，又保证「凡是值得查的，一定采到了」。

关键配置

网关和每个服务统一注入：

trace:
  propagate: [traceparent, tracestate]
  sampling:
    default: 0.1
    tail:
      enabled: true
      latency_threshold: 500ms
    on_error: always

配合炬鲸的标签体系：txn_id（交易号）、channel（渠道）、amount（金额档位）、product（产品线），排查时按这些维度过滤。告警也复用这些标签，把「支付通道 P99 超阈值」这类告警直接关联到具体的交易样本。

落地效果与建议

上线后，一笔转账从受理到完成全链路可见，慢在哪一跳一目了然。一个典型案例：某支付通道 P99 延迟 1.2 秒，靠 trace 定位到是对端接口超时后重试导致，切到备用通道后 P99 降到 300ms，全程没有翻一条日志。

落地分三步：先打通核心系统和支付系统（占交易量九成，见效最快），再覆盖渠道和对账；采样先松后紧，等数据量可控再提高采样率；最后把 trace ID 写进业务日志和返回报文头，客户报障时凭一个单号就能直接定位，省掉大量来回沟通。