内容简介: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 发布,完善开源生态及扩展性
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
Programming Amazon Web Services
James Murty / O'Reilly Media / 2008-3-25 / USD 49.99
Building on the success of its storefront and fulfillment services, Amazon now allows businesses to "rent" computing power, data storage and bandwidth on its vast network platform. This book demonstra......一起来看看 《Programming Amazon Web Services》 这本书的介绍吧!