Prometheus高可用与长期存储：Thanos及Mimir实战

单机Prometheus部署简单，但进入生产后很快会遇到三个问题：采集节点故障造成监控盲区、本地磁盘无法长期保留历史数据、跨集群查询和规则计算越来越慢。简单地给Prometheus挂一块更大的磁盘，无法解决故障域、数据复制、查询扩展和多租户治理问题。

本文从监控系统自身的SLI出发，说明双Prometheus、Alertmanager高可用、Thanos与Grafana Mimir的架构选择、对象存储、去重、容量规划、迁移和灾难恢复。示例仅用于解释关键配置，部署前应按当前官方文档核对参数和版本兼容性。

一、先定义监控平台目标

监控平台也必须有SLO。建议至少定义：

• 采集可用性：关键目标在多少时间内不能出现数据空洞；
• 写入延迟：样本从采集到可查询允许多长时间；
• 查询可用性：仪表盘和告警查询的成功率与P95延迟；
• 告警可用性：从异常发生到通知送达的最大时间；
• 数据保留：原始样本和降采样数据分别保留多久；
• 恢复目标：对象存储、规则和配置损坏后的RPO、RTO；
• 租户隔离：不同团队是否需要配额、权限和成本归属。

“Prometheus进程存活”并不代表监控系统可用。采集、远程写、规则、查询、通知和存储链路都需要独立验证。

二、双Prometheus不是主备

推荐让两个Prometheus副本同时抓取同一批目标，形成主动—主动采集。每个副本使用独立持久卷，避免共享磁盘成为单点。

global:
  scrape_interval: 30s
  evaluation_interval: 30s
  external_labels:
    cluster: prod-shanghai
    replica: prometheus-a

另一副本使用不同的replica值。业务标签必须一致，副本标签必须唯一。外部系统通过副本标签去重，不能让两个副本完全使用相同外部标签。

两副本都应独立服务查询。入口可通过负载均衡器切换，但直接轮询两个本地Prometheus不会自动消除重复序列，跨副本统一查询应交给Thanos Query或Mimir等上层系统。

三、Alertmanager高可用与告警去重

Prometheus副本可以同时计算相同告警并发送到Alertmanager集群。Alertmanager通过集群状态协调通知去重、分组、静默和抑制。

alerting:
  alertmanagers:
  - static_configs:
    - targets:
      - alertmanager-0.monitoring.svc:9093
      - alertmanager-1.monitoring.svc:9093
      - alertmanager-2.monitoring.svc:9093

注意：

• Alertmanager集群通信端口与通知出口都需放行；
• 各节点配置必须一致；
• 静默、模板和路由变更要版本化；
• 通知接收端应具备幂等或去重能力；
• 告警标签不要包含副本标签，否则同一事件无法正确合并；
• 监控Alertmanager集群成员、通知失败、队列和配置加载状态。

高可用不是“部署三个副本”就结束，还要验证丢失一个节点、网络分区和通知端限流时的行为。

四、Prometheus本地TSDB的职责

本地TSDB适合保存近期数据并支持快速规则计算。即使使用Thanos或Mimir，也不应盲目把本地保留时间调成零。

prometheus \
  --storage.tsdb.path=/prometheus \
  --storage.tsdb.retention.time=15d \
  --storage.tsdb.wal-compression \
  --web.enable-lifecycle

容量估算需要考虑活跃时间序列、采样间隔、样本大小、WAL、索引、压缩块和安全余量。最容易失控的不是采样频率，而是标签基数。用户ID、请求ID、完整URL、容器ID等无界值不应成为标签。

持续监控head series、series churn、WAL大小、checkpoint与重放时间、compaction失败、磁盘空间、out-of-order样本、scrape样本数和目标数量变化。

五、方案一：Thanos架构

Thanos围绕Prometheus构建长期存储和全局查询，常见组件包括：

典型路径是Prometheus本地写入TSDB，Sidecar暴露近期数据并把完成的块上传对象存储，Store Gateway提供历史数据，Query统一查询并按副本标签去重。

六、Thanos Sidecar与外部标签

Prometheus必须配置稳定且唯一的外部标签。

global:
  external_labels:
    cluster: prod-shanghai
    prometheus: platform
    replica: prometheus-a

Query启用去重时指定副本标签。集群、环境和Prometheus逻辑分片标签不能随Pod名称随机变化，否则同一序列会在历史中断裂。对象存储凭据只授予所需bucket和操作权限，不要把长期密钥写进公开ConfigMap。

七、对象存储不是普通备份目录

Thanos和Mimir都高度依赖对象存储。需要确认：

• bucket是否独占或有清晰前缀；
• 版本控制、生命周期和不可变策略；
• 服务端加密与密钥可用性；
• 跨区域复制及其延迟；
• LIST、GET、PUT、DELETE性能和费用；
• 对象存储不可用时读写路径如何退化；
• 删除和保留策略由谁执行。

不要让云平台生命周期策略先于Compactor保留策略删除块，否则元数据与数据对象可能不一致。跨账号复制可以提升灾备能力，但必须演练从副本bucket恢复。

八、Compactor、降采样和保留

Compactor负责块压缩、保留和可选降采样。其工作目录需要持久且有足够空间，同时避免多个Compactor无协调地处理同一数据集。

保留策略应与查询需求对应：原始分辨率用于近期排障，中期数据可保留较低分辨率，长期数据用于趋势和容量规划，合规数据另行归档。降采样会改变查询精度，不适合替代审计、计费或精确事件分析。

九、方案二：Grafana Mimir架构

Mimir提供水平扩展、高可用、多租户和长期Prometheus兼容存储。常见组件包括Distributor、Ingester、Querier、Query Frontend、Store Gateway、Compactor、Ruler与Alertmanager。部署模式和内部架构会随版本演进，生产设计应以当前官方架构文档为准。

Prometheus或OpenTelemetry Collector通常通过remote_write把样本送入Mimir：

remote_write:
- url: https://mimir.example.com/api/v1/push
  headers:
    X-Scope-OrgID: platform
  queue_config:
    capacity: 20000
    max_shards: 20
    min_shards: 2

remote_write队列不是无限缓冲。远端持续不可用时，WAL会积压并最终超过保留能力，因此要对失败、延迟、积压和丢弃建立告警。

十、Thanos与Mimir如何选择

选择原则不是“哪个更新”，而是团队责任边界、数据规模、租户数量、对象存储条件和运维能力。小规模环境先解决双副本、告警高可用和备份，避免过早引入复杂分布式系统。

十一、remote_write可靠性

监控pending samples、failed/retried samples、highest sent timestamp与当前时间差、shard数量、WAL读取、远端429/5xx及单租户限制。限流时不要仅提高重试次数，需要明确是单序列过热、租户配额、网络带宽、Distributor容量还是Ingester环问题。

十二、查询路径与查询保护

长时间范围、大量正则和高基数聚合可能占满Querier。建议：

• Query Frontend按时间拆分查询；
• 缓存结果与索引元数据；
• 设置最大时间范围、样本数和并发；
• 对租户实施公平调度；
• 使用recording rule预计算常用聚合；
• 为仪表盘限制默认时间范围；
• 追踪慢查询和取消无用查询。

告警规则和交互查询应使用独立优先级或资源池，避免一次大范围排障查询拖垮规则计算。

十三、规则与告警放在哪里

常见选择：

1. 每个Prometheus本地计算规则，延迟低且故障域清晰；
2. Thanos Ruler或Mimir Ruler基于全局数据计算；
3. 两者混合：本地规则保障关键实时告警，全局规则用于跨集群和容量分析。

无论哪种方式，都要避免同一规则在多个位置重复通知。规则文件纳入Git并测试：

promtool check rules rules/*.yaml
promtool test rules tests/*.yaml

十四、容量规划

至少收集每秒摄入样本数、活跃序列、每日新增序列、每租户占比、对象存储增量、查询QPS、扫描字节、P95延迟、规则耗时、缓存命中率及故障时剩余容量。

按峰值而非日均规划，并预留单可用区或单节点故障后的容量。高可用副本会增加摄入和存储开销，去重主要发生在查询，不代表底层只存一份。

十五、监控监控系统

必须建立独立的meta-monitoring：

• Prometheus目标发现与抓取失败；
• 规则评估失败和超时；
• Alertmanager通知失败；
• Sidecar上传、块数量和Store同步；
• Compactor失败、积压和重复块；
• Mimir环状态、复制失败和租户限流；
• 对象存储错误和延迟；
• 查询错误率、超时和排队；
• remote_write时间差；
• 端到端合成指标与测试告警。

最好由独立故障域的监控实例观察主监控平台，避免平台整体故障时没有证据。

十六、迁移实施路线

阶段一：稳定单集群

统一标签、清理高基数、双Prometheus、Alertmanager集群、规则测试和本地存储监控。

阶段二：接入长期存储

选择非关键集群试点Thanos或Mimir，验证对象存储、去重、保留、查询和恢复。

阶段三：双写与结果比对

旧平台和新平台并行，比对关键PromQL、告警、仪表盘和历史数据。

阶段四：迁移查询和规则

先迁移只读仪表盘，再迁移全局规则和关键告警，每一步保留回退入口。

阶段五：平台治理

建立租户、配额、标签规范、成本归属、数据删除和升级流程。

十七、灾难恢复

需要备份和重建的对象包括平台配置、规则、告警路由、Grafana数据源与仪表盘、对象存储、租户权限、密钥、DNS、证书和部署清单。对象存储有副本不代表平台能恢复，必须在隔离环境验证历史查询、规则加载和告警结果。

十八、常见故障

查询出现双线或数值翻倍

检查外部标签、replica标签、Query去重参数以及两副本目标集合是否一致。

历史数据突然缺失

检查Sidecar上传、Compactor、对象存储生命周期、Store Gateway同步和时间范围，不要先重建bucket索引。

remote_write持续落后

检查网络、远端限流、队列、WAL、单序列热点和下游容量，确认最老未发送时间是否逼近WAL保留边界。

查询拖垮集群

限制时间范围和并发，启用查询拆分与缓存，定位高基数或无界正则，并把常用聚合转为recording rule。

告警重复通知

核对告警标签、Alertmanager集群状态、路由配置和通知接收端去重。

十九、生产验收清单

• [ ] 两个Prometheus副本位于不同故障域并独立存储；
• [ ] 外部标签稳定且副本标签唯一；
• [ ] Alertmanager集群完成通知去重和故障演练；
• [ ] 标签基数、WAL、磁盘和规则耗时有告警；
• [ ] 对象存储权限、加密、版本和生命周期已审计；
• [ ] Thanos Compactor或Mimir关键组件具备高可用设计；
• [ ] remote_write积压与最老未发送时间可观测；
• [ ] 查询有限额、缓存和公平调度；
• [ ] 关键告警有端到端测试；
• [ ] 长期数据和平台配置做过隔离恢复。

二十、官方参考

• Prometheus High Availability
• Prometheus Storage
• Prometheus Remote Write
• Thanos Components
• Thanos Storage
• Grafana Mimir Documentation
• Grafana Mimir Architecture

监控平台的价值不是保存最多指标，而是在故障时持续提供可信信号。双副本、长期存储、去重和查询扩展都应服务于这个目标，并通过故障注入和恢复演练持续证明。