面向银行、证券的落地方案：审计留痕、跨系统链路追踪、告警分级与应急联动，以及生产环境采样、数据留存等合规约束下的具体做法。
金融行业做可观测性，和互联网公司最大的区别是两条红线：合规留痕和变更管控。方案要在这两条约束下，把故障定位做到和互联网一样的效率。这篇讲我们在银行和证券客户的落地做法。
金融监管要求操作可追溯——可观测平台本身也在监管范围内。平台要过等保，账号要接统一身份认证（IAM），关键操作（改告警规则、删数据、导出日志）必须留审计日志。我们的做法是：平台内所有写操作落审计事件，接入行里的 SIEM，留存周期对齐监管要求——日志一般至少 180 天，交易相关数据更长。查询默认脱敏，卡号、身份证号、手机号等敏感字段按掩码规则处理，防止运维人员随手一查就带出客户明文。
一笔转账要经过渠道、核心、账务、清算十几个系统。排查慢交易时，单个系统的 trace 看不到全貌。做法是把全链路 trace_id 透传：渠道层生成 trace_id，HTTP 头、消息体统一带上，各系统用 OpenTelemetry 埋点，最终在炬鲸 OBSERVE 里看到这笔交易的完整调用链。这里的关键是制定统一的 trace_id 透传规范——谁生成、放哪个头、跨消息队列怎么带——否则链会断在某个系统边界上，又回到手工对日志的老路。落地时建议先在渠道层和核心系统打通透传，确认 trace_id 在消息队列场景下不丢失，再逐步覆盖其余系统。
金融对告警时效要求极高。按 P0/P1/P2 分级，P0 直接电话值班并同步到应急群；告警规则覆盖交易成功率、响应时间 P99、批处理超时等业务指标，而不仅是 CPU、内存——批处理超出时间窗口本身就是一起事故，哪怕机器看起来都正常。告警正文附关联的指标曲线和日志片段，值班人员接电话就能定位。联动上，P0 告警触发工单系统和值班升级流程，形成闭环，而不是让告警死在群里。
合规要求全量留存，但全量 trace 存储成本高。折中方案：trace 全量保留元数据（trace_id、耗时、服务列表）用于审计与检索，明细 span 按采样率存储；错误和慢交易 100% 保留明细。这样既满足"可追溯"的监管底线，又控制住存储成本。实施上建议先小范围试点，验证留存周期和查询性能后，再推广到核心系统，不要一次性切换整个交易链路。