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

块目录内容： ​

$ 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存储具有简单易用、方便快捷等特点，但其自身也存在着不少短板。

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

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