文章：https://cairry.github.io/docs/Prometheus/storage.html，内容如下

Prometheus 容量规划

存储需求主要取决于以下几个因素：

1. 指标数量（Time Series Count）：你正在监控的总指标数量。
2. 样本速率（Sample Rate）：每个指标每秒生成的样本数。
3. 保留时间（Retention Time）：数据需要保留的时间长度。
4. 样本大小（Sample Size）：每个样本在磁盘上占用的空间，通常为 1.2 字节/样本（经过压缩）。

存储需求计算公式

存储需求(字节) = 指标数量 × 样本速率 × 保留时间(秒) × 样本大小(字节)

详细说明

• 指标数量：通常是 Prometheus 中活跃的时间序列数。
  • prometheus_tsdb_head_series：计算出活跃样本数
• 样本速率：一般情况下，每个指标每 15 秒收集一个样本（这是 Prometheus 的默认抓取间隔），因此样本速率为 1/15 秒，即 0.067 样本/秒。
  • 活跃样本数 / 15s = 样本速率
• 保留时间：可以根据需要设置，一般为 15 天。
• 样本大小：经过 Prometheus 的压缩后，每个样本大约占用 1.2 字节。

示例计算

假设你有 10,000 个指标，每个指标每 15 秒抓取一个样本，数据保留 15 天。

1. 样本速率：每个指标每 15 秒抓取一次，即 1/15 样本/秒。
2. 保留时间：15 天 = 15 * 24 * 60 * 60 秒。
3. 样本大小：每个样本占用 1.2 字节。

大约 10.4 GB

公式解释

• 指标数量：10,000 表示你有 10,000 个指标。
• 样本速率：0.067 表示每个指标每秒的采样率。
• 保留时间：1,296,000 秒是 15 天的总秒数。
• 样本大小：1.2 字节是每个样本的压缩大小。

数据获取方式

每秒抓取的样本数

sum(rate(prometheus_tsdb_head_samples_appended_total[1m])) by (job)

正在监控的指标数

count({__name__=~".+"}) by (job)

压缩后的样本大小

rate(prometheus_tsdb_compaction_chunk_size_bytes_sum[1h]) / rate(prometheus_tsdb_compaction_chunk_samples_sum[1h])

• 计算过去 1 小时内，prometheus_tsdb_compaction_chunk_size_bytes_sum压缩过程中每秒处理的块大小的增量。
• 计算过去 1 小时内，prometheus_tsdb_compaction_chunk_samples_sum压缩过程中每秒处理的样本数量的增量。
• 将两者相除，得到每个样本的平均大小。

自身容量监控指标

• prometheus_tsdb_storage_blocks_bytes：表示当前块存储的大小。
• prometheus_tsdb_head_samples_appended_total：表示已追加的样本总数。
• prometheus_tsdb_wal_storage_size_bytes：表示 WAL 存储的大小。

文章：https://community.transwarp.cn/question/83，内容如下

概述
Aquila使用Prometheus (作为 AQUILA 角色之一) 收集和存储监控指标, 这些指标默认持久化在本地 (暂时不支持保存数据到第三方存储服务), 可以通过查看AQUILA 配置 prometheus.data.dir获得本地存储目录，建议将 prometheus.data.dir 单独挂到一块磁盘上, 使用默认值可能会发生根分区磁盘 IO 竞争.

在部署 Prometheus 服务之前，对服务的存储用量进行规划是十分重要的。否则，运维人员无法对业务数据的规模和所需存储资源的量级获得直观认识。分配的存储资源过多，会导致资源闲置与成本浪费; 分配的存储容量不足，则无法应对业务的增长，严重影响监控服务的稳定性。

本篇帖子主要分析 Prometheus 在 TDH 集群上运行时存储用量受到哪些因素影响，以及如何根据这些因素得出一个经验公式, 用来预估 Prometheus 的磁盘使用量和内存消耗

经验公式
正式分析 Prometheus 的磁盘使用量和内存消耗之前, 先给一个基本的经验公式，可以直接根据这个经验公式来合理分配磁盘与内存.

Prometheus 需要磁盘大小 = 节点个数 * 2.6 GB
Prometheus 需要内存大小 = 节点个数 * 350 MB

磁盘容量规划
首先明确几个概念:

• 监控节点: 一个 exporter 进程被认为是一个监控节点。Manager 在安装 AQUILA时，默认每个节点都会安装一个 node-exporter 收集节点信息(CPU, Memory 等), 每个节点安装一个 tdh-exporter 收集 TDH Services metrics (目前有: HDFS, YARN, ZOOKEEPER, KAFKA, HYPERBASE, INCEPTOR). 故在 TDH 集群上, 每个节点有两个 exporter 进程.
• 测量点: 一个测量点代表了某监控节点上的一个观测对象. 从某测量点采集到的一组样本数据构成一条时间序列（time series).
• 抓取间隔: Promtheus 对某个监控节点采集 metrics 的时间间隔. 一般为同类监控节点设置相同的抓取间隔. AQUILA对应的配置值为: prometheus.node.exporter.scrape_interval(默认15s) 和 prometheus.tdh.exporter.scrape_interval(默认60s)
• 保留时间: 样本数据在磁盘上保存的时间,超过该时间限制的数据就会被删除. 存储在磁盘上的样本都是经过编码之后的样本(对样本进行过数据编码, 一般为 double-delta 编码). AQUILA对应的配置值为 prometheus.storage.retention.time(默认15天)
• 活跃样本留存时间: 留存于内存的活跃样本（已经被编码）在内存保留时间. 在内存中的留存数据越多，查询过往数据的性能越高，但是消耗内存也会增加. 在实际应用中，需要根据所监控的业务的性质，设定合理的内存留存时间. AQUILA对应的配置值为 prometheus.min-block-duration (默认2h), prometheus.max-block-duration(默认26h). Facebook 在论文 《Gorilla: A Fast, Scalable, In-Memory Time Series DataBase》 （Prometheus实现参考论文）中给出了留存内存时间的一般经验: 26 h.
• 样本(测量点)大小: 根据 Prometheus 官方文档说明, 每一个编码后的样本大概占用1-2字节大小

环境:
Manager节点: 3个
Pod总数: 74个
服务数量: 4个

估算如下:
每个监控节点上的测量点由具体使用的 exporter 定义, 测量点可根据 exporter 暴露给 prometheus 的 api 获取

• ode-exporter(单个节点) 有 534 个测量点, 现场的话可以打开node_exporter的/metrics界面, 统计出实际的值
• tdh-exporter(单个节点) 有 481 个测量点 (根据安装服务数量决定)
• manager-exporter(总共) 有接近 3000 个测量点 (根据安装服务数量决定)
• kube-state-metrics(总共) 有接近 15000 个测量点 ((和pod数量相关))
• prometheus (总共) 自身指标有 265 个测量点
• etcd (单个节点) 有 1200 个测量点
• kubelet (单个节点) 有1225 个测量点 (和pod数量相关)
• kubelet-caadvisor(单个节点) 有4897 个测量点 (和pod数量相关)
• mysqld exporter (单个节点) 有接近 2400 个测量点
• Aquila 自身指标 (单个节点) 有接近 300 个测量点

根据以上概念可以得出, Prometheus 存储用量受到: 测量点(即样本数量), 样本大小, 抓取间隔, 保留时间四个因素影响.

根据 Prometheus 官方文档说明: 磁盘大小 = 保留时间 * 每秒获取样本数 * 样本大小

• Aquila 保留时间默认为 15天
• 每秒获取样本数= 抓取间隔内收集的样本总数 / 抓取间隔获取 (默认 15s).
• 压缩后单个样本平均大小(1-2 bytes)

根据以上公式我们可以得出在 TDH 集群上, 单个节点 Promethues 压缩样本使用磁盘大小公式为:

• node-exporter disk usage: 534 / 30 * (60 * 60) * 2 = 0.12 兆/每小时
• tdh-exporter disk usage: 481 / 30 * 60 * 60 * 2 = 0.11 兆/每小时
• manager-exporter disk usage: 3000 / 15 / (3节点) * 60 * 60 * 2 = 0.46 兆/每小时
• kube-state-metrics disk usage: 15000 / 30 / (3节点) * 60 * 60 * 2 = 1.15 兆/每小时
• prometheus disk usage: 265 / 15 / (3节点) * 60 * 60 * 2 = 0.04 兆/每小时
• etcd disk usage: 1200 / 15 * 60 * 60 * 2 = 0.55 兆/每小时
• kubelet disk usage: 1225 / 15 * 24 * 60 * 60 * 2 = 0.56 兆/每小时
• kubelet-caadvisor disk usage: 4897 / 15 * 60 * 60 * 2 = 2.24 兆/每小时
• mysqld exporter disk usage: 2400 / 15 * 60 * 60 * 2 = 1.1 兆/每小时
• Aquila disk usage: 300 / 15 * 60 * 60 * 2 = 0.14 兆/每小时

上述几项之和相加可以得出结论: 对于单个 TDH 节点, Prometheus 每小时产生持久化压缩样本大小为 6.47 兆

除了持久化在磁盘的样本之外, 根据Prometheus 官方文档说明, Prometheus 还在在磁盘上写入 write-ahead-log (WAL) 来防止 Prometheus 程序突然崩溃导致在内存中的未写入的磁盘的样本的丢失.

• WAL 文件大小取决于Prometheus 留存于内存的活跃样本的大小. 而留存于内存的活跃样本的大小又取决于每秒获取样本数和活跃样本留存内存时间.
• 记录活跃样本信息的 WAL 文件都是 raw data, 故大小比经过 Prometheus 编码之后的样本大得多. Prometheus 官方文档中说明至少会保存3个 write-ahead log files(每一个最大为128M), 如果实际使用中留存内存的样本数量非常大或者时间比较长, 那么用来记录样本的 WAL 文件可能需要大于三个.
• 计算 WAL 文件 大小和计算压缩样本大小方法类似, 唯一区别是活跃样本是 raw data.
• 收集上来测量点由 timestamp 和 value 构成, 总大小为 16 bytes. 考虑到近似时间段的 timestamp 有大部分是相同的, 因此每个样本实际大小不会超过 16 bytes. 这里姑且按照每个样本 16 bytes 大小计算. WAL file 的保留时间按照官方说明是至少 2 小时, 但实际环境中肯定是大于 2小时. 按照实际经验值来算为 6 小时左右

根据上述观点可以得出结论: 对于单个 TDH 节点Prometheus 每小时产生 WAL 文件 大小为 6.47 * (16 / 2) = 51.76 兆

结论: 在单个 TDH 节点上:

1. 每小时产生压缩样本大小为: 6.47 兆, 默认最大保留时间为 15 天,
2. 每小时产生 WAL 文件大小为: 51.76 兆, 经验保留时间为 6小时
3. 上述两项按照最大值计算得出磁盘占用: 2.6 G

内存容量规划

Prometheus 对内存的使用主要由以下两个部分组成：

• 留存于内存的活跃样本和排队等待持久化的过期样本
• 索引数据

1)  留存于内存的活跃样本和排队等待持久化的过期样本
留存于内存的活跃样本和排队等待持久化的样本和 WAL 文件大小差不多, 经验保留时间为 6小时.

• 对于单个 TDH 节点Prometheus, 留存于内存的活跃样本和排队等待持久化的过期样本大小为: 310 兆

2)  索引数据
索引数据所需的内存较少，一个经验公式为，每一千个时间测量点大约需要 1M 内存.

• 对于单个 TDH 节点Prometheus, 索引数据大小为: (15000(测量点) / 1000) = 15 兆

Prometheus 内存消耗等于上述几部分相加

结论单个 TDH 节点上

• 消耗内存大小为: 325 兆

内存调优参数配置

• –query.max-samples=50000000: Maximum number of samples a single query can load into memory

更多：https://www.echo.cool/docs/observability/prometheus/prometheus-storage-and-performance/storage-capacity-planning/