金融行业可观测性落地：从合规审计到分钟级故障定位

金融行业看可观测性的三个痛点

金融客户的诉求通常不是「能不能监控」，而是三个更具体的问题：日志能不能满足监管留存和审计要求；一笔交易失败后能不能快速定位到是哪个系统、哪次调用出了问题；以及告警能不能少而准，别让值班同事天天被误报叫醒。

这三个诉求分别对应可观测性的存储、追踪、告警三个能力，也是方案落地的三条主线。

日志留存与审计合规

监管对日志的要求是「全量、可追溯、防篡改」。落地上有三个关键动作：

• 全量采集：交易、账务、渠道、网关等核心系统的日志不抽样，全部接入；非核心系统可按需裁剪字段。
• 留存周期：按监管口径配置分级留存，一般核心交易日志不少于 3 年，一般日志 6 个月到 1 年，冷数据自动转低频存储，控制成本。
• 审计与防篡改：开通操作审计，记录谁在什么时间查了哪批日志；对归档日志做完整性校验，防止篡改。

技术上，建议给日志打上统一的 traceId、tradeId、customerId，这是后面做全链路关联和审计追溯的基础。字段规范要在一开始就定好，事后补非常痛苦。

全链路追踪定位资金链路

一笔跨系统的交易，从前端下单到核心记账可能经过十几个服务。传统的做法是各系统各自查日志拼时间线，慢而且容易对不上。

方案是用 OpenTelemetry 做端到端埋点，把一次交易从入口到落库的完整调用链串起来。落地时重点处理两件事：

• 跨系统 traceId 透传：网关入口生成或透传 traceId，下游所有系统沿用，HTTP 头或消息体里都要带。这是资金链路能串起来的前提。
• 关键节点打点：在记账、扣款、风控、清算等节点用 span 打点，标注结果码和耗时，出问题时先看这几个节点而不是逐层下钻。

实际效果是，一笔交易失败，输入交易号能在分钟级看到完整调用链，定位到具体节点和错误码，排查时间从小时级压到分钟级。

告警分级与值班联动

金融系统告警最怕两件事：一是漏报，出了问题没人知道；二是误报多，值班麻木了真告警反而没人看。方案建议：

• 分级：按影响面把告警分 P0～P3，P0 直接电话/短信，P1 走即时消息，P2/P3 汇总成日报。
• 抑制与降噪：同一根因的告警合并，机房级故障抑制下游服务告警，避免告警风暴。
• 与值班系统联动：炬鲸告警对接现有 ITSM/值班系统，自动派单、自动升级，全程留痕可复盘。

安全与数据隔离

金融数据需要的不仅是监控，还有隔离与管控。两个反复出现的实践：

• 网络隔离：炬鲸部署在生产网段，严格限制出方向；只有 Collector 的 OTLP 出口和值班联动需要放行。
• 角色权限与字段脱敏：按角色授予所需日志的访问权，查询时对敏感字段（卡号、证件号、手机号）做脱敏，排查问题不泄露个人隐私。

这两项都是原生能力而非外挂，审计问起「某个字段如何被保护」时能直接给出答案。

容量与性能经验

金融业务有明显的波峰（如双十一、季度结息）。上线前用压测数据做容量评估，按峰值 QPS 和日志写入速率预留存储和索引能力；上线后用趋势图观察日志量增长，提前扩容而不是等磁盘告警。索引层建议冷热分离，热数据走 SSD，历史数据落对象存储，性价比最高。

落地节奏上，多数机构是分阶段推进而不是一步到位：先做核心系统的日志采集与审计（最快的合规收益），再上资金链路的追踪，最后收紧告警。每个阶段都有可量化的产出，不用等几个月才看到第一个结果。