存储

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。如果未设置此标志或 storage.tsdb.retention 或 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 映射的块计入总大小，但仅删除持久块以遵守此保留。因此，磁盘的最低要求是 wal（WAL 和检查点）和 chunks_head（m 映射的头块）目录组合所占用的峰值空间（每 2 小时达到峰值）。
  • --storage.tsdb.retention：已弃用，建议使用 storage.tsdb.retention.time。
  • --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 目录以解决问题。请注意，这意味着每个块目录将丢失大约两小时的数据。同样，Prometheus 的本地存储并非旨在作为长期存储；外部解决方案提供扩展保留和数据持久性。

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

如果同时指定了时间和大小保留策略，则将使用首先触发的策略。

过期块清理在后台发生。删除过期块可能需要长达两小时的时间。块必须完全过期才能被删除。

调整保留大小

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

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

远程存储集成

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

概述

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

  • Prometheus 可以将它摄取的样本写入远程 URL 中的标准化格式。
  • Prometheus 可以以标准化格式接收来自其他 Prometheus 服务器的样本。
  • Prometheus 可以从远程 URL 中的标准化格式读取（回填）样本数据。

Remote read and write architecture

读写协议都使用通过 HTTP 的 snappy 压缩协议缓冲区编码。这些协议尚未被视为稳定的 API，并且将来可能会更改为使用通过 HTTP/2 的 gRPC，当可以安全地假设 Prometheus 和远程存储之间的所有跃点都支持 HTTP/2 时。

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

可以通过设置 --web.enable-remote-write-receiver 命令行标志来启用内置的远程写入接收器。启用后，远程写入接收器端点为 /api/v1/write。

有关请求和响应消息的详细信息，请参阅 远程存储协议缓冲区定义。

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

现有集成

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

从 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 将为块使用默认块持续时间（2 小时）；此行为通常是最适用和正确的。但是，当在很长一段时间内回填数据时，使用更大的块持续时间值可能更有利，以加快回填速度并防止 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 可以访问它）。

本文档是 开源 的。请通过提交问题或拉取请求来帮助改进它。