V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
Distributions
Ubuntu
Fedora
CentOS
中文资源站
网易开源镜像站
plko345
V2EX  ›  Linux

关于 prometheus HA 架构的方案

  •  
  •   plko345 · 2019-09-19 21:10:02 +08:00 · 6249 次点击
    这是一个创建于 1894 天前的主题,其中的信息可能已经有所发展或是发生改变。

    当前方案

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

    存在的问题

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

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

    其它方案

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

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

    29 条回复    2020-01-23 09:38:48 +08:00
    derek80
        1
    derek80  
       2019-09-19 21:19:00 +08:00
    两台 prometheus 无法保证采集时间同步,可以尝试开启 黏性 Session,或者查询时混合数据。
    phantomzz
        2
    phantomzz  
       2019-09-19 21:30:18 +08:00 via Android
    你这个规模,thanos 可以解决问题,thanos 会对两个 sidecar 传来的数据进行汇聚。
    Takamine
        3
    Takamine  
       2019-09-19 21:37:50 +08:00 via Android
    最近搞不好也有这个需求,插眼学习。
    plko345
        4
    plko345  
    OP
       2019-09-19 21:48:11 +08:00 via Android
    @derek80 黏性 session 是参数吗,我了解看看。查询混合数据。。。
    zhoulouzi
        5
    zhoulouzi  
       2019-09-19 23:24:24 +08:00
    Thanos 在你的环境能落地吗,Thanos 就现在的方案,感觉带来的问题,比解决的问题多
    plko345
        6
    plko345  
    OP
       2019-09-19 23:36:35 +08:00
    @zhoulouzi 还在看, 初步了解还不错, 坑什么的还没发现
    yeya24
        7
    yeya24  
       2019-09-19 23:49:03 +08:00
    @zhoulouzi 能不能说说大概为什么现在的方案问题比较大?如果只需要保证 grafana 查询的话,只需要用到 querier 和 sidecar,目前基本是没有问题的,这两个组件比较稳定了。目前的坑主要是在对象存储上,thanos store 占用的 memory 非常高。
    EPr2hh6LADQWqRVH
        8
    EPr2hh6LADQWqRVH  
       2019-09-19 23:49:09 +08:00
    HA 和 LB 还是有点区别的,传统上来讲 HA 的话,keepalived 虚 IP 就能行了
    yeya24
        9
    yeya24  
       2019-09-19 23:50:31 +08:00
    @plko345 他说的 session affinity 是 k8s service 的那个吧?我看你好像不是 k8s 环境
    zhoulouzi
        10
    zhoulouzi  
       2019-09-20 00:51:53 +08:00
    @plko345 @yeya24 个人觉得 m3db 是最适合国内的环境,可以持续关注下。
    phantomzz
        11
    phantomzz  
       2019-09-20 08:28:49 +08:00
    @zhoulouzi m3db 性能一般,我们团队压过,如果规模小可以上。
    scukmh
        12
    scukmh  
       2019-09-20 09:03:43 +08:00
    插眼学习一下,搞不好最近也得搞这个
    plko345
        13
    plko345  
    OP
       2019-09-20 17:41:42 +08:00
    @yeya24 对, 不在 K8S 环境, 不过也要考虑下
    plko345
        14
    plko345  
    OP
       2019-10-04 10:39:06 +08:00
    @derek80
    @phantomzz
    @scukmh

    请问下, 你们的公司内部有写一些适合开发接入 Prometheus 的类似中间件的吗? 有同事说要写个工具方便他们接入, 要不每次都要写个 exporter, 可是我开发个工具不是也是要制定一些规范吗, Prometheus 已经都做好了
    phantomzz
        15
    phantomzz  
       2019-10-06 08:17:43 +08:00
    @plko345 官方提供的 client lib 已经非常方便了,我们自己写的 exporter 也都是基于 client-java 和 client-go,基本我们用的中间件,官方和社区都已经提供了 prometheus metrics。
    phantomzz
        16
    phantomzz  
       2019-10-06 08:20:24 +08:00
    @plko345 不是很理解你们的场景,但是有个思路是用 client-go 写一个脚本执行器,让它去调用比如 python 脚本,约定好脚本输出,由脚本执行器解析为 prometheus metrics,这样每次定义新型的 metrics 只需要写脚本就可以了。
    nobody123123
        17
    nobody123123  
       2019-10-09 13:47:07 +08:00
    thanos 有没有人用过的?
    nobody123123
        18
    nobody123123  
       2019-10-09 13:49:07 +08:00
    @nobody123123 目前的开源的高可用方案中,感觉 thanos 算是比较靠谱的啊。 尝试过 remote write 到 es, 然后再从 es 中 remote read,效率太低了,数据存储效率下降 1-2 个数量级
    plko345
        19
    plko345  
    OP
       2019-10-10 08:35:10 +08:00 via Android
    @nobody123123 我们用阿里云的 influxdb, 不过阿里云的读写限制让人头疼
    nobody123123
        20
    nobody123123  
       2019-10-10 09:30:29 +08:00
    @plko345 influxdb 集群版貌似不开源的吧。 昨天对比了 thanos 和 cortex。 貌似 cortex 对多租户的支持比较理想。grafana cloud 的 sass 版的 prometheus 应该用的就是这个。thanos 还是更适合用作集团内部的 prometheus 方案。目前这两者不知道国内有没有公司在用的
    nobody123123
        21
    nobody123123  
       2019-10-10 09:36:48 +08:00
    Thanos
    plko345
        22
    plko345  
    OP
       2019-10-13 15:17:23 +08:00
    @nobody123123
    @phantomzz

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

    这是我了解到的, 你们是这样吗?
    phantomzz
        23
    phantomzz  
       2019-10-14 08:38:55 +08:00
    @plko345 就是 prometheus,thanos 只是 prometheus 的 query 层,初期我们调研了很多时间序列数据库,influxdb(集群收费),TimescaleDB, FiloDB,cortex
    plko345
        24
    plko345  
    OP
       2019-10-14 12:48:17 +08:00 via Android
    @phantomzz 可是官方文档并不建议使用 prometheus 本地存储,而且我们之前使用也遇到了不少问题,才买了阿里的 influxdb,但是有读写限制,用的也难受
    phantomzz
        25
    phantomzz  
       2019-10-14 20:34:47 +08:00
    @plko345 能买的起阿里云说明你们规模应该不太大吧,我觉得只要规模没大到一定程度,用哪种数据库区别应该不会太大…我们现在接近 100W 的 scrape targets...上不起云,哈哈
    weilongs
        26
    weilongs  
       2019-11-29 13:54:51 +08:00
    @plko345 请问,您这个最后落地是哪个方案呢?目前也是在考虑这个方案问题。
    plko345
        27
    plko345  
    OP
       2020-01-21 11:09:32 +08:00
    @derek80 @phantomzz 你好, 使用黏性会话解决了数据一致的问题, grafana 请求的时候始终会去访问其中一台 prometheus, 但有两个问题

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

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

    PS: 我目前还不太想使用 thanos
    phantomzz
        28
    phantomzz  
       2020-01-21 19:19:50 +08:00
    @plko345 我们现在存储已经不再用 prometheus 了,prometheus 只作为采集节点,remote storage victoriametrics。
    plko345
        29
    plko345  
    OP
       2020-01-23 09:38:48 +08:00 via Android
    @phantomzz 好的,多谢
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1538 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 35ms · UTC 17:05 · PVG 01:05 · LAX 09:05 · JFK 12:05
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.