存储

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

本地存储

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

磁盘布局

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

传入样本的当前块保存在内存中，并且没有完全持久化。它通过预写日志 (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 和 m-mapped chunks 会计入总大小，但只有持久块会被删除以遵守此保留策略。因此，磁盘的最低要求是 wal（WAL 和 Checkpoint）和 chunks_head（m-mapped Head chunks）目录组合占用的峰值空间（每 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 以四种方式与远程存储系统集成
  • Prometheus 可以以远程写入格式将其摄取的样本写入远程 URL。
  • Prometheus 可以以远程写入格式从其他客户端接收样本。
  • Prometheus 可以以远程读取格式从远程 URL 读取（返回）样本数据。

Remote read and write architecture

Prometheus 可以以远程读取格式返回客户端请求的样本数据。

远程读取和写入协议都使用基于 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 小时（当前 head 块）回填数据是不安全的，因为此时间范围可能与 Prometheus 仍在更改的当前 head 块重叠。回填将创建新的 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 访问它）。

本文档是 开源的。请通过提交 issue 或 pull request 来帮助改进它。