关于prometheus:第06期Prometheus-存储

Description: 本文是介绍了 Prometheus 的两种贮存类型和本地存储的原理

Author: 孙健，爱可生上海研发核心成员，研发工程师

一、前言

Prometheus 提供了本地存储，本文次要讲述 Prometheus 自带的 tsdb 时序数据库。

二、本地存储（tsdb）

1. 什么是时序数据库

时序数据库全称为工夫序列数据库。工夫序列数据库次要用于指解决带工夫标签（依照工夫的程序变动，即工夫序列化）的数据，带工夫标签的数据也称为工夫序列数据。次要用于存储周期性的采集各种实时监控信息。

2. 特点

• 垂直写，程度读

• 数据点写入扩散，且数据量微小
• 热点数据显著

3．存储配置

• --storage.tsdb.path：数据存储目录。默认为 data/。
• --storage.tsdb.retention.time：数据过期清理工夫。默认为 15 天。
• --storage.tsdb.wal-compression：此标记启用预写日志（WAL）的压缩。依据您的数据，您能够预期 WAL 大小将缩小一半，而额定的 CPU 负载却很少。此标记在 2.11.0 中引入，默认状况下在 2.20.0 中启用。请留神，一旦启用，将 Prometheus 降级到 2.11.0 以下的版本将须要删除 WAL。

4．目录构造

首先，block 在这里是一个数据块，每个数据块绝对独立，由一个目录组成，该目录里蕴含：一个或者多个 chunk 文件（保留 timeseries 数据）、一个 metadata 文件、一个 index 文件（通过 metric name 和 labels 查找 timeseries 数据在 chunk 文件的地位）。

./data
├── 01BKGV7JBM69T2G1BGBGM6KB12
│   └── meta.json
├── 01BKGTZQ1SYQJTR4PB43C8PD98
│   ├── chunks
│   │   └── 000001
│   ├── tombstones
│   ├── index
│   └── meta.json
├── 01BKGTZQ1HHWHV8FBJXW1Y3W0K
│   └── meta.json
├── 01BKGV7JC0RY8A6MACW02A2PJD
│   ├── chunks
│   │   └── 000001
│   ├── tombstones
│   ├── index
│   └── meta.json
└── wal
    ├── 00000002
    └── checkpoint.000001

5．贮存原理(write)

Prometheus 按 2 小时一个 block 进行存储，最新写入的数据保留在内存 block 中，达到 2 小时后写入磁盘。为了避免程序解体导致数据失落，实现了 WAL（write-ahead-log）机制，启动时会以写入日志 (WAL) 的形式来实现重播，从而复原数据。

这种程度分区减少了一些劣势：

• 查问工夫范畴时，咱们能够轻松疏忽该范畴之外的所有数据块。只须要读取工夫范畴内的 block 数据；
• 当实现一个块时，咱们能够通过程序写入一些较大的文件来保留内存数据库中的数据，防止随机带来的写放大；
• 最近 2 小时的数据放在内存，使得查问最多的数据始终缓存在内存中；
• 删除旧数据的开销很小，只须要删除一个目录。

6．mmap(read)

应用 mmap 读取压缩和合并的大文件（不占用过多的句柄），建设过程虚拟地址和文件偏移量之间的映射关系，并且仅在查问和读取相应地位时才将数据读入物理内存。绕过文件系统页面缓存，缩小一个数据正本。查问完结后，Linux 零碎会依据内存压力主动回收相应的内存，并可在回收之前将其用于下一个查问命中。因而，应用 mmap 主动治理查问所需的内存缓存的长处是治理简略且解决效率高。

7．索引

个别 Prometheus 的查问是把 metric + label 做关键字的，而且是很宽泛，齐全用户自定义的字符，因而没方法应用惯例的 sql 数据库，Prometheus 的存储层应用了全文检索中的 倒排索引【文末链接】概念，将每个工夫序列视为一个小文档。而 metric 和 label 对应的是文档中的单词。

例如，requests_total{path=”/status”, method=”GET”, instance=”10.0.0.1:80″}是蕴含以下单词的文档：

• name=”requests_total”
• path=”/status”
• method=”GET”
• instance=”10.0.0.1:80″

提醒：因为 Prometheus 索引定义很宽泛，label 会作为索引，官网不倡议将 label 定义为动静的值，会导致索引的文件大小变大。

8．数据压缩

数据压缩的次要操作包含合并 block、删除过期数据、重构 chunk 数据。其中合并多个 block 成为更大的 block，能够无效缩小 block 个数，当查问笼罩的工夫范畴较长时，防止须要合并很多 block 的查问后果。为进步删除效率，删除时序数据时，会记录删除的地位，并不会立刻从 chunk 文件删除，而是将删除的记录先记录在 block 目录下的 tombstone 文件中，只有 block 所有数据都须要删除时，才将 block 整个目录删除。因而 block 合并的大小也须要进行限度，防止保留了过多已删除空间（额定的空间占用）。比拟好的办法是依据数据保留时长，按百分比（如 10%）计算 block 的最大时长。

三、近程存储

Prometheus 的本地存储在可伸缩性和持久性方面受到单个节点的限度。Prometheus 并没有尝试从本地存储中解决这个问题，而是提供了一组容许与近程存储系统集成的接口。

Prometheus 通过两种形式与近程存储系统集成：

• Prometheus 能够将提取的样本以规范格局写入近程 URL。
• Prometheus 能够以标准化格局从近程 URL 读取（返回）样本数据。

读取和写入协定都应用基于 HTTP 的疾速压缩协定缓冲区编码。该协定尚未被认为是稳固的 API，当能够平安地假设 Prometheus 和近程存储之间的所有跃点都反对 HTTP / 2 时，该协定未来可能会更改为在 HTTP / 2 上应用 gRPC。

四、参考

1. https://fabxc.org/tsdb/
2. https://prometheus.io/docs/pr…
3. https://docs.google.com/prese…
4. 倒排索引：https://nlp.stanford.edu/IR-b…

相干内容方面的常识，大家还有什么疑难或者想晓得的吗？连忙留言通知小编吧！