Prometheus监控实战系列二十一：容量管理

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

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

1、内部存储机制

Prometheus内置了一个本地的时间序列数据库，通过该数据库进行样本数据的存储，这种设计方式较大地简化了产品部署与管理的复杂性。

从2.x版本开始，Prometheus采用了更加高效的存储机制。系统采集的样本数据会按照两个小时为一个时间窗口，将期间产生的数据存储在一个块（Block）中，每个块目录包含该时间窗口内所有的样本数据（chunks），一个元数据文件（meta.json）和一个索引文件（index)。

当通过API删除时间序列指标时，删除记录会存储在单独的墓碑（tombstone ）文件中，而不会立即从文件中删除。

存储根目录：

[root@server ~]# ls -l /data/
total 142564
drwxr-xr-x 3 root root        68 Feb 26 11:42 01GT5X1RHRV2Q0Q69RZAEZMRJD
drwxr-xr-x 3 root root        68 Mar 10 11:08 01GV4QV3FRC4NSH88JTN6456RH
drwxr-xr-x 2 root root        20 Mar 10 11:08 chunks_head
-rw-r--r-- 1 root root     20001 Mar 10 11:16 queries.active
drwxr-xr-x 3 root root        81 Mar 10 11:08 wal

块目录内容：

[root@server ~]# tree data/
data/
├── 01GVSHDK8SXYHJBWQFA55W3F4C
│   ├── chunks      # 样本数据
│   │   └── 000001
│   ├── index       # 索引文件
│   ├── meta.json   # 元数据文件
│   └── tombstones  # 墓碑文件

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

WAL目录内容:

[root@server data]# ls -l wal/
total 164164
-rw-r--r-- 1 root root 134217728 Mar 23 18:12 00000000
-rw-r--r-- 1 root root  19089331 Mar 23 20:51 00000001

通过时间窗口的方式保存样本数据，可以较好地提升Prometheus的查询效率，当系统查询一段时间范围内所有的样本数据时，只需要简单的从落在该范围内的块中查询数据即可。同时，这种方式也可以简化历史数据的删除逻辑，当一个块的时间范围超过需要保留的范围后，直接清理该块即可。

2、容量管理

在了解系统的存储机制后，我们可以开始对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存储具有简单易用、方便快捷等特点，但其自身也存在着不少短板。该数据库本身不适用于大数据量的存储与查询，并且不支持集群模式，这使得该架构不适合用在大规模的监控环境中。

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

上一篇：Prometheus监控实战系列二十：监控Kubernetes集群（下）
下一篇：Prometheus监控实战系列二十二：远程存储