IT咖啡馆-监控系统的多区域与容灾

概述

按容灾级别（冷备/T+1/热备/多活）分层描述架构、RPO/RTO、数据路径、变更与演练、以及成本模型。方案完全贴合你给出的“OTLP 优先、双链路（OTel Gateway + Kafka 旁路）、OpenObserve + Kafka + PostgreSQL( Timescale/pgvector/AGE/HLL )”参考架构。

1. 目标 & 设计原则

目标

• 面向日志/指标/链路全量数据的多区域容灾，满足从低成本归档到零数据丢失的多活不同等级的业务需求。
• 为 AIOps/LLM Agent 提供“近实时可用数据 + 可靠历史回溯 + 二级分析域（PG）”。

原则

1. 摄取端复制优先：在OTel Gateway做多出口扇出（双写 + Kafka 旁路）而不是强依赖后端存储的复制能力。
2. 系统真源（System of Record）：Kafka.<region> 作为原始事件真源；可镜像到对端（Mirror/Linking），便于故障重放与 ETL。
3. 冷热分层：OpenObserve 面向检索/告警；对象存储做长期留存；PG 作为二级分析域承载聚合、向量与图分析。
4. 可演练、可回滚：GitOps 化配置、可观测自身（自监控）、具备按月/季度故障演练计划。

2. 容灾等级矩阵（结论优先）

* 成本系数为相对量纲：以 L1=1.0 作为基线，综合计算：存储 × 保留期 + 计算 × 峰值写入 + 跨区流量。

3. 参考总图（逻辑视图）

[Edge / Host / Pod]
  └─ Vector(Filelog/Prom) → OTLP/gRPC
      ↘ (Option) → Kafka.<region>.raw  (RF≥3)

[Regional Ingest/Gateway (LB前置)]
  └─ OTel Collector (file_storage + sending_queue)
       └─ Exporter Fanout:
           - OpenObserve.regionX  (Search/Alert/Visual)
           - Kafka.regionX.raw    (System of Record, replay)
           - (Option) OpenObserve.regionY (for L3/L4)

[Storage & Analytics]
  ├─ OpenObserve.regionX (objstore + WAL)
  ├─ Kafka.regionX (Mirror/Link to regionY)
  └─ ETL (Benthos/Flink/Connect) → PostgreSQL( Timescale/pgvector/AGE/HLL )
       └─ 连续聚合(CAGG)、TopK/HLL、向量与图分析

4. 分级架构与落地要点

4.1 L1 冷备份（低成本合规）

• 写入：摄取仅写主区 OpenObserve +（可选）Kafka。
• 备份：
  • OpenObserve 对象存储（S3/兼容）开启**跨区域复制（CRR）**到 DR。
  • Kafka 每日（T+1）导出到对象存储（分区/日期分桶）。
• 恢复：主区不可用时，在 DR 新建 OpenObserve 集群，挂载/回灌对象存储；按需要批量回放 Kafka 归档。
• 优点：极低成本、简单；不足：RPO=T+1，RTO较长，不适合在线告警。

4.2 L2 T+1 分析（次日可用）

• 写入：同 L1，但固定调度（每日/每小时）通过 ETL（Benthos/Flink/Connect）把 Kafka 原始数据汇总/脱敏后写入 PG(主/DR)。
• PG 复制：PG DR 库用逻辑复制或物理流复制；Timescale 连续聚合保留增量刷新策略（见 §7）。
• 用途：报表/趋势/容量规划、AIOps 训练数据集。
• 优点：低成本；不足：不覆盖在线检索/告警的 RPO/RTO。

4.3 L3 热备（主动-被动）

• OTel 双写：Gateway 同时写 OpenObserve(主) 与 OpenObserve(DR)，并写 Kafka(主)。
• Kafka 镜像：MirrorMaker 2 / Cluster Linking（或 Redpanda 对等）把主区原始流近实时镜像到 DR。
• PG：主库→DR 物理流复制；关键分析域（如告警配置、白名单）用逻辑复制保障可单表修复。
• 切换：主区故障 → DNS/LB 切写到 DR OTel Gateway；查询默认就近读。
• 优点：RPO≤分钟，RTO≤1h 内；不足：跨区写流量 & 双集群维护成本上升。

4.4 L4 多活（双活）

• 摄取：各区 OTel Gateway 就近接入，扇出双写到本区与对区的 OpenObserve；Kafka 双向镜像。
• 一致性与去重：
  • 以 trace_id / span_id / log_id（hash）作为幂等键；OpenObserve/Loki 查询侧可基于 ID 去重或“本地优先 + 远端补缺”。
  • 租户/业务维度做一致性哈希分片，减少全量双写成本（关键租户双写、一般租户单活+冷备）。
• PG 二域策略：
  • 域 A：近实时运维分析（本区主写）
  • 域 B：长周期/全局图谱（对区主写或异步汇总）
  • 必要维表/告警策略表做双向逻辑复制（冲突用“最后写入 wins + 审计日志”）。
• 优点：RPO≈0~1min，RTO≤10min；不足：最高复杂度与成本，需要成熟的 SRE 纪律与演练。

5. 标准化 OTel / Vector 配置片段（关键要点）

OTel Collector（双写 + 旁路 Kafka + 落盘队列）

extensions:
  file_storage:
    directory: /var/lib/otelcol/queue
receivers:
  otlp:
    protocols: { grpc: {}, http: {} }
processors:
  memory_limiter: { check_interval: 1s, limit_percentage: 75, spike_limit_percentage: 15 }
  batch: { send_batch_size: 8192, timeout: 5s }
  resourcedetection/system:
    detectors: ["system"]; system: { hostname_sources: ["os"] }
exporters:
  otlphttp/openobserve_primary:
    endpoint: https://oo.regionA.example/api/default/
    headers: { Authorization: "Basic xxx" }
    sending_queue: { enabled: true, num_consumers: 8, storage: file_storage }
    retry_on_failure: { enabled: true, max_elapsed_time: 300s }
  otlphttp/openobserve_dr:
    endpoint: https://oo.regionB.example/api/default/
    headers: { Authorization: "Basic yyy" }
    sending_queue: { enabled: true, num_consumers: 8, storage: file_storage }
    retry_on_failure: { enabled: true, max_elapsed_time: 300s }
  kafka:
    brokers: [ "kafka-a-1:9092","kafka-a-2:9092","kafka-a-3:9092" ]
    topic: otlp_raw
    encoding: otlp_proto
service:
  extensions: [ file_storage ]
  pipelines:
    logs:    { receivers: [otlp], processors: [memory_limiter,batch,resourcedetection/system], exporters: [otlphttp/openobserve_primary, otlphttp/openobserve_dr, kafka] }
    metrics: { receivers: [otlp], processors: [memory_limiter,batch,resourcedetection/system], exporters: [otlphttp/openobserve_primary, otlphttp/openobserve_dr, kafka] }
    traces:  { receivers: [otlp], processors: [memory_limiter,batch,resourcedetection/system], exporters: [otlphttp/openobserve_primary, otlphttp/openobserve_dr, kafka] }

Vector（边缘端：本地缓冲 + 双路）

[sources.journald] type = "journald"
[sources.filelog] type = "file"; include = ["/var/log/**.log"]

[transforms.to_otlp] type = "remap"
  # 归一字段/标签、生成 log_id = sha256(host+path+offset+ts)
  source = '''
  .log_id = md5!(.host + to_string!(.file) + to_string!(.timestamp) + to_string!(.message))
  '''

[sinks.otel]
  type = "otlp"; inputs = ["to_otlp"]; endpoint = "http://otel-gw.local:4317"; mode = "grpc"
  request.timeout_secs = 5; acknowledgements.enabled = true; buffer.type = "disk"; buffer.max_size = 268435456

[sinks.kafka]
  type = "kafka"; inputs = ["to_otlp"]; bootstrap_servers = "kafka-a-1:9092,kafka-a-2:9092"
  topic = "otlp_raw"; compression = "lz4"; acknowledgements = "all"; queue.max_length = 100000

6. Kafka 跨区复制 & 回放

• 主→备（L3）/双向（L4）：MirrorMaker 2 / Cluster Linking（Confluent）/ Redpanda 对等复制，topic 粒度选择 raw / normalized 两层：
  • *.raw（绕过解析，方便二次 ETL）
  • *.norm（已统一 schema，便于 PG 入仓）
• 重放：以分区+时间窗口重放到 OTel Gateway 的 OTLP/HTTP 或 OpenObserve 的 bulk 接口；幂等键避免重复。

7. PostgreSQL 二级分析域（DR 重点）

• 复制策略：
  • 物理流复制：主库 → DR（低延迟、全库一致）；
  • 逻辑复制：关键表（告警策略/白名单/租户配置）双向；避免全库冲突。
• Timescale：
  • **连续聚合（CAGG）**用于 1m/5m/1h 多层级汇总；
  • 故障切换后，执行 REFRESH MATERIALIZED VIEW CONCURRENTLY 补齐窗口；
  • 冷热分层：近期块不压缩，历史块压缩 + 分区保留策略。
• pgvector/AGE/HLL：
  • 向量索引：HNSW/IVFFlat，分区按时间或租户；
  • 图：服务依赖图在对端周期性汇总（避免强一致跨区写）；
  • HLL：近似去重与 TopK（高基数维度）。

8. 运行手册（SOP）

故障切换（L3 示例）

1. 触发条件：主区 OpenObserve/Kafka 不可用 > 5 分钟。
2. 动作：
   • LB/DNS 切换 OTel Gateway 到 DR；
   • 校验 DR OpenObserve 索引正常；
   • 告警路由切到 DR（Silence 主区噪声）。
3. 事后：主区恢复后，按时间窗口从 Kafka(DR) → 主区回放补齐；再切回主区读写。

定期演练（季度）

• 场景：单 AZ 故障、跨区链路中断、对象存储读写异常、PG 主故障。
• 指标：切换时长、丢数率（按 trace_id 覆盖率）、SLO 违约数。

9. 成本建模（简表）

记号：I = 日均摄取量（TB/日）、R = 保留天数、k = 双写系数（多活≈2.0，热备≈1.5，冷备≈1.0）对象存储：Cost_obj ≈ I * R * k * 单价(TB·月) 计算（OpenObserve/索引与压缩）：Cost_cpu ≈ f(I峰值, 并发查询, 压缩率) 跨区流量：Cost_xregion ≈ I * (双写或镜像比例) Kafka：按吞吐与 RF，磁盘（NVMe）+ 备份（对象存储） PG：SSD 容量（明细+聚合）+ 逻辑/物理副本算力经验系数：L1/L2：跨区流量最低； L3：跨区单向写 + Kafka 镜像； L4：双向写 + 双镜像，流量最高。 优化杠杆：关键租户双写、一般租户单活+冷备；日志正文降噪（采样/模板化）、指标窗口聚合（CAGG）、Trace Tail-based Sampling（保关键异常/高延时）。

10. 推荐落地路径（从低到高）

1. Baseline（L2）：主区 OpenObserve + Kafka；每日 ETL→PG（主/DR），对象存储 CRR。
2. 进阶（L3）：OTel 双写 + Kafka Mirror；PG 物理复制；季度演练。
3. 关键业务多活（L4-Partial）：按租户/业务分片启用双写+双镜像；其余沿用 L3。
4. 全面双活（L4-Full）：全量双写与双镜像 + 就近读写策略 + 去重与回放机制完善。