这货怎么出现的就不多做解答了，K8S 标配监控解决方案，还能各种预计算、各种自发现「国内云厂商的自发现令人着急」，简直就是看上去很美，但是能用着用着单点存储问题暴露无遗「这边先停止吐槽」，今天只讨论存储，个人浓缩整理为主。
本地存储
- 将采集到的指标以时间序列的方式保存在内存中，并定时保存到硬盘中也就是本地存储中（TSDB），按 Block 块的方式来存储数据，每 2 小时由内存刷入磁盘同时后台压缩成更大的 Block，类似 LSM 的思路。用于短期窗口的 timeseries 数据保存和查询，并且不具有高可用性。
- 数据压缩功能是在 2.11.0 之后的版本中提供
- 采用 Wal 机制，2 小时内的数据存储在内存中的同时，会记录一份日志，当异常宕机后再次启动会刷入对应 Block 中 「故宕机 Or 重启 简直惨不忍睹，主要还是基本无法能控制 2 小时写多少，想快速恢复的方法可以直接删除 Wal 最惨需要丢弃 2 小时数据」
- 存储方式称为时间分片，每个 Block 都是一个独立的数据库。好处是查多少打开多少效率高。
- 官方推荐按照平均 1-2 bytes/sample，可基于如下大致计算出需要多少本地磁盘
needed_disk_space = retention_time_seconds * ingested_samples_per_second * bytes_per_sample
远端存储
- 普通公司没有太多 infra 研发资源的话，优先推荐直接交给云厂商就好了，分布式存储太难了不是能搭出来就是好「Aws 有 S3，Aliyun 有 SLS」
- 主要还是为了解决本地存储装不了多少，数据丢失的风险 「监控数据不让丢这个是另外一个故事」
- Prometheus 借助 adapter 实现远端存储的 read/write，看上去很好的解决了单机装不下的问题，也确实解决了「但是本地问题依然完蛋」
- adapter 借助 Prometheus 标准协议进行 Block 读取操作 「读内存」，remote_storage/example_write_adapter
Remote
Note that on the read path, Prometheus only fetches raw series data for a set of label selectors and time ranges from the remote end. All PromQL evaluation on the raw data still happens in Prometheus itself. This means that remote read queries have some scalability limit, since all necessary data needs to be loaded into the querying Prometheus server first and then processed there. However, supporting fully distributed evaluation of PromQL was deemed infeasible for the time being. 「读远端与本地合并，优先本地」
TSDB
- Writing a Time Series Database from Scratch
- [ 翻译 ] 从头编写一款时间序列数据库
- Amazon Timestream
- FaceBook Gorilla
- FaceBook Gorilla 开源版本 C++ 实现 Beringei
- Aliyun HiTSDB 基于 Gorilla 实现
- Google LevelDB「哪里都能看到它，Prometheus 用它放索引」
- Promethues TSDB Format
- Coding for SSDs
