Prometheus学习系列（二十四）之存储

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

1、本地存储

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

1.1 磁盘布局

摄取的样本分为两小时的块。每一个两小时的块包含一个目录，其中包含一个或多个块文件，其中包含该时间窗口的全部时间序列样本，以及元数据文件和索引文件（将度量标准名称和标签索引到块文件中的时间序列） ）。经过API删除系列时，删除记录存储在单独的逻辑删除文件中（而不是当即从块文件中删除数据）。

当前传入样本的块保存在内存中，但还没有彻底保留。经过预写日志（WAL）防止崩溃，能够在崩溃后从新启动Prometheus服务器时重放。预写日志文件以128MB段存储在wal目录中。这些文件包含还没有压缩的原始数据，所以它们比常规块文件大得多。 Prometheus将保留至少3个预写日志文件，可是高流量服务器可能会看到三个以上的WAL文件，由于它须要保留至少两个小时的原始数据。

Prometheus服务器的数据目录的目录结构以下所示：

./data/01BKGV7JBM69T2G1BGBGM6KB12
./data/01BKGV7JBM69T2G1BGBGM6KB12/meta.json
./data/01BKGTZQ1SYQJTR4PB43C8PD98
./data/01BKGTZQ1SYQJTR4PB43C8PD98/meta.json
./data/01BKGTZQ1SYQJTR4PB43C8PD98/index
./data/01BKGTZQ1SYQJTR4PB43C8PD98/chunks
./data/01BKGTZQ1SYQJTR4PB43C8PD98/chunks/000001
./data/01BKGTZQ1SYQJTR4PB43C8PD98/tombstones
./data/01BKGTZQ1HHWHV8FBJXW1Y3W0K
./data/01BKGTZQ1HHWHV8FBJXW1Y3W0K/meta.json
./data/01BKGV7JC0RY8A6MACW02A2PJD
./data/01BKGV7JC0RY8A6MACW02A2PJD/meta.json
./data/01BKGV7JC0RY8A6MACW02A2PJD/index
./data/01BKGV7JC0RY8A6MACW02A2PJD/chunks
./data/01BKGV7JC0RY8A6MACW02A2PJD/chunks/000001
./data/01BKGV7JC0RY8A6MACW02A2PJD/tombstones
./data/wal/00000000
./data/wal/00000001
./data/wal/00000002
复制代码

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

请注意，本地存储的限制是它不是群集或复制的。 所以，面对磁盘或节点中断，它不是任意可扩展的或持久的，所以应该被视为更近期数据的短暂滑动窗口。 可是，若是您的耐久性要求不严格，您仍能够成功地在本地存储中存储多达数年的数据。

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

2、运营方面

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

• --storage.tsdb.path：这决定了Prometheus写入数据库的位置。 默认为data/。
• --storage.tsdb.retention.time：这决定了什么时候删除旧数据。 默认为15d。 若是此标志设置为默认值之外的任何值，则覆盖storage.tsdb.retention。
• --storage.tsdb.retention.size：[EXPERIMENTAL]这肯定了存储块可使用的最大字节数（请注意，这不包括WAL大小，这可能很大）。 最先的数据将被删除。 默认为0或禁用。 此标志是实验性的，能够在未来的版本中进行更改。 支持的单位：KB，MB，GB，PB。 例如：“512MB”
• --storage.tsdb.retention：不推荐使用此标志，而使用storage.tsdb.retention.time。

平均而言，Prometheus每一个样本仅使用大约1-2个字节。 所以，要规划Prometheus服务器的容量，您可使用粗略的公式：

needed_disk_space = retention_time_seconds * ingested_samples_per_second * bytes_per_sample

要调整每秒摄取样本的速率，您能够减小抓取的时间序列数（每一个目标的目标更少或更少的系列），或者能够增长刮擦间隔。然而，因为一系列样品的压缩，减小系列数可能更有效。

若是您的本地存储因任何缘由而损坏，最好的办法是关闭Prometheus并删除整个存储目录。 Prometheus的本地存储不支持非POSIX兼容的文件系统，可能会发生损坏，没法恢复。 NFS只是潜在的POSIX，大多数实现都不是。您能够尝试删除单个块目录以解决问题，这意味着每一个块目录丢失大约两个小时的数据时间窗口。一样，普罗米修斯的本地存储并不意味着持久的长期存储。

若是同时指定了时间和大小保留策略，则在该时刻将使用先触发的策略。

3、远程存储集成

Prometheus的本地存储在可扩展性和耐用性方面受到单个节点的限制。 Prometheus没有尝试解决Prometheus自己的集群存储问题，而是提供了一组容许与远程存储系统集成的接口。

3.1 概述

rometheus以两种方式与远程存储系统集成：

Prometheus能够以标准格式将其提取的样本写入远程URL。 Prometheus能够以标准格式从远程URL读取（返回）样本数据。

读写协议都使用基于HTTP的snappy压缩协议缓冲区编码。这些协议还没有被视为稳定的API，而且可能会在未来更改成使用gRPC over HTTP/2，此时能够安全地假设Prometheus和远程存储之间的全部跃点都支持HTTP/2。

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

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

请注意，在读取路径上，Prometheus仅从远程端获取一组标签选择器和时间范围的原始系列数据。对原始数据的全部PromQL评估仍然发生在Prometheus自己。这意味着远程读取查询具备必定的可伸缩性限制，由于须要首先将全部必需的数据加载到查询Prometheus服务器中，而后在那里进行处理。可是，支持PromQL的彻底分布式评估暂时被认为是不可行的。

3.2 现有的集成

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

4、连接

Prometheus官网地址：prometheus.io/ 个人Github：github.com/Alrights/pr…