金融核心交易系统的链路追踪与毫秒级故障定位

金融场景对追踪的额外要求

金融核心交易系统对可观测性的要求比普通业务严得多：一笔请求跨越十几个微服务，涉及账户、清算、风控、渠道多个系统；监管要求关键交易可审计、可回溯；故障的每一秒都是真金白银。普通系统的“概率采样 + 事后翻日志”在这里不够用。

采样策略：关键交易 100%，其他按比例

全量采集所有 trace 成本太高，但金融系统必须保证关键交易一笔不漏。炬鲸 OBSERVE 支持按规则采样：

sampling:
  - name: critical-tx
    match: attributes["tx_type"] in ("transfer", "settlement")
    rate: 1.0
  - name: default
    rate: 0.1

这样既保证监管审计需要的关键交易全量留痕，又把存储成本控制在可接受范围。

TraceID 透传规范

金融系统常见“半截链路”：前端到网关有 trace，网关往后就断了。根因是中间件没透传 trace 上下文。落地时要把 TraceID 透传写进接入规范：

• 所有 HTTP 客户端必须注入 traceparent / X-B3-TraceId 头；
• 消息队列（Kafka / RocketMQ）在消息头里携带 trace 上下文；
• 定时任务、异步线程要显式传递 SpanContext，否则子任务成“孤儿”。

规范要在代码评审里强制检查，光靠自觉一定会断。

一次真实的故障定位

某天 14:03，支付成功率从 99.7% 掉到 96%，告警触发。值班同学在炬鲸 OBSERVE 里按“支付失败”筛选 trace，按耗时排序，发现超时集中在 settlement-service 调用 ledger-service 这一跳：

• 用 trace 瀑布图看到，ledger-service 的 DB 查询从 8ms 涨到 900ms；
• 关联该时间段的数据库慢查询日志，定位到一条未走索引的 SQL；
• 全链路耗时看板确认：故障影响范围只在该接口，未扩散。

从告警到定位根因，用时 6 分钟。事后把这条慢 SQL 对应的告警规则补上，同类问题下次直接自动告警。

落地建议

• 关键交易路径（转账、清算、对账）强制 100% 采样并设定保留期，满足审计；
• 把 TraceID 透传写进接入规范，用 CI 检查而非人工自觉；
• 建立“trace + 慢查询 + 指标”三者的联动查询习惯，跨页面对齐时间线是定位的关键。

金融系统的可观测性目标不是“好看的大屏”，而是“下次故障，一分钟内知道卡在哪一跳”。