金融多活架构的可观测性：跨机房日志、链路与告警统一治理

金融核心系统做同城双活、两地三中心时，最头疼的不是应用改造，而是故障时"到底哪个机房、哪条链路出了问题"。跨机房日志割裂、链路 trace 断在网关上、告警风暴，是三个高频痛点。本文讲一套统一治理方法。

三个核心痛点

1. 日志割裂：每机房一套 ELK，查一次要切三套系统，跨机房调用日志对不上号。
2. 链路断链：trace context 在跨机房网关或消息队列处丢失，一笔交易看不到完整链路。
3. 告警风暴：A 机房故障引发 B 机房级联告警，值班人被刷屏，找不到根因。

统一上报架构

每机房部署一组采集器（OTel Collector + 本地缓存），统一上报到中心的 OBSERVE。采集器带本地磁盘队列，机房网络抖动时数据不丢、恢复后自动补传：

exporters:
  otlphttp:
    endpoint: https://ob.jjhub.cn/otel
    sending_queue:
      storage: file_storage
      queue_size: 10000
extensions:
  file_storage:
    directory: /var/lib/otelcol

链路侧要求所有服务走统一 SDK，trace context 在网关和 MQ 上显式透传——不要只在 HTTP 头里传，MQ 消息头也要带上 traceparent，否则一笔交易跨到 MQ 就断链。

告警分级与降噪

• 按机房和业务域打标签，告警规则统一"先按机房隔离、再按业务聚合"。
• 配置依赖关系：A 机房故障时自动抑制 B 机房的级联告警，只保留根因一条。
• 关键指标（交易成功率、P99 延迟）做跨机房对比告警：某机房与其它机房偏离超过阈值才告警，避免全局限流造成误报。示例规则：abs(rate_A - rate_B) / rate_B > 0.1 持续 5 分钟才触发。

合规与数据治理

金融对数据留存和审计有硬要求：日志加密存储、按保留期自动归档、查询留痕。OBSERVE 支持字段级脱敏（卡号、身份证号自动掩码）和查询审计，满足等保与数据安全要求。这些要在方案设计阶段一并规划，别等验收前临时补——跨机房的数据流向、留痕范围、脱敏字段清单，评审时都要能说清楚。