金融行业可观测性落地：审计留存、双活容灾与秒级故障定位

金融机构的可观测性不只是"看得到"，还要满足审计留存、数据隔离、双活容灾三条硬约束。这篇讲我们在几家中大型金融机构落地时沉淀的做法。

一、审计留存：日志不是想删就能删

监管要求交易类日志留存 3—15 年不等，且要保证完整、不可篡改、可追溯。落地上我们做了三件事：

1. 冷热分层：近 30 天热数据落 SSD，之后归档到对象存储并加 SHA-256 摘要，防止事后篡改；
2. 只读归档：归档区对普通账号只读，删除需双人复核；
3. 导出即证据：支持按时间窗 + 交易号导出完整日志包，附校验和，可直接交给审计。

二、数据隔离与权限：多法人/多租户的边界

金融机构常有多法人、多业务条线。OBSERVE 的租户模型按机构维度切分，数据在存储层物理隔离，权限用 RBAC 控制到字段级——风控团队能看交易日志但不能看客户敏感字段（卡号、手机号），这些字段在采集端就做脱敏。审计员账号默认只读 + 全操作留痕，任何查询行为本身也进入审计日志。

三、双活容灾：可观测系统自己不能先挂

生产业务双活，可观测平台同样要双活。做法是：

1. 采集器双写：同一份日志/指标同时写入两个数据中心，单侧故障不丢数据；
2. 元数据主备：达梦/金仓走主备自动切换，切换演练每季度一次；
3. 告警链路独立：告警通知走独立短信网关与话务专线，不依赖被监控网络，避免"网络断了连告警都发不出去"。

四、秒级定位：从"告警响了"到"知道哪错了"

标准排查路径是：告警按 service 聚合 → 点开该 service 的黄金指标（延迟、错误率、饱和度）→ 下钻到异常主机的日志 → 用 trace_id 展开调用链。我们把这条路径做成"故障定位工作台"，把散落三处的信息按 trace_id 串起来，P0 故障的 MTTR 从小时级压到分钟级。黄金指标里最容易漏的是"饱和度"——CPU、连接池、队列深度这三个通常在告警阈值之前就出现异常，值得优先纳入看板。

五、落地建议：先跑通一条链路，再谈全覆盖

金融系统改造最忌讳一步到位。建议先选一条核心交易链路（例如支付）做试点，把日志、指标、链路三样打通并验收，再横向复制。试点阶段就定好命名规范（service 名、日志字段、trace 属性）与容量基线，否则后续几十个系统接入时会为命名混乱和容量预估失准付出成倍成本。