背景

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的无状态化，让采集变的比较复杂。他需要能更新或者获取一个被更新的数据，以此达到在暴露指标的时候就知道最终结果。所以暴露的数据的信息会更多，对网络的压力也会上浮。

总结

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