🥩 👨🏾‍🤝‍👨🏽 🍲 Thanos-可扩展的普罗米修斯 🌵 🙈 💲

本文的翻译是专门为“ DevOps实践和工具”课程的学生准备的。

(Fabian Reinartz) — , Go . Prometheus Kubernetes SIG instrumentation. production- SoundCloud CoreOS. Google.

(Bartek Plotka) — Improbable. . Intel, Mesos production- SRE Improbable. . : Golang, open source .

查看我们的旗舰SpatialOS产品，您可能会猜到Improbable需要具有数十个Kubernetes集群的高度动态的全球云基础架构。我们是最早使用Prometheus监控系统的公司之一。 Prometheus能够实时跟踪数百万个指标，并具有强大的查询语言来检索必要的信息。

简单性和可靠性Prometheus是其主要优势之一。但是，经过一定规模后，我们遇到了一些弊端。为了解决这些问题，我们开发了Thanos-Improbable创建的开源项目，用于将现有的Prometheus集群无缝转换为具有无限历史数据存储库的单个监视系统。Thanos可以在github上找到。

随时了解Improbable的最新消息。

我们与Thanos的目标

在某种程度上，出现的问题超出了香草普罗米修斯的能力。如何可靠，经济地存储PB级历史数据？可以在不影响请求响应时间的情况下完成此操作吗？是否可以通过单个API请求访问位于不同Prometheus服务器上的所有指标？是否可以以某种方式合并使用Prometheus HA收集的复制数据？

为了解决这些问题，我们创建了Thanos。以下各节描述了我们如何解决这些问题并解释了我们追求的目标。

从Prometheus的多个实例中查询数据（全局查询）

Prometheus提供了一种实用的分片方法。甚至一台Prometheus服务器都提供了足够的可伸缩性，使用户在几乎所有用例中都摆脱了水平分片的麻烦。

尽管这是一个出色的部署模型，但通常需要通过单个API或UI（全局视图）访问不同Prometheus服务器上的数据。当然，可以在一个Grafana面板中显示多个请求，但是每个请求只能在一个Prometheus服务器上执行。另一方面，使用Thanos，您可以查询和聚合来自多个Prometheus服务器的数据，因为它们都可以从一个端点进行访问。

以前，为了全面了解“不可能”，我们将Prometheus实例分为多个级别等级联盟。这意味着创建一个Prometheus元服务器，该元服务器从每个叶服务器中收集部分指标，

这被证明是有问题的，使配置复杂化，增加了潜在的故障点，并应用了复杂的规则以仅向联合端点提供正确的数据。此外，这种联合身份验证不允许您获得真实的全局视图，因为并非所有数据都可以从一个API请求中访问。

与之密切相关的是在Prometheus高可用性（HA）服务器上收集的数据的单一表示。 Prometheus HA模型独立收集两次数据，这是如此简单，以至于再简单不过了。但是，使用两个线程的组合和去重复的表示将更加方便。

当然，需要高可用性的Prometheus服务器。在Improbable，我们真的很认真地每分钟监视数据，但是每个群集只有一个Prometheus实例是单点故障。任何配置错误或硬件故障都可能导致重要数据丢失。甚至简单的部署也可能导致指标收集中的小故障，因为重新启动的时间可能明显长于抓取间隔。

可靠地存储历史数据

廉价，快速和长期的指标存储是我们的梦想（大多数Prometheus用户共有）。在Improbable中，我们被迫将指标的存储期限设置为9天（对于Prometheus 1.8）。这明显限制了我们可以回顾的范围。

在这方面，Prometheus 2.0更好，因为时间序列的数量不再影响整体服务器性能（请参阅有关Prometheus 2的KubeCon主题演讲）。但是，Prometheus将数据存储在本地驱动器上。尽管高效的数据压缩可以显着减少本地SSD的使用，但是保存的历史数据量仍然存在限制。

在Improbable，我们还关心可靠性，简单性和成本。大型本地驱动器更难操作和备份。它们更昂贵并且需要更多的备份工具，这导致不必要的复杂性。

下采样

一开始使用历史数据，我们就意识到O-big存在一些基本困难，如果我们使用数周，数月和数年的数据，查询就会变得越来越慢。

解决此问题的标准方法是下采样 -信号下采样。通过下采样，我们可以“缩小”到更大的时间范围，并保持相同数量的样本，这使我们可以保持请求的响应速度。

对旧数据进行下采样是任何长期存储解决方案的必然要求，并且超出了原始Prometheus的范围。

额外目标

Thanos项目的最初目标之一是与任何现有Prometheus安装进行无缝集成。第二个目标是操作简单，进入障碍最小。无论大小用户，都应轻松满足任何依赖性，这也意味着较低的基本成本。

萨诺斯建筑

在上一节中列出了我们的目标之后，让我们进行研究，看看Thanos如何解决这些问题。

全球视野

为了在Prometheus的现有实例之上获得全局视图，我们需要将单个请求入口点与所有服务器相关联。这正是Thanos Sidecar组件所做的。它部署在每个Prometheus服务器旁边，并充当代理，通过商店的gRPC界面提供本地Prometheus数据，使您可以通过标签和时间范围选择时间序列数据。

另一方面，有一个无状态的水平可伸缩Querier组件，它所做的不仅仅是通过标准的Prometheus HTTP API响应PromQL请求。组件Querier，Sidecar和其他Thanos通过八卦协议进行通信。

查询者收到请求后，将连接到相应的Store API服务器，即我们的Sidecar，并从相应的Prometheus服务器接收时间序列数据。
之后，它将答案合并并对其执行PromQL查询。Querier可以将Prometheus HA服务器中的不连续数据和重复数据进行合并。

这解决了我们的大部分难题-将来自隔离的Prometheus服务器的数据合并到一个视图中。实际上，Thanos仅可用于此机会。现有的Prometheus服务器不需要进行任何更改！

无限的保质期！

但是，迟早我们将要保存超出Prometheus正常存储时间的数据。为了存储历史数据，我们选择了对象存储。它可以在任何云以及本地数据中心中广泛使用，并且非常经济。此外，几乎所有对象存储都可以通过众所周知的S3 API访问。

Prometheus大约每两个小时将数据从RAM写入磁盘一次。存储的数据块包含固定时间段内的所有数据，并且是不可变的。这非常方便，因为Thanos Sidecar可以简单地查看Prometheus数据目录，并在出现新块时将其加载到对象存储桶中。

写入磁盘后立即下载到对象存储也可以使“刮板”（Prometheus和Thanos Sidecar）的简单性保持简单。这简化了支持，成本和系统设计。

如您所见，备份数据非常简单。但是查询对象存储中的数据呢？

Thanos Store组件充当从对象存储中检索数据的代理。与Thanos Sidecar一样，它也参与了八卦集群并实现了Store API。因此，现有Querier可以将其视为Sidecar，作为时间序列数据的另一个来源-无需特殊配置。

时间序列数据块由几个大文件组成。按需下载它们的效率很低，并且本地缓存需要巨大的内存和磁盘空间。

相反，Store Gateway知道如何处理Prometheus存储格式。得益于巧妙的查询计划器和仅对块的必要索引部分进行缓存，将复杂的查询减少到对对象存储文件的HTTP请求的最小数量成为可能。因此，可以将请求数量减少四到六个数量级，并获得通常难以与本地SSD上的数据请求区分开的响应时间。

如上图所示，Thanos Querier通过使用Prometheus存储格式并将相关数据并排放置，大大降低了对象存储中单个数据请求的成本。使用这种方法，我们可以将许多单个查询合并为最少数量的批量操作。

压缩和下采样

在将新的时间序列数据块成功加载到对象存储中之后，我们将其视为“历史”数据，这些数据可立即通过Store Gateway获得。

但是，过一会儿，来自一个源（带有Sidecar的Prometheus）的块会累积，不再使用全部索引潜力。为了解决这个问题，我们引入了另一个称为Compactor的组件。它仅将本地Prometheus压缩机制应用于对象存储中的历史数据，并且可以作为简单的定期批处理作业运行。

由于有效的压缩，长时间存储库中的查询不会在数据大小方面带来问题。但是，解包十亿个值并通过查询处理器运行它们的潜在成本将不可避免地导致查询执行时间的急剧增加。另一方面，由于屏幕的每个像素有数百个数据点，因此甚至无法以全分辨率可视化数据。因此，下采样不仅可能，而且不会导致明显的精度损失。

对于下采样数据，Compactor持续以五分钟一小时的分辨率聚合数据。对于使用TSDB XOR压缩编码的每个原始片段，将存储各种类型的聚合数据，例如一个块的最小值，最大值或总和。这使Querier可以自动选择适合此PromQL查询的聚合。

要使用精度降低的数据，用户不需要任何特殊配置。当用户放大和缩小时，查询器会自动在不同的分辨率和原始数据之间切换。如果需要，用户可以通过请求中的“ step”参数直接控制它。

由于存储1 GB的成本很小，因此默认情况下，Thanos将保存原始数据，即分辨率为五分钟零一小时的数据。无需删除原始数据。

记录规则

即使使用Thanos，记录规则也是监视堆栈的重要组成部分。它们减少了请求的复杂性，延迟和成本。它们也方便用户获得汇总的度量标准数据。Thanos基于Prometheus的原始实例，因此完全可以在现有Prometheus服务器上存储记录规则和警报规则。但是，在某些情况下，这可能还不够：

全局警报和规则（例如，当三个群集中的两个以上的服务中断时发出警报）。
本地存储之外的数据规则。
希望将所有规则和警报保持在一处。

对于所有这些情况，Thanos包含一个称为Ruler的单独组件，该组件通过Thanos查询来计算规则和警报。通过提供众所周知的StoreAPI，查询节点可以访问最新计算的指标。以后，它们也存储在对象存储中，并可以通过Store Gateway使用。

塔诺斯的力量

Thanos足够灵活，可以根据您的要求进行定制。从简单的Prometheus迁移时，这特别有用。让我们快速了解一下我们对Thanos组件的了解。这是将原始Prometheus转移到“无限量度存储”世界的方法：

将Thanos Sidecar添加到Prometheus服务器-例如，Kubernetes窗格中的相邻容器。
展开多个Thanos Querier副本以查看数据。此时，在Scraper和Querier之间建立八卦很容易。使用度量“ thanos_cluster_members”来测试组件交互。

仅这两个步骤就足以提供全局视图和来自潜在Prometheus HA复制副本的无缝重复数据删除功能！只需将仪表板连接到Querier HTTP端点或直接使用Thanos UI界面。

但是，如果需要备份指标和长期存储，则将需要执行另外三个步骤：

构建一个AWS S3或GCS存储桶。将Sidecar配置为将数据复制到这些存储桶。现在，您可以最小化本地数据存储。
展开Store Gateway并将其连接到现有的八卦群集。现在，您可以发送备份中的数据请求！
部署Compactor，以使用压缩和下采样来长时间提高查询性能。

如果您想了解更多信息，请随时查看我们的清单kubernetes实例并开始使用！

仅五步，我们就将Prometheus变成了具有全局视图，无限的存储时间和潜在的高可用性指标的可靠监视系统。

拉取要求：我们需要您！

Thanos从一开始就是一个开源项目。与Prometheus的无缝集成以及仅使用Thanos的一部分的能力，使其成为扩展监控系统而无需任何额外努力的绝佳选择。

我们始终欢迎GitHub Pull Request和Issues。同时，如果您有任何疑问或反馈，或者想分享您的经验，请随时通过Github Issues或宽松的Improbable-eng #thanos与我们联系。如果您喜欢我们在Improbable所做的工作，请随时与我们联系- 我们总是有空缺！

了解有关该课程的更多信息。

Thanos-可扩展的普罗米修斯