金融行业可观测方案：从交易链路到合规审计

金融场景的独特要求

金融系统的可观测不只是"排障快"。监管要求审计日志留存 3 年以上、不可篡改；交易链路要求端到端可追溯，单笔交易从下单到清算要能完整还原；故障要分级上报，核心交易链路的中断必须在分钟级被发现。这三条决定了方案不能照搬互联网那套"看个大盘就行"的做法。

全链路交易追踪

一笔支付请求可能穿过网关、账务、风控、清算十几个服务。OBSERVE 用 OpenTelemetry 把整条链路串起来，一个 trace_id 贯穿到底。出现交易超时，直接按交易号反查：是风控接口慢了，还是清算服务重试导致的堆积，火焰图上一目了然。

配合业务埋点，把 order_id、user_id、amount 作为 Span 属性打进去，就能做到"按交易号查链路、按链路查日志"，把业务维度和技术维度对上。对账出现不一致时，能从账务系统的日志直接定位到原始请求。

审计日志：留存与防篡改

审计日志写入后走 WORM（一次写入多次读取）存储策略，保留周期按监管要求设为 3 年，过期自动归档不删。每次查询、导出都留痕，配合权限管控（只读角色、导出审批），满足等保和金融监管对操作审计的要求。管理员也不能删改审计日志，避免"出了事改日志"的风险。

告警分级与值班

金融系统告警不能"一刀切"。建议分三级：

• P1：核心交易链路中断、资金相关异常，5 分钟内电话 + 短信；
• P2：非核心服务抖动、容量告警，15 分钟内企业微信/钉钉；
• P3：慢查询、磁盘水位，仅记录工单，白天处理。

告警规则、值班表、升级链路全部配置化，支持多数据中心异地双活时的告警路由。P1 告警如果 5 分钟无人确认，自动升级到上一级负责人，避免漏接。

落地配置模板

一个中型城商行的典型配置：3 节点 OBSERVE 集群 + 2 节点采集网关 + 对象存储归档，日志日增约 2TB，检索响应 P95 在 2 秒内。核心系统（核心账务、支付）全量接入 Trace，外围系统先只上日志，分阶段推进，2 周内完成核心链路覆盖。上线后每周复盘一次告警误报率，持续调阈值，把 P1 误报压到个位数。

数据分级与留存

金融数据不能一锅端。建议分三层：热层存最近 3 天，走 SSD，服务实时排障和大屏；温层存 3 到 90 天，走廉价盘，用于容量规划和周度复盘；冷层存 90 天到 3 年以上，放对象存储，主要是满足留存要求的审计日志，只在调查或检查时被查询。查询层对三层透明，审计查两年前的日志和值班看最近十分钟用的是同一个 SQL 入口，只是慢一点。分层边界要按真实查询频率定，别拍脑袋——多数团队跑一个月就会发现，95% 的查询都落在 7 天以内的数据上。