转载

Google和伙伴们把PROMETHEUS加入Kubernetes平台

作者：Timothy Prickett Morgan

在现代化的平台中有很多变化的组件，在这点上，它们相比于同前一代的平台而言没有什么不同。但是一个现代化的平台应用了很多自动化手段来在处理在集群不同组件上如同量子微粒一般出现的快速迸发而又转迅而逝的大量动态负载，它需要一些更高级的手段对协议栈及运行于其上的应用程序进行监控和管理。

对现有的诸如Nagios和Ganglia等开源监控工具的失望是行业巨无霸们为什么要自行开发工具（Google开发了Borgmon而Facebook开发了Claspin，这里仅列举这两个例子）或者对它们及其他工具进行大规模的扩展来应付监控问题的原因。你也许认为监控是很无聊的，但它对任何一个创建了微服务风格应用程序的IT组织而言都是命脉所在，因为这类应用程序将分布到数千裸机或虚拟化服务器实例上，亦或是成千上万的容器之中。如果你无法采集监测全部的细节，你就无法管理它进而也就无法向最终用户交付一致且可预期的性能。那么他们可能只需要一个简单的点击就转身离开而寻找其他备选方案了。

SoundCloud，一家位于德国柏林的音频流服务商，对他们的的StatsD和Graphite监控工具很不满意，于是在五年前开始寻找一个替代方案。对他们而言幸运的是，一位自2006年到2012年在Google工作的软件工程师Matt Proud从这家搜索引擎巨头离职后创建了Prometheus（普鲁米修斯）项目。Proud很失望地发现开源社区的管理工具不能以多维度的格式保存时序数据也没有如SQL这样易于使用的查询语言，于是他开始开发自己的监控工具－灵感来源于他对Google Borgmon和Borg集群管理器和作业调度器的理解。

“我从2006年到2012在Google供职，然后在2014年又再次加入Google” Proud告诉The Next Platform。“在Google的这段时间对我的技术眼界以及对数据的关注有着很深的影响。这成为我在离职后开创Prometheus项目的动机。作为一个软件工程师没有这样的工具是不可能做到面向数据的。“

Proud在SoundCloud只工作了一小段时间（在2013年底离职时他是技术基础架构团队的主管）但还有其他的SoundCloud员工对Prometheus投入了很多的精力，尤其是Julius Volz，他成为该项目的联合创始人。在2012年，Prometheus项目遵照Apache 2.0 license在GitHub上发布，一年后在被部署到SoundCloud的生产环境中。去年一月，Prometheus项目的成员对于他们想做什么有很大的争议，但是最终认定Prometheus是一个可供现代平台选择的新兴监控工具。

本周新闻报道称Prometheus正式成为Cloud Native Computing Foundation的孵化项目，该基金会是在Google的支持下由一群IT行业巨头创建并指导Kubernetes容器管理系统的开发。在CNCF的主导下，Prometheus成为该开放平台栈的第二个正式的组件，但是需要认识到Prometheus也将成为众多不局限于特定平台的组件之一。

“关键是要认识到CNCF并不仅仅局限于Kubernetes”，作为该组织的技术审查委员会主席兼Weaveworks创始人及CEO的Alexis Richardson说到。“Prometheus就是一个很好的例子，因为它是在Kubernetes出现之前就开发了，而且开发它的原因是世界上有很多种不同类新的应用程序需要监控。因此，Prometheus不仅能监控Kubernetes应用程序，也能够监控Mesos、Docker、OpenStack等等平台的应用程序。除此之外还有很多的东西，我个人认为目前将会超过这三个主要的平台。因此它是一个非常普通但是功能强大的工具。我们希望选择一个在多种使用场景下都很好用的工具而非只针对一个场景。它不必局限于容器，它也可以用于虚拟机。“

和很多Google的工具一样，Prometheus是用Go开发的，而且自从在2015年一月推出后该项目的受关注度就迅猛增长。Prometheus项目在GitHub上有33个repository而且截止今年一月份该项目拥有超过200个贡献者并且解决了1100个软件问题中的800多个。，项目的创始人希望通过与CNCF步调一致推进Prometheus的使用、它使用与Kubernetes类似的治理模型、在必要时提供法律援助并通过组织活动的方式让社区团结在一起。

Richardson对高级架构和监控需求并不陌生。时光倒回到1990年代晚期，他在Goldman Sachs承担固定收益衍生品交易台的量化工作，并于2002年创立了一个Java应用程序服务器的生成器－ Metalogic（它现在还有人使用），之后在2006年加入了一个早起的平台云服务提供商fo8und Cohesive Networking,之后于2009年加入Rabbit Technologies。该公司是消息队列平台RabbitMQ的制造商并被Pivotal收购。在VMware和Pivotal呆了几年后，Richardson于2014年创立了Weaveworks，一个Docker容器监控和管理平台。

“我认为监控是非常重要的“ Richardson说。”它并不是仅仅常规意义上的监控，而是你怎么做到，形成因素是什么，惯用语法是什么。现在已经有很多的产品，其中多数都是开源软件，而且其中有些还非常不错。在年度调查中，Nagios依旧名列前茅。但是你知道吗？它非常难用。“

如Richardson所说，Prometheus所使用的监控模型主要基于两点主要的考虑。第一，从根本上讲它是一个监控工具并且专注于此，第二，它有一个内置的时序数据库和查询系统。这使得人们能够以一种开发人员使用使用且自然的方式针对监控数据设计问题，而且它拥有的数据也远超过系统管理员所习以为常的由事件驱动所产生的数据流。它是不断发展的市场的一员，该市场包括所有从一开始就内置了分析功能的软件工具。Richardson说Peometheus的架构是非常灵活的，因此它在设计中允许基于Cassandra、Riak或者云计算服务中的Google BigTable或Amazon Web Services 的DynomoDB来扩展至更大的数据存储。这里的想法于其他大数据命题是一样的：你保存所有数据为乐解答所有未来所有的复杂问题，这么做不是为了拉动营收而为为乐分析根本原因并对系统和应用程序性能进行预测性分析。这些延展性的工作还没有完成，但是已经完成了基础工作。

“我想这表明Prometheus不仅是一个好工具，而且也引领了一个正确的方向” 他补充道。“它比大量的其他现有监控工具要复杂一点儿。”

（他所拥有的公司Weaveworks为Prometheus做了贡献也从中获益，它所销售的一个服务在后端使用了Kubernetes和Prometheus。）

在年初，Volz称Prometheus将会放弃自己名为PromDash的图形界面和仪表盘而将流行的Grafana工具作为其前端，这将有助于降低开发工作量。

Volz说Google显然乐衷于将Prometheus和Kubernetes集成在一起，并且在内部将Prometheus应用在一些生产系统中。CoreOS拥有一个称谓Tectonic的商业化Kubernetes栈，它在分布式配置管理系统etcd中结成了Prometheus，而Docker也实现了与其容器管理工具的集成。DigitalOcean、Boxever、KPMG、Outbrain、Ericsson、ShowMax和时代财经也宣布使用了Prometheus。

但是不要就此认为Prometheus将很快打垮Nagios和其他工具。

“关于监控工具而言最要紧的事是现在到底有多少种这类工具”，Richardson笑着说。“我想最根本的原因在于监控都是以特定的方式观察世界来进行调整。如果你走进典型的企业并问他们在使用多少不同的监控工具，答案将是30、40或50，这就是其他进行数据汇聚的产品存在的原因。每过几年，真对新的架构就会出现新一代的工具。但是我不认为老的工具就会被淘汰，因为他们的出现是有原因的而且他们依然能解决那些问题。”

Prometheus的创造者希望解决的一个问题是能够拥有一个可扩展的监控工具而不需要自己拥有并维护一个复杂的集群。例如，你可以共享Prometheus服务并将其分散到一个Hadoop集群中，但是这也会导致其自身的管理难题。相反，Proud和Volz希望一个系统能够每秒钟从集群中抽取至少800000个样本并且在一台主机上保存数百万按时间排序的数据序列。

如果你希望在生产环境中使用Prometheus，项目核心提交者之一的Brian Brazil创办了名为Robust Perception的公司为Prometheus提供商业级支持。他曾是Google的网站可靠性工程师（site reliability Engineer），为搜索引擎巨头的核心AdSense和AdWords广告系统工作了7年。核心提交者Volz和Björn Rabenstein在加入SoundCloud之前也是Google的SRE，因此当他们说Prometheus的灵感来源于Borgmon是，他们是真正地使用过Google的工具而非根据一些研究论文才想到的。

顺便说一下，Prometheus软件还没有进化到1.0发布版本，但是在今年将会连同Richardson所提到的外部读写存储一起发布。

译者：李毅中国惠普大学培训专家

原文链接：

原文 http://dockone.io/article/1345

正文到此结束