thanos Thanos：开源的大规模Prometheus集群解决方案

软件工程师Fabian Reinartz喜欢用GO语言造轮子，热衷于解决难题。他是普罗米修斯的捍卫者和库本内特斯仪器公司的联合创始人。过去，他是SoundCloud的在线工程师，领导CoreOS的监控团队。现在他在谷歌工作。

巴特克·普罗特卡是“不可能”的基础设施软件工程师。他对一些新兴技术和分布式系统很感兴趣。凭借他在英特尔底层开发部门的工作背景、他之前作为中型企业贡献者的经历以及他在SRE的全球经验，他专注于与微服务相关的改进工作。他最喜欢的三个是Golang，开源软件，排球。

也许从我们的旗舰产品SpatialOS中不难猜到，Bidental面临的需求是一个高度动态的云基础架构，具有全球规模，运行着几十个Kubernetes集群。为了让它们继续运行，我们成了普罗米修斯监控系统的早期用户。普罗米修斯可以实时跟踪数百万个监控指标，并提供了强大的查询语言，用户可以通过该语言从这些指标中提取有用的信息。

普罗米修斯简单可靠的运维模式是其主要卖点之一。但是，形成一定规模后，我们发现了一些不足。为了解决这些问题，今天我们正式发布了灭霸项目[1]，这是一个不可思议的开源项目，它可以无缝地将世界上现有的普罗米修斯部署转换成一个统一的监控系统，支持无限的历史数据存储。

我们发展灭霸的目的

在一定的集群规模下，当负载超过普通普罗米修斯集群的承载能力后，就会暴露出一些问题。如何才能经济可靠地存储PB级历史数据？我们能做到这一点而不牺牲查询响应时间吗？我们可以通过一个查询界面访问不同普罗米修斯服务器上的所有索引数据吗？此外，我们能否以某种方式合并通过普罗米修斯高可用性集群收集的复制数据？

作为这些问题的答案，我们创建了灭霸项目。在下一节中，我们将描述在开发灭霸之前我们是如何避免这些功能缺陷的，并详细介绍我们设想的一些目标。

全局查询视图

普罗米修斯主张按功能分裂。即使是一台普罗米修斯服务器也可以为几乎所有用例提供足够的可扩展性，将用户从水平扩展的复杂性中解放出来。

虽然这是一个很棒的部署模型，但是用户经常希望通过同一个API或UI，即全局视图来访问所有数据。例如，您可以在一个Grafana广告牌上呈现多个查询视图，但每个查询只能针对一个普罗米修斯服务器。另一方面，如果您使用灭霸，用户将能够从多个普罗米修斯服务器查询和聚合数据，因为所有这些数据都可以从一个端点获得。

在此之前，为了实现全局视图，我们将我们的普罗米修斯实例组织成一个多级分层联盟[2]。这意味着需要建立一个元普罗米修斯服务器来从每个“叶子”服务器收集一些数据。

这种方法最终证明是有问题的。导致配置负担越来越重，增加了额外的潜在故障点，需要在联盟节点上配置一些复杂的规则，只暴露部分数据。此外，这种联盟没有实现真正的全局视图，因为不是所有的数据都可以从一个查询接口获得。

与之密切相关的是由一对普罗米修斯高可用性服务器收集的数据提供的统一视图。普罗米修斯的高可用模型是分别收集两次数据，非常简单。然而，获得两个数据流的合并和重复数据消除视图是一个巨大的可用性改进。

毫无疑问，我们需要一个高度可用的普罗米修斯集群。在“不可能”，我们非常重视监控每分钟收集的数据。但是，在每个集群中部署一个普罗米修斯实例意味着存在单点故障的风险。任何配置错误或硬件故障都可能导致重要监控结果的丢失。即使是简单的释放也可能导致指示器收集的小中断，因为重启可能比一次收集的时间间隔长得多。

可靠的历史数据存储

我们的梦想之一(也是普罗米修斯用户的共同梦想)就是拥有一个廉价、及时的长期索引存储。在“不可能”，我们使用了普罗米修斯1.8，我们被迫将索引保留策略设置为尴尬的9天。这就增加了一个明显的操作限制，就是我们可以通过监控图回看多久以前。

普罗米修斯2.0在这方面提供了很多帮助，时间序列数据量不再影响整体服务器性能(请参考法比安在KubeCon [3]上关于普罗米修斯2的演讲)。然而，普罗米修斯仍然将指示器数据保存在其本地磁盘上。虽然高效的数据压缩可以在本地SSD磁盘上获得显著优势，但最终可以存储的历史数据量仍然有限。

此外，在“不可能”，我们注重可用性、简单性和成本。较大的本地磁盘更难操作和备份。它们更昂贵，需要更多的备份工具，带来了不必要的复杂性。

下采样(下采样)

一旦我们开始查询历史数据，我们很快就意识到，当我们搜索数周、数月甚至数年的数据时，这里的巨大复杂性会使查询越来越慢。

通常解决这个问题的方法叫做下采样，这是一个降低信号采样率的过程。我们可以“缩小”到更大的时间范围，同时保持相同数量的样本数据，从而确保查询响应的速度。

旧数据的下采样是任何长期存储解决方案的必然要求，超出了普通普罗米修斯集群的范围。

其他目标

灭霸项目的最初目标之一是无缝集成任何现有的普罗米修斯实例。第二个目标是运营尽量简单，准入门槛尽量低。如果有依赖的话，应该很容易满足大小用户的需求，也就是说基准成本可以忽略不计。

灭霸的建筑

在最后一部分，我们列出了一些预期目标。让我们看看这些列表，看看灭霸是如何解决这些问题的。

全局视图

为了获得现有普罗米修斯集群的全局视图，我们需要将中央查询层与所有服务器互连。灭霸西得卡[4]组件扮演着这样的角色，它将被部署到每一个运行的普罗米修斯服务器端。它充当代理服务器，并通过灭霸标准化的基于gRPC的商店应用编程接口提供普罗米修斯的本地数据。它还允许通过标签和时间段选择时间序列数据。

运行在另一端的是一个水平可伸缩的无状态的Querier组件，在回答PromQL查询时比标准的普罗米修斯HTTP API做的多一点。Querier、Sidecar和其他灭霸组件通过八卦协议进行通信。

当Querier收到一个请求时，它会向相关的Store API服务器(这里是我们的Sidecar)发送一个请求，并从他们的普罗米修斯服务器获取时间序列数据。

它聚合这些响应的数据，并对它们执行PromQL查询。它可以为普罗米修斯的高可用性组聚合不相交的数据或消除重复数据。

它通过将完全分离的普罗米修斯部署集成到我们数据的全局视图中，解决了我们问题的核心困难。事实上，灭霸可以这样部署，这些功能可以根据需要使用。根本不需要改变现有的普罗米修斯服务器！

保持无限数据！

但是，迟早我们会想要保留一些超过普罗米修斯常规保留时间的数据。为此，我们决定使用对象存储系统来备份我们的历史数据。它广泛应用于每一个云甚至大多数本地数据中心，性价比非常高。此外，几乎所有对象存储解决方案都可以通过著名的S3应用编程接口访问。

普罗米修斯的存储引擎大约每两个小时将最新的内存数据写入磁盘。持久数据块包含固定时间范围内的所有数据，并且是不可变的。这很有用，因为通过这种方式，灭霸西得卡可以简单地监听普罗米修斯的数据目录更改，然后在新数据块出现时将其上传到对象桶。

写入磁盘后通过Sidecar将索引数据块上传到对象存储的另一个优点是，它可以保持“刮板”(由普罗米修斯及其支持的灭霸Sidecar组成)足够轻。这简化了操作和维护、成本和系统设计。

备份我们的数据很容易。再从对象存储中查询数据怎么样？

灭霸存储组件充当对象存储中数据的数据检索代理。就像灭霸Sidecar一样，它会加入八卦集群，实现Store API。这样，现有的Querier就可以像Sidecar一样把它作为时间序列数据的另一个数据源——无需任何特殊处理。

时间序列的数据块由一些大文件组成。按需下载效率不高，需要巨大的内存和磁盘空才能本地缓存。

相反，Store Gateway知道如何处理普罗米修斯存储引擎的数据格式。通过智能查询规划和仅缓存必要索引部分的数据块，它可以将一些复杂的查询降级为对对象存储中最小数量文件的HTTP范围请求。这样，它可以将原始请求的数量减少4到6个数量级，而不影响响应时间。总的来说，很难区分这和在本地SSD上查询数据的区别。

如上图所示，灭霸·克雷耶利用普罗米修斯存储格式(可以在块文件中共存相关数据)的特点，显著降低了对象存储产品的单次请求成本。考虑到这一点，我们可以将多个字节的提取聚合成最少数量的批处理调用。

压缩和下采样(压缩和下采样)

从时间序列中的新数据块成功上传到对象存储的那一刻起，我们就可以将其视为存储网关上可用的“历史”数据。

但是，经过一段时间后，来自单个数据源(即运行Sidecar的普罗米修斯实例)的这些数据块会逐渐积累，但索引的全部潜力无法得到充分利用。为了解决这个问题，我们引入了一个名为Compactor的单一组件。它只是将普罗米修斯的本地压缩机制应用于对象存储中的历史数据，并可以作为一个简单的调度批处理任务来执行。

得益于普罗米修斯高效的样本压缩技术，从数据大小来看，长时间查询多个序列不是问题。然而，数十亿个样本数据的解压缩和这些样本的查询处理的潜在成本必然会导致查询延迟的急剧增加。另一方面，因为每个可用的屏幕像素上有数百个数据点，所以即使是全分辨率数据也无法渲染。这也使得下采样不仅可行，而且不会造成明显的精度损失。

为了生成下采样数据，压实机将连续聚合序列数据，分辨率为5分钟1小时。对于通过TSDB异或压缩编码的每个原始数据块，它将存储几种不同类型的聚合数据，例如，最小值、最大值或单个数据块的总值。这使得query er能够为给定的PromQL查询自动选择合适的聚合数据。

从用户的角度来看，不需要对采样后的数据进行任何特殊的配置来使用。当用户放大和缩小时，查询器会自动在不同分辨率和原始数据之间切换。或者，用户可以通过指定用户定义的“步骤”来直接控制查询参数。

由于每GB的存储成本非常低，默认情况下，灭霸将始终在存储中维护分辨率为五分钟一小时的原始数据，因此无需删除原始数据。

记录规则(记录规则)

即使在灭霸，日志记录规则仍然是监控堆栈的重要组成部分。它们降低了查询的复杂性、延迟和成本。它们还为用户提供了查看指标数据的重要汇总视图的便捷快捷方式。灭霸基于普通的普罗米修斯实例，所以在现有的普罗米修斯服务器中保留记录规则和警报规则是完全有效的。但是，对于以下情况，这可能还不够:

全局的告警和规则（例如：当三个集群中的两个以上的集群里的服务宕机时发出告警）超出单台Prometheus本地保留数据的规则希望将所有规则和告警存储在一个地方

为了解决这些问题，灭霸提供了一个名为统治者的独立组件，它将执行规则并基于灭霸·克雷耶发出警报。通过发布众所周知的存储API，查询节点可以访问新计算的索引数据。它们也备份到对象存储，并且可以通过存储网关进行访问。

灭霸的力量

灭霸非常灵活，可以根据用户的使用场景进行不同的设置。这在迁移普通普罗米修斯时特别有用。让我们通过一个简单的例子快速回顾一下我们从灭霸组件中学到的东西。以下示例说明了如何将您的普通普罗米修斯迁移到我们“无限保留指示器”的闪亮世界:

将Thanos Sidecar添加到你的Prometheus服务端 - 例如，在Kubernetes pod里运行一个相邻容器；部署一些Thanos Querier的副本以启用数据浏览功能。与此同时，用户可以轻松地在Scraper和Querier之间配置一个gossip集群。使用thanos_cluster_members指标来确认所有组件都已连接。

值得一提的是，仅这两个步骤就足以实现从潜在的普罗米修斯高可用性副本和无缝重复数据消除中获得的结果的全局视图！只需将仪表板连接到查询器HTTP端点，或者直接使用灭霸用户界面。

但是，如果您想实现指标数据的备份和长期保留，我们需要完成以下三个附加步骤:

创建一个AWS S3或GCS存储桶。你只需要简单地配置一下Sidecar即可完成数据的备份。如今你也可以将本地保留策略配至最低。部署一个Store Gateway然后将它加入到现有的gossip集群。做到这一点的话我们的查询便也可以访问到备份好的数据！部署Compactor，通过应用压缩和降准采样来提升长期数据查询的响应能力。

如果您想了解更多，请随时查看我们的库本内特示例列表[5]和条目页面[6]！

只需五个步骤，我们就可以将普罗米修斯实例组装成一个强大的监控系统，为用户提供全局视图、无限的数据保留和高可用性的潜在指标。