Prometheus 学习之——本地存储 TSDB

---

前言

Prometheus 是 CNCF 收录的第二个项目，已经成为了云原生时代监控的标准。

本文介绍了 Prometheus 本地存储的 V3 版本。该版本主要由 Fabian 主导开发，将监控数据以时间段拆分成不同的 block，并且会压缩、合并历史数据块；还引入了 WAL，避免因为 Prometheus 重启或者宕机导致数据丢失等问题；并且，数据存储可接近每秒 10 000 000 个样本，与 V2 版本相比，对 CPU 的使用率降低 3 倍，磁盘 I/O 降低 10 倍。

---

一、TSDB 核心概念

Prometheus 的本地存储被称为 Prometheus TSDB。TSDB 的设计有两个核心：block 和 WAL，而 block 又包含 chunk、index、meta.json、tombstones。

二、详细介绍

1.block

    TSDB 将存储的监控数据按照时间分隔成 block，block 的大小并不固定，按照设定的步长倍数递增。默认最小的 block 保存 2h 监控数据。如果步数为 3、步长为 3，则 block 的大小依次为：2h、6h、18h。随着数据量的不断增长，TSDB 会将小的 block 合并成大的 block，例如将 3 个 2h 的 block 合并成一个 6h 的 block，这样不仅可以减少数据存储，还可以减少内存中的 block 个数，便于对数据进行检索。

    每个 block 都有全局唯一的名称，通过 ULID（Universally Unique Lexicographically Sortable Identifier，全局字典可排序 ID）原理生成，可以通过 block 的文件名确定这个 block 的创建时间，从而很方便地按照时间对 block 排序。对时序数据库的查询通常都会涉及连续的很多块，这种通过命名便可以排序的设计非常简便。

     block 包含 4 个主要部分：chunks、index、meta.json、tombstones，如下图：

进入本地安装好的 Prometheus 里看一下，确实如此：

1）chunks

    chunks 用于保存压缩后的时序数据。每个 chunk 的大小为 512MB，如果超过，则会别截断成多个 chunk 保存，且以数字编号命名。

2）index

    index 是为了对监控数据进行快速检索和查询而设计的，主要用来记录 chunk 中时序的偏移位置。index 的数据格式如下：

1. TOC 表。TOC 表是 index 的入口，记录 index 文件中其他表的位置。在写入其他表的数据之前都会先将当前的偏移量（8 字节）作为该表的地址记录，在读取 index 时首先读取的是 TOC 表。
2. 符号表（Symbol Table）。TSDB 对磁盘的利用发挥到了极致，为了避免标签重复存储，对每个标签只存储一次，在使用该标签时直接使用符号表中的索引。
3. 时序列表（Series）。记录该 block 中每个时序的标签及这些时序在该 block 中关联的 chunk 块。
4. 标签索引表（Label Index Table）。将具有相同标签名称（key）的标签组合到一起，从而形成标签索引（Label Index），然后通过标签索引表去查找这些索引。
5. Postings 表。每个 Posting 都代表一个标签和时序的关联关系，Postings 表则是 Posting 的索引表。

举个例子：
假如要查找某个时间段内某种指标的监控数据，TSDB 就会首先根据该时间段找到所有的 block，并加载每个 block 的 index 文件，之后要先读取 index 的 TOC 表才能找到其他表。对 TOC 表的读取很简单，直接读取 index 文件的最后 52 字节（6 张表 * 每张表 8 字节偏移量 + 4 字节的 CRC 校验和）即可。之后找到符号表，就可以确定这个指标标签的名称和值在符号表中的索引 ID，后续的查找都是基于这个 ID 的查找。

3）tombstone

    tombstone 用于对数据进行软删除。TSDB 在删除 block 数据块时会将整个目录删除，但如果只删除一部分数据块的内容，则可以通过 tombstone 进行软删除。

4）meta.json

    meta.json 记录 block 的元数据信息，主要包括一个数据块记录样本的起始时间（minTime）、截止时间（maxTime）、样本数、时序数和数据源等信息，这些元数据信息在后期对 block 进行维护（删除过期 block、合并历史 block 等）时会用到。
    一个 meta 文件的样例：

{"ulid": "01FCFPJNJARNTQZVATVBWA7BAT", //所属 block 的 ulid"minTime": 1628229600000, //block 的最小时间"maxTime": 1628280000000, //block 的最大时间"stats": {"numSamples": 4416675, //样本数"numSeries": 1838, //时序个数"numChunks": 40430 //chunk 个数},"compaction": {"level": 3, //压缩级别"sources": ["01FCDB1QZABY4DXFARW9AWCM93", //block ulid"01FCDHXF7A9EX4GFA2E7YHDSGN","01FCDRZAJ636968YMBYYPM4W0R","01FCDZMWRAYN9TFWE2730SJATG","01FCE6ZKCH25K7VX3J548GXANE","01FCEE8QMHPGGBZWQGCMHMAAZD","01FCF5DACZQSQHN0RJWR4N2VJH"],"parents": [{"ulid": "01FCDZMXC4DGMZPCGNHVQWPYWQ","minTime": 1628229600000,"maxTime": 1628251200000},{"ulid": "01FCF5DCCYTAAYE3AY389TJKV2","minTime": 1628251200000,"maxTime": 1628272800000},{"ulid": "01FCF5DACZQSQHN0RJWR4N2VJH","minTime": 1628272800000,"maxTime": 1628280000000}]},"version": 1
}

上面的 compaction 记录这个块被压缩的次数。之前介绍 block 大小时提到：小块会被 TSDB 压缩成大块，每压缩一次，level 值就会加一，并且 source 部分会记录这个大块是由哪些小块压缩而成的。

    这些 block 按照时间顺序被分割成一个个 block，其中，第 1 个 block 被称为 head block（头块），它被存储在内存中并且允许修改，而后面的 block 以只读方式存储在硬盘中。整体布局如下：

    head block 和后面的 block 都被设定为保存 2h 数据，当 head block 超过 1.5 倍大小（3h）的时候，它将被重新划分成 2h 和 1h 两部分，前面一部分将会变成只读块并被保存到硬盘中。

2.WAL

    WAL（Write-Ahead Logging，预写日志）是关系型数据库中利用日志来实现事务性和持久性的一种技术，即在进行某个操作之前先将这件事情记录下来，以便之后对数据进行回滚、重试等操作并保证数据的可靠性。

     Prometheus 为了防止丢失暂存在内存中的还未被写入磁盘的监控数据，引入了 WAL 机制。WAL 被分割成默认大小为 128MB 的文件段（Segment），文件段以数字命名，例如 00000000、00000001、00000002 等，以此类推。WAL 的写入单位是页（page），每页的大小为 32KB，所以每个段文件的大小必须是页的大小的整数倍。每个文件段都有一个"已使用的页"属性来标识在该段中已分配的页数目，如果 WAL 一次性写入的页数超过一个段的空闲页数，就会创建一个新的文件段来保存这些页，从而确保一次性写入的页不会跨段存储。

    按照每种对象设定的采集周期，Prometheus 会将周期性采集的监控数据通过 Add 接口添加到 head block 中，但这些数据没有被持久化，TSDB 通过 WAL 将提交的数据先保存到磁盘中，在 TSDB 宕机重启后，会首先启动多协程读取 WAL，从而恢复之前的状态。

---

总结