容器监控的基石Prometheus 2.0到来

Kubernetes使得复杂环境的管理变得容易，但是为了确保可用性，对Kubernetes组件以及群集上运行的所有应用程序进行操作深入分析至关重要。在CoreOS，我们相信监控是良好生产环境的基石，这也是我们投入开发Prometheus监控系统（https://prometheus.io/）的原因。作为一个由Cloud Native Computing Foundation（CNCF）支持的项目，Prometheus迅速获得了基础设施及应用监控方面的热度，今天是它更进一步的时候。

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则需要更多的资源，并且其资源使用率难以预测。

Prometheus 2.0中最大的改进是其每秒写入磁盘的数据量，可以查看下图。新版本的写入量较之前低了近2个数量级。很明显，这能增加SSD的寿命（译者：SSD寿命由PE次数决定，与写入数据量密切相关），进而降低成本。在高序列扰动的情况下，即使使用相同的序列压缩算法，依旧可以观察到显著的磁盘空间节省。

在Prometheus 1.5中，随着更多的时间序列被创建，查询的延迟是线性增长的。Prometheus 2.0则从一开始就维持了稳定的性能，它使得查询的反馈更加敏捷，正如下图所示。

其余新特性

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迁移，请查看官方声明（https://prometheus.io/blog/2017/11/08/announcing-prometheus-2-0/）以及迁移指南（https://prometheus.io/docs/prometheus/2.0/migration/）。

敬请尝试

有关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（https://github.com/prometheus/prombench）生成。为了复现它们，你需要一个配置好的AWS账户，并且你必须指定想要执行的基准测试spec。spec.example.yaml正是生成本文所用图的spec。

原文来自:Docker

声明：所有来源为“聚合数据”的内容信息，未经本网许可，不得转载！如对内容有异议或投诉，请与我们联系。邮箱：marketing@think-land.com