prometheus容量预估需基于实测指标：活跃序列数、每秒样本数、平均样本大小及保留时长，公式为“每秒样本数×平均样本大小×保留总秒数”，并可通过调采集间隔、精简标签、分层保留等三大杠杆优化；单机健康上限约每秒80万样本，超限应优先横向拆分。
Prometheus 本身不存储“日志”，它只存储结构化的时序指标（time series），所谓“日志占用”其实是误称——真正影响磁盘的是指标样本量、标签组合爆炸、采集频率和保留时长。预估容量的关键，是把抽象的监控规模转化为可计算的样本速率与时间序列数。
核心指标：先搞清你实际在存什么
不要靠经验拍脑袋，直接查 Prometheus 自身暴露的指标：
-
活跃时间序列数：
prometheus_tsdb_head_series（当前内存中活跃的序列总数） -
每秒写入样本数：
rate(prometheus_tsdb_head_samples_appended_total[1m])（真实采集吞吐，比理论值更准） -
平均样本压缩大小：
rate(prometheus_tsdb_compaction_chunk_size_bytes_sum[1h]) / rate(prometheus_tsdb_compaction_chunk_samples_sum[1h])（通常在 1.2–1.6 字节，实测为准） -
当前块存储大小：
prometheus_tsdb_storage_blocks_bytes（验证估算是否合理）
容量公式：用实测数据代入计算
存储需求（字节） = 每秒样本数 × 平均样本大小 × 保留总秒数
例如：
- 每秒写入 12 万样本（
rate(...)[1m] ≈ 120000） - 平均样本大小 1.42 字节（实测值）
- 保留 15 天 → 15 × 24 × 3600 = 1,296,000 秒
- 估算空间 = 120000 × 1.42 × 1296000 ≈ 222 GB
这个结果比用“指标数 × 1/15 × 保留时间 × 1.2”这类静态公式更贴近真实负载，因为跳过了对标签基数、exporter 实际暴露指标数等难以准确预估的中间变量。
影响容量的三大杠杆：哪些能调，怎么调
容量不是固定值，而是可调控的结果。重点控制以下三方面：
-
减少每秒样本数：
• 调高非关键 job 的
scrape_interval（如从 15s 改为 60s） • 用metric_relabel_configs删除无用指标（如node_disk_io_time_ms、process_open_fds） • 关闭 exporter 中默认开启但业务不用的收集器（如 node-exporter 的--no-collector.wifi） -
压低时间序列基数：
• 避免将动态值（如请求 ID、用户 UID、随机 UUID）打入标签
• 合并高基数标签：把
path="/api/v1/users/123"归一为path="/api/v1/users/{id}"• 限制标签维度数量，单指标建议 ≤ 4 个有效标签 -
缩短或分层保留时间：
• 默认 15 天可降为 7 天（适合测试/开发环境）
• 高频指标保留短周期，聚合后指标（通过 recording rule 生成）保留更久
• 用
remote_write将原始数据转存到长期存储（如 VictoriaMetrics、Thanos）
什么时候该考虑扩容或拆分？
单机 Prometheus 的健康写入上限约为每秒 80 万个样本。超过这个量级，不仅磁盘增长快，还会出现 WAL 写满、查询延迟飙升、规则计算超时等问题。
判断依据不只是磁盘空间，更要关注：
-
prometheus_tsdb_wal_storage_size_bytes持续高位且增长快（WAL 压力大） -
prometheus_tsdb_head_truncations_failed_total> 0（截断失败，说明 head block 清理不过来） - rule evaluation duration 超过 scrape interval（规则跟不上采集节奏）
- 内存使用长期 > 70%，且
go_memstats_heap_inuse_bytes持续爬升
达到瓶颈后，优先横向拆分（按业务/集群/地域部署多个 Prometheus），再考虑联邦或远程读写，而不是盲目堆磁盘。
