金融行业可观测性落地：链路追踪与告警降噪的实践方案

金融系统的可观测性难点不在采集，而在两件事：一是交易链路跨十几个系统，出问题定位慢；二是告警太多，值班的人已经麻木。本文给出一个以链路追踪和告警降噪为主线的落地方案。

用链路追踪定位跨系统故障

一笔转账要经过渠道、风控、账务、清算等十几个系统，任何一个环节超时都表现为"交易失败"。光看单系统日志查不出根因，必须靠 Trace 把整条链路串起来。方案要点：

• 统一 traceId 传递：所有系统用 OTel 标准，跨系统透传 traceparent，不要自造请求头。
• 交易号与 traceId 绑定：在入口把交易流水号写入 Span 属性（txn.id），客服报单号就能反查整条链路。
• 关键节点打标：风控决策、账务记账、清算确认各加一个 Span，失败时 recordException 并标 ERROR 状态。

一次真实案例：某交易高峰出现 2% 失败，靠"按 txn.id 反查 + 慢 Span 排序"，5 分钟定位到清算系统某分片连接池耗尽，而此前靠日志排查花了近两个小时。

告警降噪：从几百条到几条

金融系统告警天然多：基础设施、中间件、业务三层叠加，一次故障能触发上百条。降噪按三层做：

第一层抑制：同一指标在收敛窗口内只发一条，重复触发不重复发。第二层聚合：把"同一交易链路、同一根因"的告警归并成一条，附上受影响服务列表。第三层分级：只对 SLO 相关指标做电话/短信级告警，其余走消息队列和看板。

SLO 与指标口径

告警该不该响，最终看 SLO。建议按交易类型分别定义：核心转账可用性目标 99.99%，查询类 99.9%。错误预算按季度核算，燃尽到 80% 时暂停非紧急变更。指标口径要在全公司统一，例如"失败率"必须明确是"失败笔数 / 总笔数"而非"失败请求 / 总请求"，否则不同团队报上来的数字对不上。

审计与值班流程

监管要求日志留存和操作可追溯，因此日志原始数据保留策略要满足监管年限，告警处置全程留痕：谁接警、何时确认、做了哪些动作、何时恢复，全部落到工单。值班流程建议固定成 runbook：接警 → 用链路定位 → 按预案止血 → 事后复盘更新 SLO，每一步都有对应看板和查询模板，减少对个人经验的依赖。