金融行业可观测性建设：从日志合规到全链路追踪

金融系统的可观测性和互联网公司不一样：排障不是唯一目标，合规审计、操作留痕、等保要求同样硬性。建设时往往"日志先行、告警随后、trace 最后补"，但三块若不打通，最后只剩一堆孤岛。下面讲一套可落地的建设路径。

一、先解决合规：日志的采集、留存与审计

金融场景日志要满足几个硬约束：

• 留存周期：交易类日志一般要求留存 3-5 年，监管检查要能随时调取；
• 完整性：日志不能被篡改，需要防篡改或不可变存储；
• 权限隔离：谁看日志、谁能导出，都要可审计。

落地时建议把日志分"热/温/冷"三层：热数据进检索集群（近 7-30 天），温数据进对象存储保留 1 年，冷数据归档并打时间戳 + 哈希，归档时同步写入审计表记录"谁在何时导出了什么"。炬鲸 OBSERVE 支持按租户和角色做数据权限，审计日志单独一份存储，和业务日志物理隔离。等保 2.0 对日志留存和审计的具体条款，建议在项目启动时就逐条核对，别等验收前才发现留档不足。

二、告警要"分级 + 收敛"，别把值班淹没

金融系统告警多到爆炸是常态。关键是把告警分级并做收敛：

• 分级：P0 影响资金/对外服务、P1 影响内部、P2 性能劣化、P3 需关注；
• 收敛：同一台机器同一类告警 5 分钟内只发一次，故障风暴期间自动聚合成一个事件；
• 路由：P0 走电话 + 短信，P1 走即时通讯，P2/P3 进工单系统。

告警条件建议直接挂在指标上，而不是靠日志关键词。比如"支付接口 P99 延迟连续 3 分钟超过 800ms"比"日志里出现 timeout 就告警"稳定得多——后者在大促期间会被刷屏。值班表要提前排好，每个时段明确到人，P0 告警必须有人能 15 分钟内响应，这是监管对业务连续性的底线要求。另外建议给每个 P0/P1 告警配一条处置手册（runbook），写明排查入口、常见原因和升级路径，避免新人值班时手足无措。

三、全链路追踪：把一笔交易看透

一笔跨系统的转账，可能经过网关、账户、风控、清算四个系统。没有 trace，故障定位只能靠各系统对时间戳。有了 trace，就能按 trace_id 把这笔交易的所有调用串起来，一眼看出卡在哪个环节。

金融系统接入 trace 有两个特殊点：

1. 敏感字段脱敏：span 里的卡号、身份证号、金额要脱敏后再上报，炬鲸支持在 agent 侧配置脱敏规则，数据出生产环境前就完成清洗；
2. 采样策略：普通请求按比例采样，但涉及资金变动的交易 100% 采集——这类 trace 数量有限，却是监管回溯的关键证据。

四、落地的三个阶段

建议按三个阶段推进，每阶段都有可验收的产出：

• 第一阶段（日志合规）：完成日志集中采集、留存策略、权限与审计，产出是"能通过等保/监管检查"；
• 第二阶段（监控告警）：核心系统的指标采集 + 分级告警 + 值班流程，产出是"平均故障定位时间（MTTD）明显下降"；
• 第三阶段（全链路）：核心交易链路接入 trace，日志-指标-trace 三者串联，产出是"复杂链路故障的定位时间从小时级降到分钟级"。

配套的治理不能省：每个季度清理一次无人认领的告警规则，把"响了没人管"的告警要么删掉要么降级；trace 采样率、日志留存周期这些参数定期复核，随业务量变化调整。可观测性系统本身也需要被维护，否则半年后又会堆出一堆没人看的看板。

可观测性建设不是买一套工具就能交差，它是把"事后翻日志"变成"事前有告警、事中有 trace、事后有审计"的过程。金融行业尤其如此——工具要服务合规，也要服务排障，两者缺一不可。