Prometheus做为一款功能强大的监控系统,能够支持对海量的监控数据进行抓取与查询。而对于监控管理员而言,如何对系统的容量进行合理地规划,确保这些数据得到有效地保存与维护则是一项重要工作。

本文主要介绍Prometheus的存储机制以及对存储容量的评估方法。

# 一.内部存储机制

Prometheus内置了一个本地的时间序列数据库,通过该数据库进行样本数据的存储,这种设计方式较大地简化了产品部署与管理的复杂性。 从2.x版本开始,Prometheus采用了更加高效的存储机制。

系统采集的样本数据会按照两个小时为一个时间窗口,将期间产生的数据存储在一个块(Block)中,每个块目录包含该时间窗口内所有的样本数据(chunks),一个元数据文件(meta.json)和一个索引文件(index)。 当通过API删除时间序列指标时,删除记录会存储在单独的墓碑(tombstone )文件中,而不会立即从文件中删除。

# 存储根目录:

$ ls -l ./data/
total 20
drwxr-xr-x. 3 root root    68 Jan  7 13:33 01FRSGF2NBJ21HZW1QM2594CB9   # 块目录 
drwxr-xr-x. 3 root root    68 Jan  7 15:00 01FRSNCMS0Q1Y9Q9KKT6TTXH3C   # 块目录
drwxr-xr-x. 2 root root    34 Jan  7 15:00 chunks_head
-rw-r--r--. 1 root root     0 Jan  7 10:33 lock
-rw-r--r--. 1 root root 20001 Jan  7 15:19 queries.active
drwxr-xr-x. 2 root root    54 Jan  7 15:00 wal        
1
2
3
4
5
6
7
8

# 块目录内容:

$ ls -l 01FRSGF2NBJ21HZW1QM2594CB9 total 1532 drwxr-xr-x. 2 root root 20 Jan 7 13:33 chunks # 样本数据 -rw-r--r--. 1 root root 1560504 Jan 7 13:33 index # 索引文件 -rw-r--r--. 1 root root 280 Jan 7 13:33 meta.json # 元数据文件 -rw-r--r--. 1 root root 9 Jan 7 13:33 tombstones # 墓碑文件

在当前时间窗口内正在收集的样本数据,则会被Prometheus保存到内存中。同时 ,为了确保系统在出现意外崩溃后数据依然能够恢复,Prometheus会通过预写日志(WAL)的方式进行临时保存,在重新启动后会从WAL目录进行加载,从而恢复数据。预写日志以128MB 的段存储在WAL目录中,这些文件包含尚未压缩的原始数据,因此你会看到它们将明显大于块文件。

# WAL目录内容:

ls -l ./wal/ total 38048 -rw-r--r--. 1 root root 23625728 Jan 7 13:33 00000000 -rw-r--r--. 1 root root 11206656 Jan 7 15:00 00000001 -rw-r--r--. 1 root root 3064462 Jan 7 15:23 00000002 通过时间窗口的方式保存样本数据,可以较好地提升Prometheus的查询效率,当系统查询一段时间范围内所有的样本数据时,只需要简单的从落在该范围内的块中查询数据即可。同时,这种方式也可以简化历史数据的删除逻辑,当一个块的时间范围超过需要保留的范围后,直接清理该块即可。

# 二. 容量管理

在了解系统的存储机制后,我们可以开始对Prometheus的容量来进行评估 。

按照官方数据,每个样本指标平均占用存储空间为1-2 字节,我们通过下面的公式可对总容量进行粗略的计算:

needed_disk_space = retention_time_seconds * ingested_samples_per_second * bytes_per_sample

注:retention_time_seconds 为数据保留时间范围内的总时间数;ingested_samples_per_second为平均每秒获取的指标数量;bytes_per_sample为每条样本数据占用的空间大小,此处取2 字节。

ingested_samples_per_second的数量可以采用下面的PromQL表达式获取,该表达式会计算出最近5分钟平均每秒获取的样本数量

rate(prometheus_tsdb_head_samples_appended_total[5m])

假设系统平均每秒获取的指标数量为10万个,按照默认样本保留 15天计算,那么需要的空间至少为259G。

(3600*24*15)* 100000 * 2 ≈ 259G

从上面的公式中也可以看出,容量的大小取决于样本保留时间(retention_time_seconds)和指标的样本数量。对于样本保留时间,可以在系统启动时通过--storage.tsdb.retention 参数进行修改。而样本数量的控制有两种方式,一种是减少目标的指标数量,另一种则是增加采集样本的时间间隔,考虑到Prometheus会对时间序列进行压缩,所以减少时间序列数量的效果会更明显。

# 结语

Prometheus原生的TSDB存储具有简单易用、方便快捷等特点,但其自身也存在着不少短板。

该数据库本身不适用于大数据量的存储与查询,并且不支持集群模式,这使得该架构不适合用在大规模的监控环境中。

对此,更好的方案是通过外置存储的方式来保存,关于这块内容我们将在下篇的“远程存储“一文中讲解。

上次更新: 2022/5/17 11:31:39