一笔支付从发起到记账怎么追：金融交易链路的可观测性

金融场景的可观测性有什么不一样

普通业务的可观测性主要服务排障，金融还要叠两层：审计合规和交易一致性。一笔支付从网关、风控、账务到清算，横跨十来个服务，出问题不只是「慢了」，可能是「钱对不上」。所以监控不能只看技术指标，还得盯着业务指标——成功率、金额一致性、对账差异——而且每一步都要留痕。

用 trace_id 贯穿整条链路

做法很直接：支付请求在网关入口生成一个全局唯一的 trade_id，让它同时充当 trace_id 贯穿下游所有服务。这样一条链路里，从鉴权到记账的每一个 span 都能串起来，任意一笔交易都能一键还原完整路径。

关键点有两个：一是 trade_id 要在消息队列、异步任务里显式传递，别依赖线程上下文；二是把关键业务字段挂到 span 属性上，比如 order.amount、order.channel、order.status，排查时按金额、渠道过滤比按耗时快得多。

关键指标与告警

技术指标之外，至少要建这几条业务指标：

• 支付成功率（按渠道、按金额档位拆分）；
• 端到端耗时 P95/P99；
• 对账差异金额与笔数；
• 超时未决单数量。

告警要分级。成功率跌破阈值属于 P1，直接通知值班；对账差异属于 P0，必须电话升级。告警详情里带上 trade_id 和 trace 链接，收到告警点一下就能看到这条交易在哪个服务、哪个 span 上出的问题，不用再翻日志。

脱敏与审计日志

金融日志里全是敏感数据：卡号、手机号、身份证号。写入 OBSERVE 前必须在采集端做脱敏，用正则把卡号中间段打码、手机号保留前 3 后 4。脱敏规则要在数据进库之前执行，而不是只在查询展示时遮一下——后者数据已经落库，合规上站不住。

审计日志单独存一份，和普通运行日志分开：谁在什么时间查了哪笔交易、改了什么配置，都要记录且不可篡改。审计日志按监管要求保留，别和可观测数据混在一套过期策略里。