金融行业可观测性方案：监管合规与故障定位两手抓

金融系统的可观测性有两条绕不开的硬约束：一是监管合规，审计日志必须完整留存、可追溯、防篡改；二是可用性，交易链路一旦抖动，损失按秒计算。这两条需求看似矛盾——一个要"留得住"，一个要"查得快"——实际可以用同一套平台同时满足。下面拆开讲每条约束怎么落地。

交易链路的端到端追踪

支付、转账这类核心交易往往横跨网关、账户、风控、清算十几个服务。炬鲸 OBSERVE 通过 OpenTelemetry 在交易发起时注入 trace_id，整条链路从下单到清算全程可追踪：

SELECT trace_id, sum(cost_ms) AS total
FROM traces
WHERE api = 'POST /api/pay'
  AND ts > now() - 10m
ORDER BY total DESC

一旦某笔交易超时，点开 trace 就能看到卡在哪个服务、哪一跳重试了几次，不必逐层翻日志。建议把交易单号 order_no 作为 span 属性写入，这样业务侧报"订单 8899123 扣款失败"时，直接用订单号反查整条链路。

审计日志的留存与检索

监管通常要求关键操作日志留存 3 年以上。建议做法：

• 操作类日志（登录、权限变更、对账、手工调账）单独打标 audit=1，与运行日志分离，避免被运行日志的保留期误删。
• 启用对象存储冷备 + WORM（一次写入多次读）锁，防止被修改或删除——这正是审计真正会检验的那条属性。
• 检索按操作人、时间、动作三维度建索引，抽查时秒级定位，而不是全量扫描。

告警分级与应急响应

• 告警分级：核心交易链路故障为 P0，立即电话/短信触达值班；非核心降级为 P1/P2，走工单。
• 告警收敛：同一故障产生的告警风暴要按根因聚合，避免值班被几百条重复告警淹没。
• 应急闭环：每次故障后从 trace 导出时间线，复盘定位根因，沉淀成巡检项。

变更与灰度可观测

金融系统发版风险高，建议把"变更"也纳入可观测：每次发布把版本号、灰度比例写进 span 属性，按版本维度对比错误率和 p95，灰度阶段发现异常就能立刻回切。发布后盯着"新版本错误率 vs 旧版本"这条曲线，比任何事后复盘都更早暴露问题。

对金融团队来说，收益很实在：审计一次通过、故障在客户察觉前定位。