面向金融机构技术负责人的可观测落地方案：日志分类留存与审计合规、全局流水号贯穿的交易链路追踪、分级告警与应急响应，以及三步走的落地节奏。
金融系统的可观测不只是技术问题，还牵涉审计、等保、数据留存。本文面向金融机构的技术负责人，给出一个既能满足合规、又能真正用于故障定位的落地方案。
监管对日志留存年限、完整性、不可篡改有明确要求。方案要点：日志按业务、运维、安全三类分通道采集，互不串扰；安全类日志单独加密存储并做哈希链防篡改；留存策略按类别区分——安全类通常要求 6 个月以上，交易类更长，运维类可相对缩短。平台提供按时间的只读归档查询，审计员只读、运维可查、开发按项目隔离，权限分明。审计操作本身也落日志，做到"谁在什么时候查了什么"可追溯。
具体来说，安全类和交易类日志往往要留存多年且须能应对取证，应走加密、不可变、带留存锁的存储；运维类日志通常 30-90 天滚动即可。在采集入口就把三类分开，而不是入库后再分，才能让大流量的运维日志不占用昂贵的防篡改存储，长期留存成本才不会失控。
核心诉求是"每一笔交易都能还原"。方案用全局流水号（global_trace_id）贯穿网关、交易、清算、账务四个系统，在 OpenTelemetry 里作为父 span 透传，各系统的本地 trace_id 与它建立映射。落地做法是在网关为每笔交易生成 global_trace_id 并注入为 span 属性，再通过 W3C Trace Context 往下游透传，每个下游系统在自己的 span 和日志里都记下它。出现问题后，输入订单号即可还原该笔交易经过的所有服务、每个环节耗时和关键字段，跨系统的对账和纠纷排查从小时级降到分钟级。
金融场景告警必须分层：P0 直接电话通知值班，P1 短信加群消息，P2 进工单。关键指标（如支付成功率、核心交易 TPS、资金一致性）设双重阈值——软阈值预警、硬阈值告警，减少误报。例如支付成功率软阈值 99% 预警、硬阈值 97% 触发 P0，中间的缓冲吸收正常波动，不至于半夜把人叫醒。告警信息里直接附上关联的 trace 和日志链接，值班人拿到告警就能往下查，不用再问"现场在哪"。
分三步走：第一阶段跑通日志采集与留存，先满足合规底线；第二阶段接入链路，覆盖交易主链路；第三阶段上监控告警与自动化处置。每阶段都有独立验收标准——第一阶段看留存与审计查询是否过审，第二阶段看任意一笔交易能否按订单号还原，第三阶段看 P0 告警能否在秒级带上关联链路。这样分步推进，避免"一步到位"的失败风险。