金融机构的可观测性要同时满足三个约束：数据不出域、链路可审计、故障分钟级定位。本文给出核心交易链路埋点方案、告警分级降噪策略和分阶段落地节奏。
金融场景的可观测性不能照搬互联网那套。它被三件事约束：一是数据主权，交易、账户相关日志通常不允许出内网，更不能上公有云；二是审计要求，谁在什么时候改了什么配置、触发了什么告警，都要留痕可回溯；三是定位时效，核心交易链路的故障以分钟计，慢一分钟就是一笔真实损失。方案设计必须从这三条出发，而不是从工具功能出发。
落地时先定边界：采集端、存储、查询全部部署在内网，敏感字段（卡号、身份证号、手机号）在采集侧脱敏，只保留末四位用于排障关联。配置一套脱敏规则在入口统一执行，而不是让每个应用自己处理，避免遗漏。
审计分两条线：一条是数据审计，日志按角色授权查询，任何人的检索动作都记录（谁、查了什么字段、时间范围）；另一条是变更审计，告警规则、静默窗口、仪表盘的每次修改保留版本，出事故时能还原“当时到底是谁的配置生效”。这两条在验收检查里基本是必查项。
核心交易链路通常跨网关、核心系统、支付通道、账务四五个系统，一次超时要定位在哪一跳，靠日志对时间戳基本不可行。方案是给交易链路统一埋点，用全局 trace_id 贯穿请求，关键 span 上标注交易类型、金额区间、渠道等业务标签。出现超时后，先在链路页面按交易类型和耗时倒序过滤，直接看到是网关转发慢还是账务写库慢，再下钻到该 span 的日志和指标。
给两条实践建议：第一，埋点以交易状态机为骨架，每个状态迁移一个 span，别按方法名硬埋；第二，金额、账号等业务字段作为 span 属性打标，但务必走脱敏，否则合规这关过不去。
金融场景的告警宁可少而准，不能多而乱。按影响面分四级：P1 核心交易不可用或错误率超阈值，电话 + 短信直达值班；P2 单一通道或降级路径异常，短信；P3 性能劣化但未影响业务，群消息；P4 趋势性预警，仅记录。降噪靠两招：同一根因的告警聚合（同一服务同一指标的抖动合并成一条），以及静默窗口与升级策略（持续 N 分钟未恢复自动升到上一级）。这样告警量能压掉七成，值班人员才不会对告警麻木。
不建议一上来全量接入。第一阶段（2 周）先接核心交易链路和网关，跑通采集、链路、告警闭环；第二阶段（1 个月）扩展到全部核心系统，补充业务标签和脱敏规则；第三阶段（1 个季度）做告警分级优化和容量/趋势分析。每一步都有明确的验收标准：能定位、能审计、能降噪，再谈智能化和 AIOps。