金融行业可观测性实践：从日志到链路的统一排障

金融系统的排障难点

金融系统对可用性和合规的要求都高，排障却更复杂：核心交易链路长，一次转账要穿过网关、风控、账务、清算十几个系统；日志量大且敏感，脱敏要求严格；监管对故障处置有明确的时效和留痕要求。传统"各系统自己查自己的日志"的方式，定位一次跨系统故障往往要几小时，而支付链路上的每一小时停机，损失的都是钱和信任。

统一日志与全链路追踪

炬鲸 OBSERVE 的方案是先把日志、指标、链路收进一个平台，再靠 trace_id 把它们串起来。一笔交易从网关进来，trace_id 贯穿所有下游系统；出问题时，从告警点开一笔异常交易，就能看到它在每个系统的耗时和返回码，直接定位到慢的那一跳。

接入时注意两点：一是全链路统一生成和透传 trace_id，网关是第一跳，务必正确注入；二是日志落盘前先脱敏，卡号、手机号、身份证号在采集端就替换，而不是入库后再处理。脱敏规则示例：

masking:
  - field: card_no
    regex: "\d{12,19}"
    replace: "****$"
  - field: phone
    regex: "1\d{10}"
    replace: "1******$"

在采集端脱敏还有一个好处：敏感值根本不会离开源主机，审计时数据保护口径更清晰。

告警分级与熔断联动

金融场景下，告警不能只有"有"和"没有"。OBSERVE 支持按影响面分级：核心交易错误率、资金类接口耗时超标属于 P0，普通查询慢属于 P2。规则示例：

- name: 核心交易错误率
  metric: error_rate
  filter: service in (gateway, core-trade)
  threshold: "> 0.1%"
  level: P0
  for: 1m

P0 告警可以对接工单系统和值班手机，同时触发网关的降级策略，实现"发现即处置"。落到位之后，一次典型故障的处置路径是：14:03 支付错误率告警触发，值班同学点开告警、跳到对应 trace_id，发现慢点集中在风控服务的外部查询，从告警到定位根因只需几分钟，不再需要拉群会诊。

合规与审计留痕

监管要求故障可回溯、可审计。OBSERVE 的日志默认只读、不可篡改，支持按时间、按交易号导出审计报告；告警的每一次触发、通知、处理动作都有操作记录。保留周期可按数据类型分别配置——原始日志按监管要求保留，聚合指标存得更久。这在等保测评和监管现场检查时能省下大量人力。

落地节奏建议

不建议一步到位全量接入。建议分三步：先接网关和核心交易系统，跑通日志与链路；再接入外围系统，补全链路；最后统一告警策略和值班流程。每阶段都以前一阶段的链路完整率为验收指标，比"接了多少个系统"更有意义。