prometheus存储
prometheus 的本地存储目录结构：
./data
├── 01BKGV7JBM69T2G1BGBGM6KB12
│ └── meta.json
├── 01BKGTZQ1SYQJTR4PB43C8PD98 // 默认分组成 2 小时的块存储，初始经过压缩持久化存储为1个目录
│ ├── chunks // chunks 目录中的样本默认组合成一个或多个段文件
│ │ └── 000001 // 每个段文件最大为 512MB
│ │ └── 000002
│ ├── tombstones // 删除记录存储在单独的 tombstone 文件中（而不是立即从块段中删除数据）
│ ├── index // 索引文件
│ └── meta.json // 元数据文件，标明存储目录的起止时间和包含的存储块
├── 01BKGTZQ1HHWHV8FBJXW1Y3W0K
│ └── meta.json
├── 01BKGV7JC0RY8A6MACW02A2PJD // 最终在后台会被压缩成更长的块，包含最多保留时间的10%或31天（以较小者为准）的数据
│ ├── chunks
│ │ └── 000001
│ │ └── 000002
│ ├── tombstones
│ ├── index
│ └── meta.json // 记录chunks（段文件目录）里的内容来自多少个存储块（包含多少个2小时块）
├── chunks_head
│ └── 000001
└── wal // 最新的2小时存储在内存和预写文件wal中，重启可通过wal恢复到内存
├── 000000002 // 每128M为一段，wal目录至少包含3个段文件，甚至更多
└── checkpoint.00000001
└── 00000000
wal目录存储最近2小时的热数据，方便prometheus重启后可以恢复最近2小时数据到内存，因此wal数据尚未完全持久化，也包含未压缩数据，存储占用会比持久化+压缩后2小时的块大。
内存默认存储2小时数据，超过2小时的数据会持久化到磁盘存储成一个目录，更久的数据会进一步压缩成一个目录，每个存储目录下的meta.json会标明该存储目录的起止时间和包含的更多存储块。（一个存储目录可能包含不止一个存储块）
Prometheus启动参数与本地存储相关的：
--storage.tsdb.path: Prometheus 写入数据库的地方。默认为data/。
--storage.tsdb.retention.time: 何时删除旧数据。默认为15d。
--storage.tsdb.retention: 是否使用storage.tsdb.retention.time。
--storage.tsdb.retention.size：要保留的存储的大小，最旧的数据将首先被删除。默认为0或禁用。支持的单位：B、KB、MB、GB、TB、PB、EB。例如：“512MB”。
--storage.tsdb.wal-compression：启用预写日志 (WAL) 的压缩。此标志在 2.11.0 中引入，并在 2.20.0 中默认启用。
如果同时指定时间和大小保留策略，谁先触发使用谁。过期存储块清理发生在后台，删除过期块最多可能需要两个小时（每个存储块存储两小时数据），块在被删除之前必须完全过期。
Prometheus 平均每个样本只存储 1-2 个字节。因此，要规划 Prometheus 服务器的容量，可以使用粗略的公式：
needed_disk_space = retention_time_seconds * ingested_samples_per_second * bytes_per_sample
要降低存储占用，可以减少采集的指标数量（减少target数量或者每个target采集较少的指标），还可以增加采集间隔。不过考虑到 Prometheus 是对时间序列进行压缩，减少采集指标数量更有效。
如果本地存储由于某种原因而损坏，解决问题的策略是关闭 Prometheus，然后删除整个存储目录。还可以尝试删除单个块目录或 WAL 目录来解决问题，这意味着每个块目录会丢失大约两个小时的数据。
同样，Prometheus 可以考虑外部解决方案延长数据保留期和数据持久性。Prometheus 通过三种方式与远程存储系统集成：
- Prometheus 可以将其指标以标准化格式写入远程 URL。
- Prometheus 可以从其他 Prometheus 服务器以标准化格式接收指标。
- Prometheus 可以以标准化格式从远程 URL 读取（返回）指标数据。
参考文献：https://prometheus.io/docs/prometheus/latest/storage/