手记

prometheus大规模监控的问题

背景

prometheus在采集metrics上可以说占比比较大,他有丰富的预计算,label操作,表达式等等优势。支持多种抓取方式,尤其是服务发现的采集方式,增加了不少动态性。
prometheus开箱即用,配置也方便。但是他没有一个合理的配置变更的方式。例如没有服务发现的情况。例如物理机监控。数据量少的时候没有什么问题,例如10台机器,抓取的时候label可以在job里处理,例如1-5是A服务,6-10是B服务。当出现机器的加入,我们的机器和服务的关系发生了一定变动。1-7是A服务,8-12是B服务。这里我们修改配置还是也能接受的一个动作。如果说有1w台呢,prometheus一台也不够用了,2台一起操作,都分的A服务的抓取和B服务的抓取。此时变动5000台,每个配置服务都得改变,可能此时就要刷新2个prometheus的所有的配置。这个配置的变更就比较麻烦了。

解决方案

  • 方案1
    大家自然想到了注册服务,通过服务发现来控制,所有的变动都体现在了配置中心,prometheus只要去更新配置中心的数据就可以做到刷新了。
    这里有两个问题,1是同一个服务的数据分散在不同的机器上。如何做聚合,第二个是压力如何分摊。
    第一个问题可以通过thanos或者远程存储的问题解决,不是本文重点。可以查询解决。
    压力分配就是比较麻烦的事情了。例如一台prometheus的压测其实是3000物理机数据。那么1w的数据分配就要体现在服务中,确保能获取到自己能承受范围的采集量。这种变动理论是可行的,不过容易出现人为的失误,导致了prometheus挂掉。
  • 方案2
    压力分配的问题确实比较麻烦。需要准确的获取和分配。我们还可以去掉prometheus的状态。prometheus那边不区分服务A,服务B。他只要抓取自己的3000台机器即可。服务的标签在采集端获取。例如可以加入固定的配置文件,环境变量等等。都可以满足我们的需求,这样的做的好处就是在prometheus那边是无感知的,就算失误的操作,把所有的标签每个机器都改成了A。prometheus那边也不会有任何的变化,prometheus那边的压力已经是固定的了,不会因为标签的变化而改变。

无状态的抓取

无状态的的采集端要有比较复杂的设计,例如获取环境变量,或者特定的配置中心等等。因为prometheus的无状态化,让采集变的比较复杂。他需要能更新或者获取一个被更新的数据,以此达到在暴露指标的时候就知道最终结果。所以暴露的数据的信息会更多,对网络的压力也会上浮。

总结

根据上面的内容,我们可以简单分为三种情况

手动调整 服务发现 无状态
规模 数量少 无压力风险 大规模
抗变化能力
变更错误 有风险 有风险 无风险
部署难度 简单 复杂 采集端复杂
网络压力 - - 变大
0人推荐
随时随地看视频
慕课网APP