内容简介:Prometheus是CNCF基金会管理的一个开源监控项目,由于其良好的架构设计和完善的生态,迅速成为了监控领域事实上的标准,尤其是在云原生领域。随着深入地了解Prometheus,你会发现一些非常好的功能:
Prometheus是CNCF基金会管理的一个开源监控项目,由于其良好的架构设计和完善的生态,迅速成为了监控领域事实上的标准,尤其是在云原生领域。
随着深入地了解Prometheus,你会发现一些非常好的功能:
- 服务发现使配置更加容易。Prometheus支持consul,etcd,kubernetes以及各家公有云厂商自动发现。对于监控目标动态发现,这点特别契合Cloud时代,应用动态扩缩的特点。我们无法想象,在Cloud时代,需要运维不断更改配置。
- 开源社区建立了数百个exporter。基本上涵盖了所有基础设施和主流中间件。
- 工具库可从您的应用程序获取自定义指标。基本上主流开发语言都有对应的 工具 库。
- 它是CNCF旗下的OSS,是继Kubernetes之后的第二个毕业项目。Kubernetes已经与Promethues深度结合,并在其所有服务中公开了Prometheus指标。
- Pushgateway,Alermanager等组件,基本上涵盖了一个完整的监控生命周期。
对于一家小型单位,Prometheus足够了。几乎不需要任何的开发,就足以应对所有监控需求。
我们都知道Prometheus,自身的时序数据库TSDB是一个单机的数据库,不支持分布式是其天生的劣势。当你的 metrics 数量足够多的时候,单机Prometheus就显得捉襟见肘。您的Prometheus服务器开始崩溃,大多时候是内存问题。Prometheus中的内存使用量与存储的时间序列数量成正比,并且随着时间序列数量的增加,Prometheus会OOM。具有数百万个指标的Prometheus可以使用超过100GB的RAM,很多时候我们受限制于一些主机本身的大小,我们无法不断的通过纵向调整机器大小来解决这个问题。
因此解决Prometheus的扩展性,是打造企业分布式监控平台的关键。
如何解决Prometheus的扩展性
联邦
官方的解决方案是集群联邦,主要提供了分层联邦和跨服务联邦。
分层联邦
分层联邦允许 Prometheus 能够扩展到十几个数据中心和上百万的节点。在此场景下,联邦拓扑类似一个树形拓扑结构,上层的 Prometheus 服务器从大量的下层 Prometheus 服务器中收集和汇聚的时序数据。
跨服务联邦
在跨服务联邦中,一个服务的 Prometheus 服务器被配置来提取来自其他服务的 Prometheus 服务器的指定的数据,以便在一个 Prometheus 服务器中对两个数据集启用告警和查询。
这两种联邦,其实有很大的问题,本质上Prometheus的单机能力依旧没有得到解决。
拆分
拆分永远是解决问题的一个好思路。尤其是当你的场景是,不需要一个全局的监控视图。
我们可以根据环境(test,uat, prod)或是业务类型(基础设施,中间件,业务),甚至是根据部门类型来拆分。
当然可以通过grafana配置不同的数据源,给使用方营造一种整体的假象。
但是这种方案,会带来很多问题:
- 随着你metrics量的增加,切分的维度会越来越细。
- 缺乏一个全局的视图,我们仍然无法跨不同集群查询服务,并且无法真正执行全局查询。
- 给统一报警增加了困难。
- 如果群集是动态的或变化的,则每次群集中部署Prometheus时,您通常都需要实现一种自动向Grafana添加数据源的方法。
长期存储
Prometheus社区也意识到了同样的问题,于是提供了远程读写两个接口,让大家可以使用一些社区的时序数据库方案,来扩展prometheus。
当前,有几个提供长期存储(LTS)的开源项目,而这些社区项目则领先于其他项目:Cortex,Thanos或M3。
当然这些项目实现的方式是不同的,均有不同的优势和劣势,需要大家根据自己单位实际的场景需求来选择。
诸如Thanos,最终的储存是S3等对象存储,整体架构比较复杂。
M3db社区活跃度不够,文档比较少,但是M3db相比其他几个,是典型的时序数据库。
Influxdb集群版本没有开源。
Victoria 数据是没有副本的。
我曾经在生产环境中,使用过Clickhouse作为长期存储。该解决方案存在的问题是,Clickhouse并发查询能力比较低,导致查询的时候慢。当然写入倒是没有什么大的问题。
采集端hash mod
尤其当Prometheus部署到kubernetes当中,并且我们使用了Prometheus的kubernetes sd 服务发现时,当我们集群变得非常大的时候,单台的Prometheus采集能力也成为一个瓶颈。此时,我们可以使用hash mod, 对采集任务进行分片。
总结
本文是利用Prometheus 打造企业分布式监控平台系列中的第一篇文章。主要讲了Prometheus的可扩展性上的一些解决方案。其实没有百分百完美的方案,大家需要根据自己metrics的数量来选择最合适自己的方案。
以上所述就是小编给大家介绍的《利用Prometheus 打造企业分布式监控平台(1)--扩展性》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!
猜你喜欢:- 漫谈分布式系统(十五):扩展性的最后障碍
- 漫谈分布式系统(七):扩展性?切就完了
- 写扩展性好的代码:函数
- 如何借助 Proxy 代理,提升架构扩展性
- AI公司的练级之道:如何更具扩展性?
- Sentinel 1.7.2 发布,完善开源生态及扩展性
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。