单节点压力
早期我使用的是 Prometheus + Grafana 这一套经典的监控系统，部署便利，配置简单且有独立风格 PromQL 查询语句。
随着时间的推移，在保存一年监控数据的情况下：
-
max_over_time(prometheus_tsdb_head_series[1d])= 17M ，在 内存计算器 预估内存使用是 60G，然而实际使用在 80G 以上。 - Wal 文件夹达到 60GB 大小，重启等待 replay 需要 20 分钟才能恢复监控。
尝试使用 --storage.tsdb.wal-compression 参数压缩 wal 文件，但将 wal 文件夹大小缩小到 40GB，重启时间并无显著加快。
考虑方案
1. 多实例 Prometheus
该方案吃力不讨好！！！
- 由于 Prometheus 不支持负载均衡，那么多实例部署时需要将采集配置分散到多个实例上，需要大量工作将现有的抓取配置进行拆分。
- 数据源拆分到多实例上，我们的 grafana 监控面板需要重新定向数据源。
- 报警规则可能不止依赖一个 metrics，那么如何拆分数据源才能支持原有的报警规则？
2. Victoria
image
特点
- 组件划分：
- Vmagent, vmselect, vminsert, vmstorage ......
- 支持 Remote_write， 但不支持 Remote_read
- 基于 PromQL 独家实现的 VMQL
- 可使用 prometheus-operator crd，用 vmagent, vmrule, vmalert 将 proemtheus 的采集和报警也替换，彻底告别 prometheus
酷
- 使用了 remote_write 导入数据，Prometheus 换节点重启损失数据非常少
- 数据流像瀑布流，架构清晰容易理解，组件可以横向拓展
- group_left 表达式会自动将 multi-multi 情况转成 one-multi，简化 PromQL
不酷
- 一个 WebUI 都不提供，我怀疑他们招不起前端！Grafana 的 explore 查询入口没有 prometheus 的好用，而且 targets 和 rules 展示节点和报警实在是太方便了。
3. Thanos
image
特点
- 组件划分：
- Sidecar, Query, Store Gateway, Compact, Ruler
- Thanos 管理的最小单位是 tsdb 的本地 block，每 2 小时 Prometheus 会生成一个 block 文件，Thanos Sidecar 负责将其上传到存储端。
- 最近 2h 的数据存储于 prometheus，2h 以前的数据存储于 thanos。
酷
- 解决了 Prometheus 单点存储的蛋疼问题，优化了重启时间
- 数据长期存储单独管理，还支持数据降采样
- Query 提供和 prometheus 相同的 WebUI，照顾到用户 debug 和用户习惯
- 组件可以横向拓展
不酷
- Prometheus 2h 才打包一次块并上传，只使用本地文件系统的话，节点损坏会损失最多 2h 数据。因此，紧急换节点重启服务失效的数据时长还是比较难接受的
- Prometheus 有 remote_write，为什么要提供一个 sidecar？使用 remote_write 的话，query 只需要请求 store gateway
- Compactor 是独立组件，个人觉得放在 storage-gateway 一起就行了
- 这种结构导致了相同的文件块会在组件间传输多次
最终方案
尝试搭建了 Thanos 和 Victoria，发现 Thanos 架构导致部分数据在各组件之间存在不必要的重复传输，所以选择了更轻量的 Victoria。
