文章的翻译是专门为课程的学生准备的 .
是一名软件开发人员、Go 狂热者和问题解决者。 他也是 Prometheus 维护者和 Kubernetes SIG 工具的联合创始人。 过去，他是 SoundCloud 的生产工程师，并领导 CoreOS 的监控团队。 目前在谷歌工作。
- Improbable 的基础设施工程师。 他对分布式系统的新技术和问题感兴趣。 他拥有 Intel 的底层编程经验、Mesos 的贡献者经验以及 Improbable 的世界级 SRE 生产经验。 致力于改善微服务世界。 他的三大爱好：Golang、开源和排球。
看看我们的旗舰产品 SpatialOS，您可以猜测 Improbable 需要一个高度动态、全球规模的云基础设施，其中包含数十个 Kubernetes 集群。 我们是最早使用监控系统的公司之一 。 Prometheus 能够实时跟踪数百万个指标，并附带强大的查询语言，可让您提取所需的信息。
Prometheus 的简单性和可靠性是其主要优点之一。 然而，一旦超过一定规模，我们就会遇到一些缺点。 为了解决这些问题我们开发了 是由 Improbable 创建的一个开源项目，旨在将现有的 Prometheus 集群无缝转换为具有无限历史数据存储的单一监控系统。 Thanos 已在 Github 上提供 .
我们与灭霸的目标
在一定规模上，出现的问题超出了普通普罗米修斯的能力。 如何可靠且经济地存储 PB 级历史数据？ 这可以在不影响响应时间的情况下完成吗？ 是否可以通过单个 API 请求访问位于不同 Prometheus 服务器上的所有指标？ 有什么方法可以合并使用 Prometheus HA 收集的复制数据吗？
为了解决这些问题，我们创建了灭霸。 以下部分描述了我们如何解决这些问题并解释我们的目标。
查询多个Prometheus实例的数据（全局查询）
Prometheus 提供了一种功能性的分片方法。 即使单个 Prometheus 服务器也能提供足够的可扩展性，使用户在几乎所有用例中摆脱水平分片的复杂性。
虽然这是一个很好的部署模型，但通常需要通过单个 API 或 UI（全局视图）访问不同 Prometheus 服务器上的数据。 当然，可以在一个 Grafana 面板中显示多个查询，但每个查询只能在一台 Prometheus 服务器上执行。 另一方面，使用 Thanos，您可以查询和聚合来自多个 Prometheus 服务器的数据，因为它们都可以从单个端点访问。
之前，为了获得 Improbable 的全局视图，我们将 Prometheus 实例组织成多级 。 这意味着创建一个 Prometheus 元服务器，从每个叶服务器收集一些指标。
事实证明这种方法是有问题的。 这导致了更复杂的配置、增加了额外的潜在故障点以及应用复杂的规则来确保联合端点仅接收其需要的数据。 此外，这种联合不允许您获得真正的全局视图，因为并非所有数据都可以通过单个 API 请求获得。
与此密切相关的是高可用性（HA）Prometheus 服务器上收集的数据的统一视图。 Prometheus的HA模型独立采集两次数据，简单得不能再简单了。 然而，使用两个流的组合和重复数据删除视图会方便得多。
当然，需要高可用的 Prometheus 服务器。 在 Improbable，我们非常重视每分钟的数据监控，但每个集群只有一个 Prometheus 实例会导致单点故障。 任何配置错误或硬件故障都可能导致重要数据丢失。 即使是简单的部署也可能会导致指标收集出现轻微中断，因为重新启动的时间可能明显长于抓取间隔。
历史数据的可靠存储
廉价、快速、长期的指标存储是我们的梦想（大多数 Prometheus 用户都有这个梦想）。 在 Improbable 中，我们被迫将指标保留期配置为 1.8 天（对于 Prometheus XNUMX）。 这明显限制了我们的回顾能力。
Prometheus 2.0 在这方面有所改进，因为时间序列的数量不再影响服务器的整体性能（参见。 ）。 然而，Prometheus 将数据存储在本地磁盘上。 虽然高效的数据压缩可以显着减少本地SSD的使用，但最终可以存储的历史数据量仍然是有限的。
此外，在 Improbable，我们关心可靠性、简单性和成本。 大的本地磁盘操作和备份都比较困难。 它们成本更高，需要更多备份工具，从而导致不必要的复杂性。
下采样
一旦我们开始处理历史数据，我们就意识到 Big-O 存在根本性的困难，当我们处理数周、数月和数年的数据时，这些问题会让查询变得越来越慢。
这个问题的标准解决方案是 （下采样）- 降低信号采样频率。 通过下采样，我们可以“缩小”到更大的时间范围并保持相同数量的样本，从而保持查询响应。
对旧数据进行下采样是任何长期存储解决方案的必然要求，并且超出了普通 Prometheus 的范围。
额外目标
Thanos 项目的最初目标之一是与任何现有的 Prometheus 安装无缝集成。 第二个目标是易于操作、最小化进入壁垒。 对于小型和大型用户来说，任何依赖性都应该很容易满足，这也意味着基础成本较低。
灭霸架构
在上一节中列出我们的目标后，让我们逐一研究它们，看看 Thanos 如何解决这些问题。
全球视野
为了获得现有 Prometheus 实例之上的全局视图，我们需要将单个请求入口点链接到所有服务器。 这正是 Thanos 组件的作用。 。 它部署在每个 Prometheus 服务器旁边，充当代理，通过 gRPC Store API 提供本地 Prometheus 数据，允许按标签和时间范围检索时间序列数据。
另一方面是横向扩展、无状态 Querier 组件，它的作用只不过是通过标准 Prometheus HTTP API 回答 PromQL 查询。 Quierer、Sidecar 和其他 Thanos 组件通过以下方式进行通信 .
- Querier收到请求后，连接到相应的Store API服务器，即我们的Sidecar，并从相应的Prometheus服务器接收时间序列数据。
- 之后，它组合响应并对它们执行 PromQL 查询。 查询器可以合并来自 Prometheus HA 服务器的不相交数据和重复数据。
这解决了我们的一个主要难题 - 将来自孤立的 Prometheus 服务器的数据组合到一个视图中。 事实上，Thanos只能用于这个功能。 无需对现有 Prometheus 服务器进行任何更改！
保质期无限！
然而，迟早我们会想要存储超过正常 Prometheus 保留时间的数据。 我们选择对象存储来存储历史数据。 它可广泛用于任何云以及本地数据中心，并且非常具有成本效益。 此外，几乎所有对象存储都可以通过众所周知的 S3 API 获得。
Prometheus 大约每两个小时将数据从 RAM 写入磁盘。 存储的数据块包含固定时间内的所有数据并且是不可变的。 这非常方便，因为 Thanos Sidecar 可以简单地查看 Prometheus 数据目录，并在新块可用时将它们加载到对象存储桶中。
写入磁盘后立即加载到对象存储中还可以让您保持抓取器（Prometheus 和 Thanos Sidecar）的简单性。 这简化了支持、成本和系统设计。
如您所见，数据备份非常简单。 但是查询对象存储中的数据呢？
Thanos Store 组件充当从对象存储中检索数据的代理。 与 Thanos Sidecar 一样，它参与 gossip 集群并实现 Store API。 这样，现有的查询器就可以将其视为 Sidecar，作为时间序列数据的另一个来源 - 无需特殊配置。
时间序列数据块由多个大文件组成。 按需加载它们的效率非常低，并且在本地缓存它们将需要大量的内存和磁盘空间。
相反，Store Gateway 知道如何处理 Prometheus 存储格式。 得益于智能查询调度程序并仅缓存块的必要索引部分，可以将复杂查询减少到对对象存储文件的 HTTP 请求的最小数量。 通过这种方式，您可以将请求数量减少四到六个数量级，并实现通常难以与本地 SSD 上的数据请求区分的响应时间。
如上图所示，Thanos Querier 通过利用 Prometheus 存储格式并将相关数据并排放置，显着降低了对象存储数据的每次查询成本。 使用这种方法，我们可以将许多单个请求组合成最少数量的批量操作。
压缩和下采样
一旦新的时间序列数据块成功加载到对象存储中，我们就将其视为“历史”数据，可以通过 Store Gateway 立即使用。
然而，一段时间后，来自一个来源（带有 Sidecar 的 Prometheus）的块会累积，并且不再使用完整的索引潜力。 为了解决这个问题，我们引入了另一个组件，称为Compactor。 它只是将 Prometheus 的本地压缩引擎应用于对象存储中的历史数据，并且可以作为简单的定期批处理作业运行。
由于有效的压缩，长时间查询存储不会造成数据大小的问题。 然而，解压十亿个值并通过查询处理器运行它们的潜在成本将不可避免地导致查询执行时间的急剧增加。 另一方面，由于屏幕上每个像素有数百个数据点，因此甚至不可能以全分辨率可视化数据。 因此，下采样不仅是可能的，而且不会导致精度的明显损失。
为了对数据进行下采样，Compactor 以五分钟和一小时的分辨率连续聚合数据。 对于使用 TSDB XOR 压缩编码的每个原始块，存储不同类型的聚合数据，例如一个块的最小值、最大值或总和。 这允许 Querier 自动选择适合给定 PromQL 查询的聚合。
用户无需特殊配置即可使用降低精度的数据。 当用户放大和缩小时，查询器会自动在不同分辨率和原始数据之间切换。 如果需要，用户可以直接通过请求中的“step”参数进行控制。
由于存储 XNUMX GB 的成本较低，Thanos 默认存储原始数据、五分钟和一小时分辨率数据。 无需删除原始数据。
录音规则
即使使用 Thanos，记录规则也是监控堆栈的重要组成部分。 它们降低了查询的复杂性、延迟和成本。 它们也方便用户按指标获取聚合数据。 Thanos 基于普通 Prometheus 实例，因此在现有 Prometheus 服务器上存储记录规则和警报规则是完全可以接受的。 然而，在某些情况下这可能还不够：
- 全局警报和规则（例如，当服务无法在三个集群中的两个以上运行时发出警报）。
- 本地存储之外的数据的规则。
- 希望将所有规则和警报存储在一个地方。
对于所有这些情况，Thanos 包含一个名为 Ruler 的独立组件，它通过 Thanos 查询计算规则和警报。 通过提供众所周知的 StoreAPI，查询节点可以访问新计算的指标。 随后，它们也存储在对象存储中，并通过 Store Gateway 提供。
灭霸的力量
Thanos 足够灵活，可以根据您的需求进行定制。 从普通的 Prometheus 迁移时，这特别有用。 让我们通过一个简单的示例快速回顾一下我们对 Thanos 组件的了解。 以下是如何将普通 Prometheus 引入“无限指标存储”的世界：
- 将 Thanos Sidecar 添加到您的 Prometheus 服务器 - 例如 Kubernetes Pod 中的 Sidecar 容器。
- 部署多个 Thanos Querier 副本以便能够查看数据。 在这个阶段，很容易在 Scraper 和 Querier 之间建立八卦。 要检查组件的交互，请使用“thanos_cluster_members”指标。
只需这两个步骤就足以从潜在的 Prometheus HA 副本提供全局视图和无缝重复数据删除！ 只需将仪表板连接到 Querier HTTP 端点或直接使用 Thanos UI。
但是，如果您需要指标备份和长期存储，则需要完成另外三个步骤：
- 创建 AWS S3 或 GCS 存储桶。 配置 Sidecar 将数据复制到这些存储桶。 现在可以最小化本地数据存储。
- 部署 Store Gateway 并将其连接到现有的 gossip 集群。 现在就可以查询备份的数据了！
- 部署 Compactor 以使用压缩和下采样来提高长时间的查询效率。
如果您想了解更多，请随时查看我们的 и !
只需五个步骤，我们就将 Prometheus 变成了一个可靠的监控系统，具有全局视图、无限的存储时间和潜在的指标高可用性。
拉取请求：我们需要你！
从一开始就是一个开源项目。 与 Prometheus 的无缝集成以及仅使用 Thanos 的一部分的能力使其成为轻松扩展监控系统的绝佳选择。
我们始终欢迎 GitHub Pull 请求和问题。 同时，请随时通过 Github Issues 或 slack 联系我们如果您有疑问或反馈，或者想分享您的使用体验！ 如果您喜欢我们在 Improbable 所做的事情，请随时与我们联系 - !
来源： habr.com