关于 prometheus HA 架构的方案

[plko345]

当前方案

现在使用的是两个 prometheus 节点(配置完全相同), 存储 influxdb, 前端 nginx 负载均衡

存在的问题

1. 两个节点的数据不完全一样, 图表展示的时候, 刷新前后的趋势图有点差别, 有点差别还挺明显
2. 当我尝试弄挂掉一个节点, 重启时(节点还没完全可用), dashboard 中的图表中, 有的有数据, 有的显示 请求失败

本以为存储在 influxdb 读的数据是一致的, 但现在看来并不是

其它方案

1. nginx 的 upstream 中设置 ip_hash 之类的, 用来解决问题 1, 但感觉也不靠谱
2. Thanos 方案, 但了解的还不够多, 感觉能解决问题 2, 但不确定能否解决问题 1

请问各位公司里是怎么处理这两个问题的?

[nobody123123]

Thanos

[plko345]

@nobody123123
@phantomzz

你们用的 thanos 的存储方案是什么? 好像 thanos 不支持管理写入 influxdb 等时序数据库, 如果它管理存储好像是存到对象存储的(如 s3, oss 等)

这是我了解到的, 你们是这样吗?

[0NF09LJPS51k57uH]

@plko345 就是 prometheus，thanos 只是 prometheus 的 query 层，初期我们调研了很多时间序列数据库，influxdb(集群收费),TimescaleDB, FiloDB，cortex

[plko345]

@phantomzz 可是官方文档并不建议使用 prometheus 本地存储，而且我们之前使用也遇到了不少问题，才买了阿里的 influxdb，但是有读写限制，用的也难受

[0NF09LJPS51k57uH]

@plko345 能买的起阿里云说明你们规模应该不太大吧，我觉得只要规模没大到一定程度，用哪种数据库区别应该不会太大…我们现在接近 100W 的 scrape targets...上不起云，哈哈

[weilongs]

@plko345 请问，您这个最后落地是哪个方案呢？目前也是在考虑这个方案问题。

[plko345]

@derek80 @phantomzz 你好, 使用黏性会话解决了数据一致的问题, grafana 请求的时候始终会去访问其中一台 prometheus, 但有两个问题

1. grafana 上所有图表都会去这台 prom 上查询, 但如果出现大查询, 负载都在这台 prom 上, 内存占用很高, 会出现 OOM 危险
2. grafana 的所有查询请求都是以 grafana server 的 cookie 为准, 而用户是通过 grafana server 间接的请求, 因此 cookie 始终只有一个, 所有用户的查询都会发往一台 prom, 这也很危险...

请问你们是否遇到类似的问题, 我搜索了相关的情况, 但都没有比较好的解决方案, 目前做了限制查询量来防止比较大的查询导致的 OOM

PS: 我目前还不太想使用 thanos

[0NF09LJPS51k57uH]

@plko345 我们现在存储已经不再用 prometheus 了，prometheus 只作为采集节点，remote storage victoriametrics。

[plko345]

@phantomzz 好的，多谢