第 9 章 · 存储与高可用 — Prometheus 完全指南

9.1 本地 TSDB 的边界

Prometheus 本地存储简单可靠，但有硬限制：单机、无副本、非长期。

Retention 保留策略: --storage.tsdb.retention.time（默认 15d）按时间保留；--storage.tsdb.retention.size 按磁盘上限保留，先到先删。
本地磁盘依赖: 数据只在本机磁盘，机器挂了数据即失（重启可从 WAL 恢复未落盘部分）。
容量估算: 约 1~2 字节/样本。磁盘 ≈ 序列数 × 每序列采样频率 × 保留时长 × 每样本字节。
为何不做分布式: Prometheus 刻意保持单机简单以保证可靠性；扩展交给下游远程存储系统。

# 容量粗算示例
100万序列 × (1样本/15s) × 30天 × 2字节
= 1e6 × (86400/15) × 30 × 2 ≈ 345 GB

9.2 高可用：跑两份

最简单的 HA：部署两个配置相同的 Prometheus，各自独立抓取全部目标。二者数据可能有微小差异，但都能独立告警。Alertmanager 集群会对两份重复告警去重。

HA 副本的查询问题

两个副本数据不完全一致，Grafana 直接指向其中一个会在切换时出现曲线断裂。要无缝去重查询，需引入 Thanos Querier 或 VictoriaMetrics 之类的全局查询层。

9.3 remote_write / remote_read

Prometheus 可把抓到的样本实时转发到远程存储，本地只留短期热数据用于告警：

# prometheus.yml
remote_write:
  - url: "http://victoriametrics:8428/api/v1/write"
    queue_config:
      max_samples_per_send: 2000
      capacity: 10000
      max_shards: 30
    write_relabel_configs:      # 只转发部分指标省成本
      - source_labels: [__name__]
        regex: "go_.*"
        action: drop

remote_read:
  - url: "http://victoriametrics:8428/api/v1/read"

9.4 长期存储方案对比

方案	架构	特点
Thanos	Sidecar + 对象存储 + Querier	CNCF 项目，复用本地 TSDB，数据上传 S3；全局查询、降采样、去重
VictoriaMetrics	单/集群，自研存储引擎	资源省、写入快、PromQL 兼容（MetricsQL）；运维简单，国内流行
Grafana Mimir	微服务集群 + 对象存储	Cortex 后继，水平扩展强，多租户，适合超大规模
Cortex	微服务集群	Mimir 的前身，多租户 SaaS 化

Thanos 简要架构

Sidecar: 贴着每个 Prometheus 跑，把 block 上传到对象存储（S3/OSS），并对外提供实时查询接口。
Store Gateway: 让 Querier 能查对象存储里的历史 block。
Querier: 全局查询入口，聚合多个 Sidecar + Store 的数据并去重，Grafana 指它即可。
Compactor: 后台压缩 + 降采样（5m/1h），降低历史数据查询成本。

9.5 联邦 Federation

联邦让一个"全局 Prometheus"从多个"下级 Prometheus"抓取聚合后的指标，适合跨数据中心汇总：

  - job_name: "federate"
    honor_labels: true
    metrics_path: "/federate"
    params:
      "match[]":
        - '{__name__=~"job:.*"}'   # 只拉 recording rule 聚合结果
    static_configs:
      - targets: ["prom-dc1:9090", "prom-dc2:9090"]

联邦只拉聚合结果

联邦不该拉全量原始指标（量太大）。配合下级的 recording rule 先聚合成 job:xxx 前缀的序列，全局层只拉这些。现代大规模更推荐 remote_write 到 VictoriaMetrics/Mimir 而非层层联邦。

9.6 性能与容量调优

控制基数：用 metric_relabel_configs drop 无用高基数指标；查 prometheus_tsdb_head_series 监控序列总数。
用 recording rule：把仪表盘的重查询预聚合，减轻查询压力。
合理抓取间隔：非核心指标拉长到 30s/60s，量减半。
限制查询：--query.max-samples、--query.timeout 防止大查询打垮实例。
用 SSD：TSDB 对随机 IO 敏感，生产务必 SSD/NVMe。

# 自监控：关注这几个指标
prometheus_tsdb_head_series               # 当前活跃序列数（基数）
rate(prometheus_tsdb_head_samples_appended_total[5m])  # 每秒摄入样本
prometheus_remote_storage_samples_pending  # 远程写积压
prometheus_target_scrape_pool_exceeded_target_limit_total  # 超限

9.7 小结与下一步

本地 TSDB 单机短期，靠 retention 控制留存；HA 就跑两份 + Alertmanager 去重。
长期与全局查询用 remote_write 到 Thanos/VictoriaMetrics/Mimir，本地只留热数据。
联邦适合拉聚合结果；调优核心是控基数、用 recording rule、上 SSD。
最后一章 生产实战：用 kube-prometheus-stack 监控真实 K8s 集群，落地 SLO。