金融机构既要秒级定位交易故障，又要满足监管审计留痕。本文讲如何用链路追踪串起交易全路径，并把审计日志、权限分级、日志脱敏与 SLO 纳入同一套可观测体系，附落地步骤。
一笔支付跨越网关、风控、账务、清算十几个服务，任何一个环节慢或报错都可能引发投诉甚至资损。排查时如果没有链路追踪，只能靠人工翻各系统日志对时间戳，一场事故可能查上几小时。对面向 C 端的支付、理财、证券行情这类业务，每多一分钟不可用，都是真金白银的损失。
同时，监管对审计有硬性要求：谁在什么时间查过什么数据、改过什么配置，都必须留痕可追溯。这要求可观测平台不只是「看」，还要「记」和「管」——记录每一次敏感操作，管理每一个人的权限。
给交易入口注入 trace id，让它随调用链一路透传。炬鲸 OBSERVE 把一笔交易的所有 span 按时间轴展开，能看到每个服务耗时、依赖关系、异常节点：
gateway (12ms) → risk-control (48ms) → account (230ms) → settlement (1.2s)
└── db.query (215ms) ← 慢点上例里 settlement 的 db.query 占了 215ms，是整条链路的瓶颈。没有 trace，这个信息散落在几十台机器的日志里，几乎不可见；有了 trace，几秒就能定位到具体服务和具体 SQL。
更实用的是把 trace 和业务上下文绑在一起：把交易单号、用户 ID 作为 span 属性注入，出问题时直接用「这笔交易单号」反查整条链路，而不是在日志里 grep 时间戳。这是金融场景排查效率的分水岭。
金融日志里常见手机号、身份证号、卡号、Token。这些字段一旦进入平台存储，就会带来额外的合规负担——存储、访问、删除都要按敏感数据标准管理。
最省事的做法是在接入层就脱敏：用 Collector 的 redaction processor，或应用侧结构化日志直接不打印敏感字段。原则是「能不打就不打，实在要打就打码」。把脱敏写成接入规范的一部分，而不是上线后才发现问题再补救。
监管审计要求「操作可追溯」。炬鲸 OBSERVE 对登录、查询、导出、Token 轮换等敏感操作全部记录审计日志，支持按人、按时间、按操作检索。权限上采用分级模型：
数据留存策略可配置：交易链路与审计日志按监管要求保留 N 年，普通应用日志可设更短周期，控制存储成本。别小看这一点——全量日志无限留存，存储账单会在几个月后给你一个「惊喜」。
告警要有依据，不能拍脑袋设阈值。给核心交易链路定义 SLO：比如「99.9% 的交易在 500ms 内完成」。炬鲸 OBSERVE 按 SLO 计算错误预算（error budget），预算耗尽前预警，而不是等到真出故障才响。
有了 SLO，团队争论「要不要现在修」就有了共同语言——看错误预算还剩多少，而不是各执一词。
金融场景的告警要更「狠」：错误率、交易成功率、P99 延迟达到阈值即触发，P0 直接电话 + 短信双通道。配合链路追踪，收到告警后能直接从告警跳到对应 trace，省去定位环节，把「从告警到定位」压缩到分钟级。
建议给核心交易链路单独建一套告警规则，阈值比外围系统更严格，并且把交易成功率作为北极星指标持续盯。