金融行业可观测建设：从监管合规到故障分钟级定位

金融场景的四个特殊要求

金融行业的可观测平台和互联网公司不一样，四个要求绕不开：

1. 监管合规：日志要满足等保与审计要求，留存周期长，敏感数据必须脱敏
2. 高可用：交易系统停顿分钟级就有损失，故障定位必须快
3. 跨系统链路：核心、渠道、支付、清算横跨几十套系统，一笔交易要串起来看
4. 容量可预测：节假日、结算日流量翻倍，要提前预警扩容

监管合规：审计留痕与数据脱敏

平台要支持四件事：所有敏感操作（登录、查询、导出、改告警）写审计日志且不可篡改；日志里的卡号、身份证号、手机号在采集端就脱敏；日志留存按监管要求设置周期（如交易日志五年以上）；权限分级，不同角色只能看到授权范围内的数据。

脱敏建议在 Collector 层用 processor 统一做，避免各业务方自己实现、标准不一：

processors:
  redaction:
    allow_all_keys: false
    blocked_values: ["\d{16}", "\d{17}[\dXx]"]  # 卡号、身份证

跨系统调用链：以一笔交易为线索

把交易流水号注入 trace context，前端渠道、后端核心、支付、清算整条链路就能按一个交易号串起来。排查时从"某笔交易失败"直接下钻到具体系统、具体方法，而不是各系统分别翻日志。这笔交易走过了哪些系统、每一步耗时多少、卡在哪一步，一张图就能说清。

故障分钟级定位的落地方法

• 给核心交易系统配置错误率、P99 延迟告警，阈值按业务低谷/高峰分段
• 告警附带 Trace 链接，点开就是慢调用火焰图
• 每周复盘告警，把误报、漏报回填成规则优化，让值班人真正信得过告警

日志留存与分级归档

金融日志动辄留存多年，但不是所有日志都一样"热"。用三级留存模型兼顾成本与合规：

• 热层（0-30 天）：近期日志与 Trace，索引完整、支持全文检索
• 温层（30 天-1 年）：压缩存储，可按时间范围和关键字段检索，速度略慢
• 冷层（1 年以上）：对象存储归档，留作审计，按需恢复

交易、支付类日志在热/温层的留存时间通常比应用调试日志更长，后者可尽快下沉到冷层。留存策略要按服务、按日志级别提前定义，事后补救要动每一套采集管道。

角色与权限

金融可观测平台不能谁都能看。至少要区分四类角色：平台管理员（管租户和基础设施）、审计员（只读审计日志、不能查询）、值班工程师（对生产有完整查询权限）、开发人员（只能访问自己的服务和环境）。用租户级、环境级的范围控制来落地，并把查询、导出、改告警等敏感操作全部写入审计日志。等监管问"谁在什么时候看过这批数据"，答案应该是一条查询，而不是一次开会。

落地清单

从"先看日志"到"先看链路"，建议按日志接入 → 指标监控 → 链路追踪 → 告警与值班 → AI 辅助排查的顺序推进，每阶段两周，先跑通核心交易链路再扩面。容量规划单独列为持续动作：用历史数据拟合流量模型，节假日、结算日前自动给出扩容建议。