数据既能存储在本地，也能存储在远端系统中。

本地存储

样本数据两小时为一个组（块）。

./data
├── 01BKGV7JBM69T2G1BGBGM6KB12                 # 两小时
│   └── meta.json
├── 01BKGTZQ1SYQJTR4PB43C8PD98                 # 两小时
│   ├── chunks
│   │   └── 000001                                # 每 512M 一个
│   ├── tombstones                              # 通过 API 被删除的记录保存在这里
│   ├── index                                    # 指标名的索引、标签的索引
│   └── meta.json
├── 01BKGTZQ1HHWHV8FBJXW1Y3W0K                 # 两小时
│   └── meta.json
├── 01BKGV7JC0RY8A6MACW02A2PJD                 # 两小时
│   ├── chunks
│   │   └── 000001
│   ├── tombstones
│   ├── index
│   └── meta.json
├── chunks_head
│   └── 000001
└── wal
    ├── 000000002
    └── checkpoint.00000001
        └── 00000000

新传入指标的当前块在内存中，并未持久化，其实通过 WAL 进行保护。当服务重启时，其将被重放。
WAL 保存在 wal/ 目录，每个段 128M。
WAL 包含原始数据，所以会比较大。最少保留三个 WAL 文件，高负载服务器会更多。

本地存储，并非为大规模扩展场景设计。存储可靠性，需要依赖 RAID 等技术，SNAPSHOT 用于备份。
除了本地存储，使用 Remote R/W API 也是一种选择，但要仔细评估这些远程存储。

数据压缩

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

压缩将创建更大的块，其中包含的数据：最多为保留时间的 10%，或 31 天，以较小者为准；

运维方面

Prom 提供多个选项来控制本地存储相关的内容，如字面意思：
1）–storage.tsdb.path
2）–storage.tsdb.retention.time
3）–storage.tsdb.retention.size

如果 time 和 size 同时存在，则先触发的将被使用。

过期块清理发生在后台。删除过期块最多可能需要两个小时，原因是块在被删除之前必须完全过期。

为了减小样本摄入频率，可以减少抓取频率，或者减少抓取数量（效果更好）。

如果数据损坏，则需要关闭服务，删除某些块目录（导致两小时内的数据丢失），或删除 WAL 目录。这也意味着，数据的丢失。

Non-POSIX FS

某些文件系统，Non-POSIX，不建议使用。NFS 也存在文件，所以建议使用本地文件系统。

远程存储

为了解决本地存储的问题，Prom 的 Remote R/W API 能够键数据写入远程存储。

有三种集成方式：
1）Prom 向 Remote 写入；
2）Prom 向 Remote 读取；
3）Prom 能够从其他 Prom 接收样本（以标准格式）；内置 Remote W Receiver 通过 –web.enable-remote-write-receiver 开启；

R/W 协议使用快速压缩的 Protocol Buffer，在 HTTP 上。以后，或许会被替换为 gRPC over HTTP/2；

PromQL 的分布式执行暂时是不可能的。PromQL 的解析发生在 Prom 中，而非远程系统，所以 Prom 必须先读取数据在进行处理。

远程存储集成，参考 Integrations 文档。

数据回填（Backfilling）

mtulio/prometheus-backfill: Backfill historical data to Prometheus
thanos – Back-filling prometheus (and related system) metrics?
Prometheus backfilling. Backfill Prometheus metrics in… | by Tom Vincent
prometheus/storage.md at v2.24.0 · prometheus/prometheus
从Prometheus居然不能填充mock数据说起

简单说就是数据填充，向 Prom 中 Mock 数据（如果我们没有理解错）。

针对回填相关的内容，这里不再深入展开。在后面的具体场景中，我们将进一步探究相关内容。

补充说明：
1）Prometheus是一个建立在时序数据库(tsdb)上的指标监控系统，而不是个通用的时序数据库，跟InfluxDB从根本上来说，根本不是一回事。
2）Prometheus是个指标(metric)系统，它定时去抓取目标系统的实时状态(指标)，而不关心这些数据的实际发生时间。
3）Prometheus不适合用来记录在特定时间发生的事件数据，处理这些数据是Elasticsearch或者InfluxDB更擅长的事。
4）Prometheus虽然不支持为指标设置时间戳，但是，通过promtool这个命令行工具，可以将历史数据以Prometheus的数据格式直接写入，或者说回填。

回填规则

通过 Rule 来生成数据，需要借助 promtool 命令。

针对回填相关的内容，这里不再深入展开。在后面的具体场景中，我们将进一步探究相关内容。