高可用与长期存储

上一章结尾我们留下了三个联邦解决不了的问题：高可用、长期存储、全局明细查询。这一章就来正面回答它们。

需要先说清楚一件事：Prometheus 的设计哲学是「每个实例都是独立、自包含、无依赖的」。它故意不做集群、不做数据复制、不做分布式共识——因为监控系统最重要的属性是在别的东西都挂了的时候它还活着，而分布式系统会引入一堆新的失败模式。所以 Prometheus 的高可用不是「让一个集群变得可靠」，而是「跑两个互不相干的实例，用外围组件处理重复」。这个思路一开始会让人觉得粗糙，但用久了你会发现它简单得可爱。

至于长期存储，Prometheus 的做法是把这件事外包出去：本地 TSDB 只负责最近几天到几周的数据，更久的数据通过 remote_write 推给专门的系统。围绕这个接口，社区长出了 Thanos、Cortex、Mimir、VictoriaMetrics 等一整个生态。

读完本章你会掌握：

• 本地 TSDB 的存储结构、--storage.tsdb.retention.time 与 --storage.tsdb.retention.size 的行为
• 双副本高可用的完整做法，以及为什么必须用 alert_relabel_configs 处理 replica 标签
• Alertmanager 集群的 gossip 去重机制，以及为什么不能把 Alertmanager 放在负载均衡后面
• remote_write 的分片队列模型、queue_config 调优与 write_relabel_configs 过滤
• Thanos 各组件（Sidecar / Query / Store / Compact / Receive）的职责与部署要点
• Cortex 与 Mimir 的关系、架构差异，以及三套方案按规模的选型建议

一、先搞清楚本地存储的边界

在谈「长期存储」之前，得先知道「短期存储」的能力到底在哪里。

TSDB 的物理结构

Prometheus 的数据目录（默认 data/，用 --storage.tsdb.path 修改）大致长这样：

data/
├── 01HXYZ.../             # 一个持久化块（block）
│   ├── chunks/
│   │   └── 000001         # 实际的样本数据，单文件最大 512MB
│   ├── index              # 倒排索引，标签到序列的映射
│   ├── meta.json          # 块的元信息：时间范围、序列数、压缩层级
│   └── tombstones         # 删除标记
├── 01HXZA.../
├── chunks_head/           # 内存中 head 块已落盘的部分
├── wal/                   # 预写日志
│   ├── 00000001
│   ├── 00000002
│   └── checkpoint.000001/
└── lock

工作方式是这样的：新到达的样本先写进内存中的 head 块，同时追加到 WAL（预写日志）保证崩溃后能恢复。每隔 2 小时，head 块被持久化成一个磁盘上的 block 并清空 WAL。后台的 compaction 会把相邻的小 block 逐步合并成更大的 block（最大不超过保留期的 10% 或 31 天，取较小者），合并过程中会删掉过期数据。

理解这个结构很重要，因为它解释了很多现象：为什么 Prometheus 重启后要花一段时间「replaying WAL」；为什么内存占用和「活跃序列数」强相关；为什么删除数据不是立刻生效的（要等下一次 compaction）。

保留期怎么配

./prometheus \
  --config.file=/etc/prometheus/prometheus.yml \
  --storage.tsdb.path=/var/lib/prometheus \
  --storage.tsdb.retention.time=30d \
  --storage.tsdb.retention.size=400GB

规则如下：

• --storage.tsdb.retention.time 控制按时间保留，支持 s / m / h / d / w / y 单位。
• --storage.tsdb.retention.size 控制按磁盘大小保留，支持 B / KB / MB / GB / TB / PB 单位（也接受 KiB 这类二进制单位）。
• 两个都设置时，任意一个条件被触发就会删除最老的块，相当于取更严格的那个。
• 两个都不设置时，默认按 15 天保留。
• 只设置 size 不设置 time 时，时间维度的保留就被关闭了，只按容量淘汰。这一点经常被误解。

单机能撑多大

给一个粗略的量级感受（具体数值和硬件、指标特征关系很大，仅供估算）：

磁盘方面，一个样本压缩后平均占用 1 到 2 字节。用这个数可以估算：100 万活跃序列、15 秒采集间隔、保留 30 天，大约需要 1e6 × (30×24×3600/15) × 1.5B，约等于 260 GB。

当单机撑不住时，你的选项是：先做垂直优化（降低采集频率、用 metric_relabel_configs 丢掉高基数指标、治理标签），再做水平分片（上一章讲过的 hashmod，或者按业务拆多个 Prometheus），最后才上远程存储。远程存储解决的是「存多久」和「怎么全局查」，它并不能减轻单个 Prometheus 的抓取压力。

二、高可用：双副本 + 去重

基本做法

Prometheus 的高可用方案简单到只有一句话：跑两台配置完全相同的实例，让它们各自独立抓取同一批目标。

副本 A 的配置：

global:
  scrape_interval: 15s
  evaluation_interval: 15s
  external_labels:
    cluster: 'prod-bj'
    replica: 'A'
 
alerting:
  alertmanagers:
    - static_configs:
        - targets:
            - 'alertmanager-1:9093'
            - 'alertmanager-2:9093'
            - 'alertmanager-3:9093'

副本 B 的配置只有一处不同：

global:
  external_labels:
    cluster: 'prod-bj'
    replica: 'B'

其余的 scrape_configs、rule_files 全部一模一样。两台机器完全对等，没有主从、没有选举、没有数据同步，谁挂了另一台照常工作。

查询侧的处理

查询侧有三种选择，复杂度递增：

方案一：负载均衡 + 会话保持。 在两个副本前面放一个 nginx 或 HAProxy，开启 sticky session（比如按源 IP 哈希）。这样同一个用户的查询总是落到同一个副本，避免图上跳变。缺点是副本切换时（比如 A 重启）用户会看到数据不连续。

upstream prometheus {
    ip_hash;
    server prom-a:9090;
    server prom-b:9090;
}

方案二：主动指定。 Grafana 里配两个数据源，日常用 A，A 挂了手动切 B。简单粗暴但需要人工介入。

方案三：Thanos Query 去重。 Thanos Query 同时连接两个副本，用 --query.replica-label=replica 告诉它「replica 这个标签是副本标识」。查询时它会把 replica="A" 和 replica="B" 的同名序列合并，优先取数据更完整的那一条，从而输出一条无空洞、无跳变的序列。这是最优雅的方案，代价是要引入 Thanos。

告警侧的处理：这里有个大坑

两个副本都在独立评估告警规则，都会往 Alertmanager 发告警。如果不做处理，你会收到两份一模一样的告警通知。

很多人以为「Alertmanager 会自动去重啊」——它确实会，但去重的判断依据是告警的标签集完全相同。而我们刚刚给两个副本打了 replica: A 和 replica: B 的 external_labels，这些标签会附加到告警上，导致两条告警的标签集不相同，Alertmanager 认为它们是两个不同的告警，于是各发一遍。

解决办法是用 alert_relabel_configs，在发送给 Alertmanager 之前把 replica 标签删掉：

alerting:
  alert_relabel_configs:
    # 发给 Alertmanager 前去掉副本标识，让两个副本的告警标签集一致
    - regex: 'replica'
      action: labeldrop
 
  alertmanagers:
    - static_configs:
        - targets:
            - 'alertmanager-1:9093'
            - 'alertmanager-2:9093'
            - 'alertmanager-3:9093'

这样副本 A 和副本 B 发出的告警标签集完全相同，Alertmanager 的去重机制才能生效，最终只发出一条通知。

global:
  external_labels:
    cluster: 'prod'
    replica: 'A'
    prometheus_host: 'prom-a.internal'
 
alerting:
  alertmanagers:
    - static_configs:
        - targets: ['alertmanager-lb:9093']

三、Alertmanager 的高可用细节

既然上面已经提到了，就把 Alertmanager 集群讲完整。

Alertmanager 用 gossip 协议（基于 HashiCorp memberlist）组成集群，没有 leader、没有共识算法。集群内同步两类状态：

• Silences（静默规则）：你在任意一个实例上创建的静默，会广播到所有实例。
• Notification Log（nflog）：「哪条告警在什么时候已经通知过了」的记录，这是去重的核心。

去重的实际流程是：告警到达所有实例后各自开始计时（group_wait），但每个实例会根据自己在集群成员列表里的位置序号额外等待一段时间（大约 位置序号 × 15 秒）。排在第一位的实例最先发出通知并广播 nflog；排在后面的实例在轮到自己时先查 nflog，发现「已经发过了」就跳过。

这个机制有几个实践含义：

• 集群规模建议 3 个实例。 2 个也能工作但没有冗余余量，超过 3 个只会增加末位实例的通知延迟。
• 通知会有额外延迟。 如果第一个实例卡住了，第二个实例要等 15 秒左右才会接手。这是可靠性的代价。
• 静默的生效有传播延迟。 刚创建的静默需要几秒才能同步到所有实例，极端情况下可能漏掉一条已经在发送途中的通知。
• 网络分区会导致重复通知。 如果集群被网络分区切成两半，两边都会认为自己该发通知。这是 gossip 系统的固有取舍：宁可重复通知，不可漏发通知。

# Alertmanager 实例宕机
up{job="alertmanager"} == 0
 
# 集群成员数不足
alertmanager_cluster_members < 3
 
# 通知发送失败
rate(alertmanager_notifications_failed_total[5m]) > 0

四、remote_write 与 remote_read

remote_write 的工作原理

remote_write 是 Prometheus 对接外部存储的标准接口。它的数据流是：

样本进入 head 块 → 同时写入 WAL → remote_write 组件读取 WAL → 按序列哈希分配到若干个分片队列 → 每个分片攒够一批就用 protobuf + snappy 压缩后 POST 给远端。

这里有几个设计要点值得注意：

• 基于 WAL 而不是内存。 这意味着远端短暂不可用时，数据不会丢——Prometheus 会在 WAL 里保留读取位置，恢复后继续从断点发送。但 WAL 本身有保留期，远端挂太久（通常超过 2 小时）还是会丢数据。
• 分片是动态的。 Prometheus 会根据「样本积压量」和「远端响应速度」自动调整分片数量，在 min_shards 和 max_shards 之间伸缩。
• 它是异步的。 抓取和远程写入是解耦的，远端慢不会阻塞抓取。

配置示例：

remote_write:
  - url: 'https://thanos-receive.internal/api/v1/receive'
    name: 'thanos'
 
    # 认证
    basic_auth:
      username: 'prometheus'
      password_file: '/etc/prometheus/remote_write_password'
 
    # 只把需要长期保存的指标写出去
    write_relabel_configs:
      # 丢弃 Go runtime 这类噪音指标
      - source_labels: [__name__]
        regex: 'go_.*|process_.*'
        action: drop
      # 丢弃已知的高基数指标
      - source_labels: [__name__]
        regex: 'apiserver_request_duration_seconds_bucket'
        action: drop
 
    queue_config:
      capacity: 10000            # 每个分片的内存队列容量
      max_shards: 50             # 分片数上限
      min_shards: 1              # 分片数下限
      max_samples_per_send: 2000 # 每次请求带多少样本
      batch_send_deadline: 5s    # 攒不满一批时最长等待
      min_backoff: 30ms          # 失败重试的最小退避
      max_backoff: 5s            # 失败重试的最大退避

    write_relabel_configs:
      - source_labels: [__name__]
        regex: '(job|service|cluster):.*|up|http_requests_total|node_.*'
        action: keep

队列积压怎么排查

remote_write 出问题时最典型的症状是「远端数据落后于本地」。看这几个指标：

# 积压程度：最新采集的样本时间 与 已成功发送的样本时间 之差（秒）
prometheus_remote_storage_highest_timestamp_in_seconds
  - ignoring(remote_name, url)
    prometheus_remote_storage_queue_highest_sent_timestamp_seconds
 
# 分片数是否已经打满上限
prometheus_remote_storage_shards
  / prometheus_remote_storage_shards_max
 
# 发送失败速率
rate(prometheus_remote_storage_samples_failed_total[5m])
 
# 因队列满而被丢弃的样本
rate(prometheus_remote_storage_samples_dropped_total[5m])

第一个查询给出的「落后秒数」是最直观的健康指标。持续超过 60 秒就该介入了：先看是不是远端太慢（看响应延迟），再考虑调大 max_shards 和 max_samples_per_send，或者用 write_relabel_configs 减少数据量。

Remote Write 2.0

Prometheus 3.0 引入了 Remote Write 协议的 2.0 版本，主要改进是：用字符串表（string interning）显著降低了重复标签的传输体积；原生支持传输元数据（HELP / TYPE / UNIT）、exemplars 和创建时间戳；对原生直方图（native histograms）有一等支持。

配置上通过 protobuf_message 指定版本：

remote_write:
  - url: 'https://mimir.internal/api/v1/push'
    protobuf_message: 'io.prometheus.write.v2.Request'

客户端和服务端会通过 HTTP 头协商版本，远端不支持 2.0 时可以回落到 1.0。除非你的后端明确支持，否则暂时保持默认（1.0）更稳妥。

remote_read 及其局限

remote_read 是反方向的接口：让 Prometheus 在执行查询时，把请求也发一份给远端存储，然后把结果和本地数据合并。

remote_read:
  - url: 'https://remote-storage.internal/api/v1/read'
    # 只有匹配这些标签的查询才走远端，避免每次查询都打扰远端
    required_matchers:
      cluster: 'prod-bj'
    # false 表示「本地已有的时间范围就不查远端了」
    read_recent: false

说实话，remote_read 在生产里用得很少，原因有三：

1. 性能差。 它需要把远端的原始样本全部传回本地，再由本地的 PromQL 引擎计算。查询一个月的数据可能要传输几百 MB，还没有任何下推优化。
2. 没有全局视图。 它只能让「这一个 Prometheus」看到更长的历史，别的实例的数据依然看不到。
3. 有更好的替代。 Thanos Query、Mimir、VictoriaMetrics 都提供了自己的 PromQL 查询端点，Grafana 直接连它们就行，计算在存储侧完成，效率高得多。

prometheus_remote_storage_shards          = 200
prometheus_remote_storage_shards_max      = 200
prometheus_remote_storage_samples_pending = 1800000
远端接口 P99 响应时间                       = 3.2s
Prometheus 每秒产生样本数                   = 150000
写出的指标里，go_* 和 *_bucket 占了 62%

五、长期存储方案对比

现在进入选型环节。三个主流方案的定位差异其实很清晰。

Thanos

Thanos 的核心思路是「给现有的 Prometheus 加装扩展件，数据放对象存储」。它不要求你改变现有部署，只是在每个 Prometheus 旁边贴一个 sidecar。

一个最小可用的 Thanos 部署长这样：

   Prometheus A ──┐                        ┌── Store Gateway ──┐
   + Sidecar      │                        │                   │
                  ├── Thanos Query ────────┤                   ├── 对象存储
   Prometheus B ──┤     (去重)              │                   │   (S3/GCS/COS)
   + Sidecar      │                        └── Compact ────────┘
                  │                             (降采样)
                  └── Grafana 连这里

部署 Thanos Sidecar 时，Prometheus 的启动参数必须改：

./prometheus \
  --config.file=/etc/prometheus/prometheus.yml \
  --storage.tsdb.path=/var/lib/prometheus \
  --storage.tsdb.retention.time=2d \
  --storage.tsdb.min-block-duration=2h \
  --storage.tsdb.max-block-duration=2h \
  --web.enable-lifecycle

Thanos 的降采样是它相对于「简单堆磁盘」的最大优势。Compact 会为每个 block 额外生成 5 分钟和 1 小时分辨率的版本，查询时 Thanos Query 根据请求的时间跨度自动选择合适的分辨率。查一年的趋势图时用 1 小时分辨率，数据量是原始数据的几百分之一，查询秒开。

Cortex

Cortex 走的是完全不同的路线：它是一个多租户的、水平扩展的、推模式的时序数据库，Prometheus 通过 remote_write 把数据推给它。

架构是典型的微服务拆分：

• Distributor：接收 remote_write 请求，校验后按序列哈希分发给多个 Ingester（默认写 3 副本）。
• Ingester：在内存里构建 TSDB head 块，定期刷成 block 上传到对象存储。
• Querier：执行 PromQL，同时向 Ingester（近期数据）和 Store Gateway（历史数据）取数。
• Store Gateway / Compactor / Ruler / Alertmanager / Query Frontend：职责与 Thanos 中的同名组件类似。

多租户是 Cortex 的一等特性：每个请求带 X-Scope-OrgID 头，数据在存储和查询层面完全隔离，每个租户还能有独立的限流配额。这让它很适合做「内部监控 PaaS」。

Cortex 早期用的是自研的 chunks 存储（依赖 Cassandra / DynamoDB 等），运维复杂且性能不佳。现在已经全面转向基于 Prometheus TSDB 的 blocks 存储，只依赖对象存储，架构清爽了很多。Cortex 目前是 CNCF 孵化项目。

Mimir

Grafana Mimir 是 Grafana Labs 在 2022 年从 Cortex fork 出来的项目，可以理解为 Cortex 的演进版本。 它保留了 Cortex 的整体架构（distributor / ingester / querier / store-gateway / compactor 那一套），在此基础上做了大量工程优化：

• 查询分片（query sharding）：把一个大查询自动拆成多个可并行执行的子查询，大幅提升重查询的速度。
• 更快的 compactor：支持按时间和序列并行压缩，能处理更大的数据量。
• 单体部署模式：用 -target=all 可以把所有组件跑在一个二进制里，本地测试和小规模部署时不需要拉起十几个微服务。这大幅降低了上手门槛。
• 乱序样本写入：支持接收时间戳早于当前 head 的样本，对边缘采集、批量回填场景很有用。
• 官方声称可扩展到 10 亿级活跃序列。

需要注意 Mimir 的许可证是 AGPLv3，而 Cortex 和 Thanos 都是 Apache 2.0。如果你要把它嵌入商业产品对外提供服务，这个差异需要法务评估。Cortex 项目本身仍在 CNCF 下继续维护，但社区活跃度和新特性投入明显向 Mimir 倾斜。

还有 VictoriaMetrics

值得一提的第四个选项。VictoriaMetrics 不是 Prometheus 生态的「原生」项目，而是一套独立实现的时序数据库，兼容 Prometheus 的 remote_write 和查询接口（用它自己的 MetricsQL，是 PromQL 的超集）。

它的卖点是极致的资源效率和运维简单性：单二进制模式下一个进程就能跑，压缩率通常比 Prometheus TSDB 高数倍，内存占用也低不少，不依赖对象存储（用本地磁盘，也有集群版）。对于「不想引入对象存储、不想管十个微服务、就想让数据存久一点」的团队来说，它往往是投入产出比最高的选择。

代价是它偏离了 Prometheus 官方生态，MetricsQL 和 PromQL 有细微行为差异，遇到问题时能参考的社区资料相对少一些。

选型速查

按规模给个粗略建议：

• 活跃序列 100 万以内、单团队、只需要 30 到 90 天数据：老老实实用单机 Prometheus（或双副本），把 retention.time 调大、磁盘给够就行。不要过早引入长期存储，它带来的运维复杂度往往超过收益。
• 多个集群、需要全局视图、需要存 1 年以上、已经有对象存储：Thanos。它对现有部署侵入最小，降采样让长跨度查询变得可用，是这个场景的最优解。
• 需要做内部监控平台、多个团队多租户、超大规模、有专门的团队维护：Mimir（新项目直接选 Mimir，不建议再从 Cortex 起步）。
• 想要最低运维成本、单一二进制、对生态兼容性要求不极端：VictoriaMetrics。

小结

• 本地存储：2 小时一个 block，WAL 保证崩溃恢复，--storage.tsdb.retention.time 和 .size 共同决定保留策略（都不设默认 15 天，只设 size 则关闭时间维度）。老的 --storage.tsdb.retention 在 3.0 已移除。
• 高可用：跑两个配置相同的独立副本，用 external_labels 里的 replica 区分。必须用 alert_relabel_configs 剥离所有副本间取值不同的标签，否则 Alertmanager 无法去重。
• Alertmanager：三副本 gossip 集群，Prometheus 要把告警发给每一个实例而不是 LB。加上 Watchdog 心跳告警，让外部服务来监控告警链路本身。
• remote_write：基于 WAL 的异步分片队列。write_relabel_configs 是控制成本和缓解积压的第一手段；高延迟远端优先调大 max_samples_per_send 而不是 max_shards。remote_read 在生产里基本不用。
• 长期存储选型：Thanos 适合「多集群 + 对象存储 + 需要降采样 + 侵入性小」；Mimir 适合「多租户 + 超大规模 + 有专职团队」；VictoriaMetrics 适合「要运维简单」；小规模团队最好的方案是什么都不上，把本地保留期调大。

到这里，Prometheus 的采集、查询、告警、扩展性话题都覆盖了。但我们始终是在「从内部看系统」——所有指标都来自被监控对象自己暴露的接口。下一章我们换个视角，看看怎么从外部像用户一样探测服务，这就是黑盒监控。