容器监控的基石Prometheus 2.0到来

1,181 阅读6分钟
原文链接: dockone.io
【编者的话】本文为大家带来了Prometheus 2.0中新存储层需求的由来,主要的挑战,实现的简要介绍,以及相关的基准测试结果,相关领域人员可以参考一下。

Kubernetes使得复杂环境的管理变得容易,但是为了确保可用性,对Kubernetes组件以及群集上运行的所有应用程序进行操作深入分析至关重要。在CoreOS,我们相信监控是良好生产环境的基石,这也是我们投入开发Prometheus监控系统的原因。作为一个由Cloud Native Computing Foundation(CNCF)支持的项目,Prometheus迅速获得了基础设施及应用监控方面的热度,今天是它更进一步的时候。
01.png
CoreOS将Prometheus作为我们企业级Kubernetes平台Tectonic的集成组件,并且我们也一直在努力提升其对Kubernetes用户的价值。今年早些时候,我们分享了关于下一代Prometheus(version 2.0)的新存储层方面的工作。为了稳固这项工作,我们和Prometheus团队以及我们的用户进行了更加密切的合作。在3个alpha版本,6个beta版本以及3个RC版本之后,今天Prometheus 2.0正式宣布稳定版本。感谢Brian Brazil和Goutham Veeramachaneni,他们在这项工作中付出巨大。在我们探索该发行版的优点之前,让我们回过头来,先探讨一下我们为何需要一个新的存储层。

时间序列和动态环境

Prometheus关于监控的理念鼓励在堆栈的每一层都采用高度详细的度量工具。容器的状态,通过的请求流,甚至是运行于其中的应用的深层信息都通过度量工具对外可见。Prometheus带来了一款强力的查询语言帮助将度量数据汇总转换成行动方案。

Prometheus通过时间序列的方式收集和存储数据,它是通过固定间隔收集到的带有时间戳数据的序列。这种设计可以使运行中的容器轻松产生成千的时间序列。随着容器的规模从成百扩展到成千,在集群中很可能产生数百万被跟踪的时间序列。

为上百万的时间序列持续写入数据显然是一项技术难题。更糟糕的是,Kubernetes使得持续销毁和创建容器变得十分容易。该项模型对于持续部署,自动扩容以及批处理作业调度而言是极为强大的,因此只会随着时间的推移而变得越来越普遍。

每个容器都有一个独一无二的标识符,所有其时间序列均包含该标识符,以达到最佳的视角。因此当被跟踪的活跃时间序列总数大致固定时,Prometheus中可以对外访问的所有历史时间序列数据是持续增长的。允许查询十亿级的时间序列是一项全新的挑战,但我们决定让Prometheus很好地支持该特性。

新的存储引擎就是用来解决这项挑战的。受到全文搜索的启发,它使用倒排索引以提供对于Prometheus时间序列可能拥有的任意纬度进行快速检索。新的磁盘格式确保相关的时间序列数据良好分布,另外write-ahead日志也使得Prometheus 2.0n能够从崩溃中恢复。

Prometheus同样变得更易操作了。Prometheus 1.x的用户应该对调整期望负载的存储配置十分熟悉。然而,有了新的存储层之后,这些控制就不再需要了。

基准测

这项工作的真实结果是令人印象深刻的。Prometheus 2.0的资源消耗得到了显著降低,使用率更加稳定,并且新的索引方式带来了更低且一致的查询延迟。

下方的图是一个基准测试集的结果,它来自一个运行着成百个应用Pod并被监控的Kubernetes集群。Pod按照高频率替换以产生时间序列的扰动。各有2个Prometheus 1.5和Prometheus 2.0实例运行采集新数据。不同版本中,各有1个实例对外服务,以产生适中性的高查询负载。

从前2个图中,我们可以看到Prometheus 2.0的内存和CPU消耗均明显更低,并且自启动后,它们很快到达稳定状态。Prometheus 1.5则需要更多的资源,并且其资源使用率难以预测。
02.png
03.png
Prometheus 2.0中最大的改进是其每秒写入磁盘的数据量,可以查看下图。新版本的写入量较之前低了近2个数量级。很明显,这能增加SSD的寿命(译者:SSD寿命由PE次数决定,与写入数据量密切相关),进而降低成本。在高序列扰动的情况下,即使使用相同的序列压缩算法,依旧可以观察到显著的磁盘空间节省。
04.png
在Prometheus 1.5中,随着更多的时间序列被创建,查询的延迟是线性增长的。Prometheus 2.0则从一开始就维持了稳定的性能,它使得查询的反馈更加敏捷,正如下图所示。
05.png

其余新特性

Prometheus 2.0的大多数工作都聚焦于提升性能并使其更加易于操作。但是新的存储层同样被设计以更好地和Prometheus的外部交互,这使得围绕收集到的时间序列数据进行广泛的定制处理成为可能。

快照备份是一项被频繁要求的特性。当使用flag --web.enable-admin-api时,只需要通过简单的API调用,Prometheus 2.0便可原生支持它们。
bash
$ curl -XPOST http://<prometheus>/api/v2/admin/tsdb/snapshot
{"name":"2017-10-18T13:44:35Z-3f6a679bb001e65d"} 

快照存放于名为返回值的目录中,且可以被上传到归档存储中,它们几乎不会占用额外的磁盘空间。最棒的是,新的Prometheus服务器可以从备份的数据启动,你只需将数据移动到新的服务器数据目录中即可。

关于完整的变更列表以及如何从Prometheus 1.x迁移,请查看官方声明以及迁移指南

敬请尝试

有关Prometheus 2.0增强的最佳部分是,Prometheus当前不但可以比以往更好地支持Kubernetes的工作负载,更在于当Kubernetes在基础设施中活力倍增时,它预留了足够的空间来支撑届时的工作负载。

想要了解Prometheus,请关注11月16日上午8时webinar上关于新特性的PT(来自Prometheus开发者Frederic Branczyk)。

如果你想要亲自了解集成Prometheus支持是如何使得CoreOS Tectonic成为真正的企业级Kubernetes平台的,你可以免费部署一个不多于10个节点的Tectonic集群。你将能够使用最新的Prometheus操作器不费吹灰之力地在集群中部署Prometheus 2.0,而无需额外的配置。

声明:本文中的基准测试通过prombench生成。为了复现它们,你需要一个配置好的AWS账户,并且你必须指定想要执行的基准测试spec。spec.example.yaml正是生成本文所用图的spec。

相关文章


原文链接:Prometheus, the backbone of container monitoring, hits 2.0(翻译:孙科)