一. Prometheus 单节点抗不过来了！

单节点压力

早期我使用的是 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

该方案吃力不讨好！！！

1. 由于 Prometheus 不支持负载均衡，那么多实例部署时需要将采集配置分散到多个实例上，需要大量工作将现有的抓取配置进行拆分。
2. 数据源拆分到多实例上，我们的 grafana 监控面板需要重新定向数据源。
3. 报警规则可能不止依赖一个 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。