【知识分享】如何进行Prometheus 的存储容量规划
概述
Aquila Insight 使用Prometheus (作为 AQUILA 角色之一) 收集和存储监控指标, 这些指标默认持久化在本地 (暂时不支持保存数据到第三方存储服务), 可以通过查看AQUILA 配置 prometheus.data.dir获得本地存储目录，建议将 prometheus.data.dir 单独挂到一块磁盘上, 使用默认值可能会发生根分区磁盘 IO 竞争.
在部署 Prometheus 服务之前，对服务的存储用量进行规划是十分重要的。否则，运维人员无法对业务数据的规模和所需存储资源的量级获得直观认识。分配的存储资源过多，会导致资源闲置与成本浪费; 分配的存储容量不足，则无法应对业务的增长，严重影响监控服务的稳定性。
本篇帖子主要分析 Prometheus 在 TDH 集群上运行时存储用量受到哪些因素影响，以及如何根据这些因素得出一个经验公式, 用来预估 Prometheus 的磁盘使用量和内存消耗
经验公式
正式分析 Prometheus 的磁盘使用量和内存消耗之前, 先给一个基本的经验公式，可以直接根据这个经验公式来合理分配磁盘与内存.
Manager节点: 3个
Pod总数: 74个
服务数量: 4个
估算如下:
Prometheus 对内存的使用主要由以下两个部分组成：
索引数据所需的内存较少，一个经验公式为，每一千个时间测量点大约需要 1M 内存.
结论
Aquila Insight 使用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 官方文档说明: 磁盘大小 = 保留时间 * 每秒获取样本数 * 样本大小
- Aquila 保留时间默认为 15天
- 每秒获取样本数= 抓取间隔内收集的样本总数 / 抓取间隔获取 (默认 15s).
- 压缩后单个样本平均大小(1-2 bytes)
- 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 兆/每小时
除了持久化在磁盘的样本之外, 根据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 节点上:
- 每小时产生压缩样本大小为: 6.47 兆, 默认最大保留时间为 15 天,
- 每小时产生 WAL 文件大小为: 51.76 兆, 经验保留时间为 6小时
- 上述两项按照最大值计算得出磁盘占用: 2.6 G
Prometheus 对内存的使用主要由以下两个部分组成：
- 留存于内存的活跃样本和排队等待持久化的过期样本
- 索引数据
1) 留存于内存的活跃样本和排队等待持久化的过期样本
留存于内存的活跃样本和排队等待持久化的样本和 WAL 文件大小差不多, 经验保留时间为 6小时.
- 对于单个 TDH 节点Prometheus, 留存于内存的活跃样本和排队等待持久化的过期样本大小为: 310 兆
索引数据所需的内存较少，一个经验公式为，每一千个时间测量点大约需要 1M 内存.
- 对于单个 TDH 节点Prometheus, 索引数据大小为: (15000(测量点) / 1000) = 15 兆
结论
单个 TDH 节点上
- 消耗内存大小为: 325 兆
- –query.max-samples=50000000: Maximum number of samples a single query can load into memory
概述
Aquila Insight 使用Prometheus (作为 AQUILA 角色之一) 收集和存储监控指标, 这些指标默认持久化在本地 (暂时不支持保存数据到第三方存储服务), 可以通过查看AQUILA 配置 prometheus.data.dir获得本地存储目录，建议将 prometheus.data.dir 单独挂到一块磁盘上, 使用默认值可能会发生根分区磁盘 IO 竞争.
在部署 Prometheus 服务之前，对服务的存储用量进行规划是十分重要的。否则，运维人员无法对业务数据的规模和所需存储资源的量级获得直观认识。分配的存储资源过多，会导致资源闲置与成本浪费; 分配的存储容量不足，则无法应对业务的增长，严重影响监控服务的稳定性。
本篇帖子主要分析 Prometheus 在 TDH 集群上运行时存储用量受到哪些因素影响，以及如何根据这些因素得出一个经验公式, 用来预估 Prometheus 的磁盘使用量和内存消耗
经验公式
正式分析 Prometheus 的磁盘使用量和内存消耗之前, 先给一个基本的经验公式，可以直接根据这个经验公式来合理分配磁盘与内存.
Manager节点: 3个
Pod总数: 74个
服务数量: 4个
估算如下:
Prometheus 对内存的使用主要由以下两个部分组成：
索引数据所需的内存较少，一个经验公式为，每一千个时间测量点大约需要 1M 内存.
结论
Aquila Insight 使用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 官方文档说明: 磁盘大小 = 保留时间 * 每秒获取样本数 * 样本大小
- Aquila 保留时间默认为 15天
- 每秒获取样本数= 抓取间隔内收集的样本总数 / 抓取间隔获取 (默认 15s).
- 压缩后单个样本平均大小(1-2 bytes)
- 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 兆/每小时
除了持久化在磁盘的样本之外, 根据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 节点上:
- 每小时产生压缩样本大小为: 6.47 兆, 默认最大保留时间为 15 天,
- 每小时产生 WAL 文件大小为: 51.76 兆, 经验保留时间为 6小时
- 上述两项按照最大值计算得出磁盘占用: 2.6 G
Prometheus 对内存的使用主要由以下两个部分组成：
- 留存于内存的活跃样本和排队等待持久化的过期样本
- 索引数据
1) 留存于内存的活跃样本和排队等待持久化的过期样本
留存于内存的活跃样本和排队等待持久化的样本和 WAL 文件大小差不多, 经验保留时间为 6小时.
- 对于单个 TDH 节点Prometheus, 留存于内存的活跃样本和排队等待持久化的过期样本大小为: 310 兆
索引数据所需的内存较少，一个经验公式为，每一千个时间测量点大约需要 1M 内存.
- 对于单个 TDH 节点Prometheus, 索引数据大小为: (15000(测量点) / 1000) = 15 兆
结论
单个 TDH 节点上
- 消耗内存大小为: 325 兆
- –query.max-samples=50000000: Maximum number of samples a single query can load into memory
评论
登录后可评论
.jpg)
