5.2 集群部署与容量规划

5.2 集群部署与容量规划

本节摘要：容量规划核心不是「磁盘 TB 数」，而是 active series 数、样本 ingest 率、compaction 窗口、查询 QPS 四维。Prometheus 单机常见上限数百万 series；Influx/VM 可水平分片；Timescale 靠 chunk 与 read replica。监控 wal_fsync_duration_seconds、head_series、compaction_duration 比 CPU 均值更早预警故障。

阅读收获

阅读完本节，你应当能够：

1. 用 scrape 间隔与 label 基数估算 active series
2. 列出 TSDB 写入健康度四类指标
3. 对比单机 Prometheus 与 VictoriaMetrics 集群扩展路径
4. 设计 cardinality 超阈值时的自动工单策略

一、问题与直觉

IoT 固件升级引发 心跳洪峰、灰度 Bug 导致异常高频打点——静态容量规划是沙堡。TSDB 的 写入放大：一个 cpu_usage{host,env} 可衍生万级 pod_uid 组合。挑战是弹性缓冲：VM 的 -memory.allowedPercent、Influx 3 无状态 write proxy 分流热点标签——尚无普适范式，但 监控驱动闭环 已成共识。

二、核心原理

Active series 估算

series ≈ metrics × Π(label_cardinality)
ingest_rate ≈ series / scrape_interval
​

例：500 metrics × 200 hosts × 20 pods = 2M series；15s scrape → 133k samples/s。

这个估算公式的价值在于「发现数字的组成」，而不是「得到一个准确答案」。每次做容量规划前，先把公式的每一层拆开：metrics 数量、每个 label 的基数、scrape 间隔。往往拆完就发现某个 label 基数远超预期，那才是真正该治理的地方——治理后公式的结果自然下降，硬件需求也一并下降。

写入健康度指标

查询侧

prometheus_engine_query_duration_seconds P99；Timescale pg_stat_user_tables seq scan 突增；Influx queryRequests 超时率。

05-05-fig01-9

磁盘粗算

磁盘/天 ≈ (samples/s × bytes_per_sample × 86400) / compression_ratio
​

Gorilla 后 float 约 1–2 byte/sample；未压缩约 16B。1M samples/s、压缩比 10、保留 90d → 约 0.8–1.5 TB 量级（不含索引开销）。

扩容决策树

容量告警触发后，先判因再动手，避免把基数问题错当容量问题：

head_series 增长？
 ├─ 是，且各 label 基数正常 → 水平扩展 / 增加分片
 ├─ 是，但某 label 基数暴涨 → 先 relabel 治理，暂缓扩容
 └─ 否，WAL/compaction 延迟高 → 磁盘 IOPS 或 batch 调优
​

三、工程实践要点

高可用：Prometheus 双副本 scrape 同 target 会 duplicate series——用 hashmod 分片 或 Thanos 去重。

容量规划工作表模板

把下面这张表当作团队容量评审的起点，每次规划都填一遍，数据会自己说话：

这张表还能暴露「规划假设」是否过时——比如 pod 数量从 20 涨到 200，series 会从 2M 跳到 20M，早发现早治理，而不是等 OOM。

集群高可用的三种形态

单机 TSDB 无论如何规划容量，都无法避免「节点宕机即监控断点」的单点风险，三种常见的高可用形态各有取舍：

形态一：Prometheus 双副本 + Thanos 去重。 两套 Prometheus 独立抓取同一批 target，通过 --enable-feature=... 的 hashmod 分片避免抓取重叠，再把数据写入同一套 Thanos 存储，查询时按 series 与时间戳去重。优点是对采集层改动小、社区方案成熟；代价是双份抓取与双份写入的开销。

形态二：VictoriaMetrics 三副本（replication）。 VM 集群的 vminsert 把写入复制到多个 vmstorage 节点，查询由 vmselect 自动合并。优点是透明复制、写入与查询都可水平扩展；代价是集群组件多、运维复杂度上升。

形态三：TimescaleDB 主从 + read replica。 主库承担写入与实时查询，只读副本承载长周期分析与报表，故障时可用 patroni 或云托管方案切换。优点是复用 PostgreSQL 生态的成熟运维；代价是写路径没有自动分片，容量受单主库限制。

选哪种取决于你对「写入不可用」的容忍度：监控断几分钟可接受的团队，双副本方案足够；对写入连续性要求更高的团队，直接上多副本集群更省心。

⚠️ 常见坑：用 P95 写入规划容量——P99.9 洪峰才是 OOM 原因。

💡 关键直觉：某云 TSDB 托管 AI 每 5min 调 VM 参数，人工干预 降 76%（CNCF 案例）——容量是动态契约，不是一次性 Excel。

自测题

1. 用「500 metrics × 200 hosts × 20 pods、15s scrape」算出 series 与 samples/s，并估算 90 天磁盘。
2. head_series 与 wal_fsync_duration_seconds 同时升高，分别指向什么根因？
3. Prometheus 双副本 scrape 为什么会 duplicate series？Thanos 如何去重？

一个容量告警的最小规则集

容量监控不需要一开始就堆几十条告警，最小可用集可以只有五条：head_series 超过规划值 80%（基数风险）、WAL 队列积压超过 1000 持续 5 分钟（写入受阻）、fsync P99 超过 100ms（磁盘到顶）、compaction P99 超过 5 秒（合并瓶颈）、查询 P99 超过告警线（查询侧压力）。这五条覆盖「写、存、查」三个方向的早期信号，且每条都有明确的后续动作，不会出现「告警了但不知道该干嘛」的局面。后续再按实际故障复盘逐步补充，让规则集与真实事故共同成长。

温故知新

• 四维：series、ingest、compaction、query
• 监控 WAL/head/compaction 先于 CPU
• horizontal：VM/Influx 分片 vs Prom 联邦
• 磁盘 看压缩比与 retention
• cardinality 治理是容量核心

下一章用决策表收口四大产品选型。