存储

Prometheus 包含一个本地磁盘时间序列数据库，但也可以选择与远程存储系统集成。

本地存储

Prometheus 的本地时间序列数据库以自定义的高效格式将数据存储在本地存储上。

磁盘布局

采集的样本被分组成两小时的块。每个两小时的块由一个目录组成，该目录包含一个 `chunks` 子目录（包含该时间窗口的所有时间序列样本）、一个元数据文件和一个索引文件（将指标名称和标签索引到 `chunks` 目录中的时间序列）。`chunks` 目录中的样本被分组到一个或多个段文件中，默认每个文件最大为 512MB。当通过 API 删除序列时，删除记录会存储在单独的墓碑文件中（而不是立即从块段中删除数据）。

用于接收样本的当前块保存在内存中，并未完全持久化。它通过预写日志（WAL）来防止崩溃，当 Prometheus 服务器重启时可以重放该日志。预写日志文件以 128MB 的段存储在 `wal` 目录中。这些文件包含尚未压缩的原始数据；因此它们比常规块文件大得多。Prometheus 将保留至少三个预写日志文件。高流量服务器可能会保留三个以上的 WAL 文件，以确保至少保留两个小时的原始数据。

Prometheus 服务器的数据目录大致如下：

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

请注意，本地存储的一个限制是它不是集群化或复制的。因此，在面对驱动器或节点故障时，它不具备任意扩展性或持久性，应像管理任何其他单节点数据库一样进行管理。

建议使用快照进行备份。没有快照的备份存在丢失自上次 WAL 同步（通常每两小时发生一次）以来记录的数据的风险。通过适当的架构，可以在本地存储中保留多年的数据。

或者，可以通过远程读/写 API 使用外部存储。需要对这些系统进行仔细评估，因为它们在持久性、性能和效率方面差异很大。

有关文件格式的更多详细信息，请参阅 TSDB 格式。

压缩

最初的两小时块最终会在后台被压缩成更长的块。

压缩将创建更大的块，包含的数据跨度最长可达保留时间的 10% 或 31 天，以较小者为准。

操作方面

Prometheus 有几个配置本地存储的标志。最重要的是：

--storage.tsdb.path：Prometheus 写入其数据库的位置。默认为 `data/`。
--storage.tsdb.retention.time：样本在存储中保留多长时间。如果未设置此标志或 `storage.tsdb.retention.size`，保留时间默认为 `15d`。支持的单位：y、w、d、h、m、s、ms。
--storage.tsdb.retention.size：要保留的存储块的最大字节数。最旧的数据将首先被删除。默认为 `0` 或禁用。支持的单位：B、KB、MB、GB、TB、PB、EB。例如：“512MB”。基于 2 的幂，因此 1KB 是 1024B。只有持久化的块会被删除以遵守此保留策略，尽管 WAL 和内存映射块会计入总大小。因此，磁盘的最低要求是 `wal`（WAL 和检查点）和 `chunks_head`（内存映射的头块）目录组合占用的峰值空间（每 2 小时达到峰值）。
--storage.tsdb.wal-compression：启用预写日志 (WAL) 的压缩。根据您的数据，您可以期望 WAL 大小减半，而 CPU 负载增加很少。此标志在 2.11.0 版本中引入，并在 2.20.0 版本中默认启用。请注意，一旦启用，将 Prometheus 降级到 2.11.0 以下版本将需要删除 WAL。

Prometheus 平均每个样本只存储 1-2 个字节。因此，要规划 Prometheus 服务器的容量，您可以使用以下粗略公式：

needed_disk_space = retention_time_seconds * ingested_samples_per_second * bytes_per_sample

要降低采集样本的速率，您可以减少采集的时间序列数量（更少的目标或每个目标更少的序列），或者增加采集间隔。然而，由于序列内样本的压缩，减少序列数量可能更有效。

如果您的本地存储损坏到 Prometheus 无法启动的程度，建议备份存储目录并从备份中恢复损坏的块目录。如果您没有备份，最后的办法是删除损坏的文件。例如，您可以尝试删除单个块目录或预写日志（WAL）文件。请注意，这意味着会丢失这些块或 WAL 覆盖时间范围内的数据。

注意Prometheus 的本地存储不支持非 POSIX 兼容的文件系统，因为可能会发生不可恢复的损坏。不支持 NFS 文件系统（包括 AWS 的 EFS）。NFS 可能符合 POSIX 标准，但大多数实现并非如此。强烈建议使用本地文件系统以确保可靠性。

如果同时指定了时间和大小保留策略，则以先触发的为准。

过期的块清理在后台进行。移除过期的块可能需要长达两个小时。块必须完全过期后才能被移除。

合理调整保留大小

如果您使用 `storage.tsdb.retention.size` 来设置大小限制，您需要考虑此值相对于为 Prometheus 分配的存储空间的合理大小。明智的做法是减小保留大小以提供一个缓冲区，确保在 Prometheus 的分配存储空间变满之前删除旧条目。

目前，我们建议将保留大小设置为您分配给 Prometheus 的磁盘空间最多 80-85%。这增加了在达到任何磁盘限制之前删除旧条目的可能性。

远程存储集成

Prometheus 的本地存储受限于单个节点的可伸缩性和持久性。Prometheus 没有尝试在自身内部解决集群存储问题，而是提供了一组接口，允许与远程存储系统集成。

概述

Prometheus 通过四种方式与远程存储系统集成：

Prometheus 可以将其采集的样本以远程写入格式写入远程 URL。
Prometheus 可以以远程写入格式从其他客户端接收样本。
Prometheus 可以以远程读取格式从远程 URL 读取（返回）样本数据。
Prometheus 可以以远程读取格式返回客户端请求的样本数据。

Remote read and write architecture

远程读写协议都使用基于 HTTP 的 snappy 压缩协议缓冲区编码。读取协议尚未被视为稳定的 API。

写入协议有稳定的 1.0 版本规范和实验性的 2.0 版本规范，Prometheus 服务器均支持这两种规范。

有关在 Prometheus 中配置远程存储集成作为客户端的详细信息，请参阅 Prometheus 配置文档的远程写入和远程读取部分。

请注意，在读取路径上，Prometheus 仅从远程端获取一组标签选择器和时间范围的原始序列数据。对原始数据的所有 PromQL 评估仍然在 Prometheus 本身中进行。这意味着远程读取查询具有一定的可伸缩性限制，因为所有必要的数据都需要先加载到查询的 Prometheus 服务器中，然后在那里进行处理。然而，支持 PromQL 的完全分布式评估目前被认为是不可行的。

Prometheus 也提供这两种协议。可以通过设置 `--web.enable-remote-write-receiver` 命令行标志来启用内置的远程写入接收器。启用后，远程写入接收器端点为 `/api/v1/write`。远程读取端点可在 `/api/v1/read` 上使用。

现有集成

要了解有关与远程存储系统现有集成的更多信息，请参阅集成文档。

从 OpenMetrics 格式回填

概述

如果用户希望从 OpenMetrics 格式的数据在 TSDB 中创建块，他们可以使用回填功能。但是，他们应该小心，并注意回填过去 3 小时（当前头块）的数据是不安全的，因为这个时间范围可能与 Prometheus 仍在修改的当前头块重叠。回填将创建新的 TSDB 块，每个块包含两小时的指标数据。这限制了块创建的内存需求。将两小时的块压缩成更大的块稍后由 Prometheus 服务器本身完成。

一个典型的用例是将指标数据从不同的监控系统或时间序列数据库迁移到 Prometheus。为此，用户必须首先将源数据转换为 OpenMetrics 格式，这是下面描述的回填的输入格式。

请注意，此过程不支持原生直方图和陈旧标记，因为它们无法在 OpenMetrics 格式中表示。

用法

回填可以通过 `promtool` 命令行使用。`promtool` 会将块写入一个目录。默认情况下，此输出目录是 ./data/，您可以通过在子命令中使用所需输出目录的名称作为可选参数来更改它。

promtool tsdb create-blocks-from openmetrics <input file> [<output directory>]

创建块后，将其移动到 Prometheus 的数据目录中。如果与 Prometheus 中现有的块有重叠，对于 Prometheus v2.38 及以下版本，需要设置 ` --storage.tsdb.allow-overlapping-blocks ` 标志。请注意，任何回填的数据都受 Prometheus 服务器配置的保留策略（按时间或大小）的约束。

更长的块持续时间

默认情况下，promtool 会使用默认的块持续时间（2h）来创建块；这种行为是最普遍适用和正确的。然而，当回填大范围时间的数据时，使用更大的块持续时间值可能更有利，以加快回填速度并防止 TSDB 稍后进行额外的压缩。

`--max-block-duration` 标志允许用户配置块的最大持续时间。回填工具将选择一个不大于此值的合适块持续时间。

虽然更大的块可能会提高回填大型数据集的性能，但也存在缺点。如果（可能很大的）块中哪怕只有一个样本仍在保留策略内，基于时间的保留策略必须保留整个块。相反，即使 TSDB 只是轻微地超过了大小限制，基于大小的保留策略也会删除整个块。

因此，使用少量块进行回填，从而选择更长的块持续时间，必须谨慎进行，不建议用于任何生产实例。

记录规则的回填

概述

当创建新的记录规则时，它没有历史数据。记录规则数据仅从创建时起存在。`promtool` 可以创建历史记录规则数据。

用法

要查看所有选项，请使用：`$ promtool tsdb create-blocks-from rules --help`。

使用示例

$ promtool tsdb create-blocks-from rules \
    --start 1617079873 \
    --end 1617097873 \
    --url http://mypromserver.com:9090 \
    rules.yaml rules2.yaml

提供的记录规则文件应该是一个常规的 Prometheus 规则文件。

`promtool tsdb create-blocks-from rules` 命令的输出是一个目录，其中包含记录规则文件中所有规则的历史规则数据块。默认情况下，输出目录是 `data/`。为了利用这些新的块数据，必须将这些块移动到正在运行的 Prometheus 实例的数据目录 `storage.tsdb.path` 中（对于 Prometheus v2.38 及以下版本，必须启用 ` --storage.tsdb.allow-overlapping-blocks ` 标志）。移动后，新块将在下一次压缩运行时与现有块合并。

限制

如果您多次运行规则回填器，且开始/结束时间重叠，则每次运行规则回填器时都会创建包含相同数据的块。
记录规则文件中的所有规则都将被评估。
如果在记录规则文件中设置了 `interval`，它将优先于规则回填命令中的 `eval-interval` 标志。
如果记录规则文件中包含告警，它们目前会被忽略。
同一组中的规则无法看到先前规则的结果。这意味着不支持引用正在回填的其他规则的规则。一种解决方法是多次回填并首先创建依赖数据（并将依赖数据移动到 Prometheus 服务器数据目录，以便可以从 Prometheus API 访问）。

本页内容