金融行业可观测性实践：用链路追踪定位跨系统慢交易

银行和券商的典型问题：一笔转账或下单请求要穿过渠道、核心、清算、风控四五个系统，用户侧显示慢，但每个系统都说「我这边正常」。没有链路追踪，这种问题只能靠开线上会议、逐个系统翻日志来查，少则半天多则几天。

场景：一笔「慢交易」的定位

以一笔 8 秒才返回的转账为例。传统排查是各系统分别查日志，然后对时间戳，效率很低。接入链路追踪后，做法完全不同：

1. 在告警里点开这笔交易，Trace 已经串联了渠道 → 核心 → 风控 → 清算的完整调用
2. 火焰图显示 7.2 秒耗在风控系统的 risk.score 这个 Span 上
3. 展开该 Span，日志自动带出上下文：model=anti-fraud-v3 timeout
4. 顺藤摸瓜发现风控调用外部反欺诈模型的服务超时且没设降级，拖垮了整条链

从发现问题到定位根因，10 分钟。这就是「把三类数据打通」在金融场景里的直接价值。

为什么金融场景必须做采样策略

金融交易量巨大，全量采集 Trace 的存储成本很快失控，而且大部分 Trace 都是「正常快速请求」，没有排查价值。建议的采样组合：

• 全量采集带 error 标记的 Span（错误是少数，必须留全）
• 按延迟采样：latency > 500ms 的请求 100% 保留
• 正常请求按 1% 概率采样兜底
• 关键交易（转账、下单、授信）用自定义 attribute 强制全采

这套组合在真实生产里能把 Trace 存储成本压到全量的 5% 以内，同时保证出问题时一定有数据。

审计与合规

金融监管对「可追溯」有硬性要求。炬鲸 OBSERVE 的审计日志独立存储、不可篡改，记录谁在什么时间用哪个账号查询了哪些日志/Trace，保留期可配到符合监管要求的年限。敏感字段脱敏默认开启，银行卡号、身份证号在展示和导出时自动打码，避免数据泄露风险。

落地节奏建议

不建议一次性把全行系统都接入。推荐路径：

1. 先选 1-2 个交易量适中、问题多发的系统试点（比如支付网关、清算）
2. 用 OTel agent 无侵入接入，跑两周看效果
3. 形成《接入规范》和告警基线后，再横向铺开

可观测性在金融行业不是「锦上添花」，它直接关系故障恢复时间（MTTR）和监管合规。早接入的系统，遇到问题时的从容程度完全不一样。