面向银行与券商的落地实践：从审计合规倒推采集边界与数据脱敏、老单体与新微服务并存下的链路追踪策略、基于数据的应急演练，以及四步落地的节奏建议。
金融系统的可观测性，难点不在技术选型，而在「既要又要」：既要快速定位生产问题，又要满足审计和合规要求；既要采集足够多的数据，又不能触碰敏感信息。这里分享一套在银行和券商落地过的做法。
金融环境对日志的要求是「完整可追溯、敏感不可见」。落地时先划采集边界：交易流水、账户、密码、身份证号等字段在采集侧做脱敏，用掩码或哈希替代，原始值不进可观测平台。保留的字段要能回答两个问题——「这笔交易是谁、在什么时间、通过哪个渠道发起的」，以及「系统在哪个环节、以什么状态处理了它」。
脱敏方法要按字段区分：卡号、手机号这类定长格式用正则替换；账号、订单号这类需要跨系统关联但不需还原的用加盐哈希；必须回源系统处理的用令牌化。过度脱敏会毁掉你本来要采集的信号，脱敏不足则是下一次审计必中的整改项。
审计日志与业务日志分链路存储，审计链路的保留期按监管要求设到 5 年甚至更长，业务日志 30 天即可。保留期要在方案里写死：审计链路 5 年以上、业务日志 30 天、链路数据 7 天、指标原始值 13 个月加 3 年降采样。什么都永久存既贵又是合规负担——保留策略是特性，不是默认值。
金融核心系统往往是「老单体 + 新微服务」并存，全链路追踪不能一蹴而就。建议按交易链路优先级分批接入：先给对客面的网关、核心交易、账务、支付这几条关键链路埋点，再逐步覆盖外围系统。对暂时无法改造成 OTel 的老系统，用 Collector 在边界做 HTTP/gRPC 的旁路采集，把上游的 trace_id 透传下去，拼出半自动的链路图。链路图上线后，重点看两个指标：跨系统调用链的完整率，以及核心交易链路的 P99 延迟分布。
故障响应要建立在数据之上。每次应急复盘，把「从告警到定位根因」的耗时拆成三段：发现（告警延迟）、定位（检索与链路下钻耗时）、处置（变更与回滚耗时）。用可观测平台的数据去度量这三段，找出瓶颈。建议每月做一次真实故障注入演练，验证告警是否真的触达、值班人员能否在检索和链路里快速锁定根因，而不是只看监控大屏的演示效果。
分四步走：第一步（2 周）打通日志采集与脱敏，先满足审计底线；第二步（4 周）接入核心交易链路的追踪和黄金指标；第三步（2 周）配置告警与值班联动；第四步（持续）用数据驱动做容量规划和故障复盘。先解决「看得见」，再解决「查得快」，最后才是「预测得准」。