金融交易链路排障：用 traceId 把日志和慢接口串起来

金融场景的故障排查有个特点：一笔交易要跨网关、账户、风控、支付等多个服务，超时发生在哪一层，光看单个服务的日志是看不出来的。这篇文章用一笔订单超时为例，讲一套可落地的排障顺序。

场景：一笔订单超时

用户反馈支付卡了 8 秒才返回。运维在监控大盘上看到支付服务的 P99 延迟升高，但单看支付服务日志没有明显报错——问题可能在上游账户服务，也可能在风控的同步调用里。这类「跨服务慢」的排查，核心是先把同一条交易链路上的所有记录串起来。炬鲸 OBSERVE 的做法是让业务日志和链路日志都带上同一个 traceId。

用 traceId 关联日志与链路

在业务日志里，traceId 写在 Log4j2 的 [traceId] 位置；在链路日志里，它作为 JSON 字段上报。两边的 traceId 一致，就能互相跳转。排查步骤：

1. 在 Tracing 页按 path LIKE "%/pay%" 过滤，找到这笔订单的调用记录；
2. 看这条链路的 cost 和 code，确认慢在哪一跳；
3. 复制 traceId，回到 Service 页用 traceId="..." 查这条链路上的全部业务日志；
4. 逐跳看请求体、响应体和耗时，定位是风控规则慢了，还是账户服务的数据库查询慢了。

一套操作下来，从「不知道哪层慢」到「锁定某服务某 SQL」，通常几分钟。

阈值告警先于用户发现

等用户投诉再排查是被动的。建议配两条规则，让平台先发现问题：

• 业务侧：level="ERROR"，窗口 5 分钟，阈值 20 条；
• 链路侧：code>=500，窗口 5 分钟，阈值 10 条。

规则每分钟跑一次，命中后推送到通知渠道，并支持静默（变更窗口期内静默 30 分钟）和冷却，避免告警风暴。对金融团队来说，这两条规则基本就是「错误预算」的最小实现。

隔离与审计兜底

金融行业对数据隔离和合规有硬要求。炬鲸 OBSERVE 的多租户是 tenant_id 硬隔离，采集 Token 分环境分治；平台操作有审计留痕；查询时间窗和日写入/存储配额都可控，超配额先告警、再拒写，查询不受影响。配合保留策略（按套餐自动清理过期日志），能同时满足排障需求和合规留痕。这套「traceId 串联 + 阈值告警 + 隔离审计」的组合，对支付、信贷、证券等对交易链路敏感的业务都适用。