Prometheus 被设计为作为单个服务器运行。这种方法将允许您处理数千个目标和数百万个时间序列，但是随着您的扩展，您可能会发现自己处于这种情况还不够。本章解决了这种必要性，并阐明了如何通过分片来扩展 Prometheus。然而，分片使得拥有基础设施的全局视图变得更加困难。为了解决这个问题，我们还将介绍分片的优点和缺点，联邦是如何出现的，最后，介绍由 Prometheus 社区创建的一个组件 Thanos，用于解决所提出的一些问题。

简而言之，本章将涵盖以下主题：

• Test environment for this chapter
• Scaling with the help of sharding
• Having a global view using federation
• Using Thanos to mitigate Prometheus shortcomings at scale

在本章中，我们将重点关注 Prometheus 的扩展和联合。为此，我们将部署三个实例来模拟全局 Prometheus 实例从另外两个实例收集指标的场景。这种方法不仅可以让我们探索所需的配置，还可以了解一切如何协同工作。

我们将使用的设置如下图所示：

在下一节中，我们将解释如何启动并运行测试环境。

要启动新的测试环境，请进入以下章节路径，相对于代码存储库根目录：

cd ./chapter13/

使用以下命令确保没有其他测试环境正在运行并启动本章的环境：

vagrant global-status
vagrant up

您可以使用以下命令验证测试环境的成功部署：

vagrant status

这将输出以下内容：

Current machine states:

shard01                   running (virtualbox)
shard02                   running (virtualbox)
global                    running (virtualbox)

This environment represents multiple VMs. The VMs are all listed above with their current state. For more information about a specific VM, run `vagrant status NAME`.

当部署任务结束时，您将能够使用您最喜欢的支持 JavaScript 的 Web 浏览器验证主机上的以下端点：

您应该能够使用相应的命令访问这些实例中的每一个：

完成测试后，只需确保您在 ./chapter13/ 中并执行以下命令：

vagrant destroy -f

不要太担心： 如果需要，您可以轻松地再次启动环境。

随着增长而来的是更多的团队、更多的基础设施和更多的应用程序。随着时间的推移，运行单个 Prometheus 服务器可能开始变得不可行：记录/警报规则和抓取作业的更改变得更加频繁（因此需要重新加载，这取决于配置的抓取间隔可能需要几分钟），错过随着 Prometheus 不堪重负，或者负责该实例的人员或团队可能会成为组织流程方面的瓶颈，擦伤可能会开始发生。发生这种情况时，我们需要重新考虑解决方案的架构，以便相应地进行扩展。值得庆幸的是，这是社区一次又一次地解决的问题，因此有一些关于如何解决这个问题的建议。这些建议围绕着分片。

在这种情况下，分片意味着将抓取目标列表拆分到两个或多个 Prometheus 实例中。这可以通过两种方式完成：通过垂直或水平分片。垂直分片是迄今为止最常见的方法，它是通过将抓取作业在逻辑上（例如，按范围、技术、组织边界）分组到不同的 Prometheus 实例中来完成的，其中分片限制是抓取作业。另一方面，水平分片是在抓取作业的级别完成的；这意味着拥有多个 Prometheus 实例，每个实例为给定作业抓取目标子集。很少使用水平分片，因为抓取作业通常大于单个 Prometheus 实例可以处理的大小。

此外，我们不考虑为每个数据中心/环境使用 Prometheus 作为分片；由于带宽和延迟以及弹性（不太容易遭受网络故障）的原因，Prometheus 应该与它监控的系统/服务一起运行。

当单个 Prometheus 实例不够用时，一个很好的扩展起点是将抓取作业拆分为逻辑组，然后将这些组分配给不同的 Prometheus 实例。这称为垂直分片。这些组可以围绕对您有意义的任何事物进行：按架构/范围（前端、后端、数据库）、按层（操作系统级指标、基础设施服务、应用程序）、按内部组织垂直、按团队、按网络安全边界（这样抓取不需要跨越防火墙），甚至是应用程序集群。

下图举例说明了这种垂直分片的样子：

这种类型的分片还可以实现 Prometheus 实例之间的隔离，这意味着来自给定目标集的大量使用的指标子集可以拆分为多个实例，可能具有更多资源。这样，它们的大量使用所带来的任何负面影响都将得到限制，并且不会影响整体监控平台的稳定性。

此外，为每个团队进行垂直分片可以带来一些组织上的好处：

• It makes cardinality considerations more visible to the service owners.
• Teams feel both empowered and accountable for the monitoring of their services.
• It can enable more experimentation for rules and dashboards without the fear of impacting others.

我们经历了几种垂直分片 Prometheus 的策略，但还有一个问题我们仍未解决：与单个作业相关的扩展需求。想象一下，您的工作在一个数据中心内有数以万计的抓取目标，并且没有一种合乎逻辑的方法可以进一步拆分它。在这种情况下，最好的选择是水平分片，将相同的作业分散到多个 Prometheus 服务器上。下图提供了此类分片的示例：

为此，我们必须依靠 hashmod 重新标记操作。 hashmod 的工作方式是将 target_label 设置为串联 source_labels 的散列的 modulus，然后我们放置在 Prometheus 服务器中。我们可以在 shard01 和 shard02 的测试环境中看到这个配置，有效地分片节点作业。我们来看看下面的配置，可以在 /etc/prometheus/prometheus.yml 找到：

...
scrape_configs:
  - job_name: 'node'
    static_configs:
      - targets: ['shard01:9100', 'shard02:9100', 'global:9100']
    relabel_configs:
      - source_labels: [__address__]
        modulus: 2 # Because we're using 2 shards
        target_label: __tmp_shard
        action: hashmod
      - source_labels: [__tmp_shard]
        regex: 0 # Starts at 0, so this is the first
       action: keep
...

在以下屏幕截图中，我们可以并排看到 shard01 和 shard02 Prometheus 实例的 /service-discovery 端点。 hashmod 操作的结果允许我们将节点导出器作业拆分到两个实例中，如下所示：

很少有人达到需要这种类型分片的规模，但很高兴知道 Prometheus 开箱即用地支持它。

分片策略，无论是垂直还是水平，虽然在某些情况下是必要的，但不应掉以轻心。管理多个 Prometheus 实例的多个配置的复杂性迅速增加，如果您没有相应地计划所需的自动化，您的生活会更加困难。可以以编程方式设置外部标签、外部 URL、用户控制台和抓取作业等内容，以减少维护分片的团队的操作工作量。

拥有全局视图也成为一个问题，因为每个 Prometheus 实例都有自己的数据子集。由于数据的位置可能不会立即清晰（例如，在 Grafana 中使用多个数据源时），这会使仪表板更加困难，并且还可以防止某些查询聚合分布在全球多个分片上的服务。这个问题可以通过几种技术来缓解，我们将在本章后面进行探讨。

最后，如果所需的时间序列不在同一个分片中，一些记录和警报规则可能会变得不切实际。例如，假设我们有一个带有操作系统级别指标的分片和另一个带有应用程序指标的分片。需要关联来自两个分片的指标的警报将是一个问题。这个问题可以通过仔细规划每个分片的内容来缓解，通过使用联合在需要的地方提供所需的指标，或者通过远程写入可以在 Prometheus 之外执行此操作的外部系统（正如我们将在第 14 章， 将长期存储与 Prometheus 集成）。

正如本章开头所提到的，如果配置和使用得当，单个 Prometheus 实例将带您走很长一段路。努力避免高基数指标应该是头等大事，减少开始分片的需要。有助于保护 Prometheus 实例免受产生不合理数量指标的抓取目标的影响，包括定义每个抓取作业的最大样本摄取量。为此，您只需将 sample_limit 添加到抓取作业中；如果 metric_relabel_configs 之后的样本数量超过了配置的限制，则抓取将被完全丢弃。示例配置如下：

scrape_configs:
  - job_name: 'massive_job'
    sample_limit: 5000
    static_configs:
      - targets:
        - 'shard01:9999'
        - 'shard02:9999'

以下屏幕截图说明了当抓取达到配置的 sample_limit 时会发生什么：

使用此限制器时，您应该注意使用 prometheus_target_scrapes_exceeded_sample_limit_total 指标和 up 指标来丢弃刮擦。虽然后者告诉您 Prometheus 无法抓取目标，但前者会告诉您原因。

如果放弃刮擦是不可能的，并且您能够承受分辨率的损失，那么另一种方法是增加刮擦间隔。请记住，您不应将其增加超过两分钟，因为这样做会导致由于单次刮擦失败而导致指标过时的风险，正如我们在 第 5 章，运行 Prometheus 服务器。

当您有多个 Prometheus 服务器时，要知道要查询哪个服务器以获取某个指标可能会变得非常麻烦。另一个很快出现的问题是如何聚合来自多个实例的数据，可能在多个数据中心。这就是联邦发挥作用的地方。联合允许您让 Prometheus 实例从其他实例中抓取选定的时间序列，从而有效地充当更高级别的聚合实例。这可以以分层方式发生，每一层将来自较低级别实例的指标聚合到更大的时间序列中，或者以跨服务模式发生，其中从同一级别的实例中选择一些指标进行联合，以便一些记录和警报规则成为可能。例如，您可以收集每个分片中服务吞吐量或延迟的数据，然后在所有分片中聚合它们以获得全局值。

让我们看一下在 Prometheus 中设置联邦需要什么，然后进入上述每个联邦模式。

正在运行的 Prometheus 服务器公开了一个在 /federate 处提供的特殊端点。此端点允许检索与一个或多个即时向量选择器匹配的时间序列（我们在 第 7 章，Prometheus 查询语言– PromQL）。为了使这些机制更清晰，我们在测试环境中提供了一个非常简单的示例。每个分片实例都有一个记录规则，生成代表对导出器的 HTTP 请求数量的聚合指标，如以下代码块所示：

vagrant@shard01:~$ cat /etc/prometheus/rules.yml
groups:
  - name: recording_rules
    rules:
      - record: job:promhttp_metric_handler_requests:sum_rate1m
        expr: sum by (job) (rate(promhttp_metric_handler_requests_total[1m]))

为了提供全局视图，我们可以在测试环境中使用 global 实例来抓取两个分片的联合端点，只请求那些聚合指标（所有以 job:)，如以下代码段所示：

vagrant@global:~$ cat /etc/prometheus/prometheus.yml 
...
scrape_configs:
  - job_name: shards
    honor_labels: true
    metrics_path: /federate
    params:
      match[]:
        - '{__name__=~"job:.+"}'
    static_configs:
      - targets:
        - shard01:9090
        - shard02:9090
...

在这个片段中有几件事需要注意。联合使用与常规抓取作业相同的机制，但需要配置不同的抓取端点，以及一个 HTTP 参数来指定我们要收集哪些指标。此外，设置 honor_labels: true 将确保保留所有原始标签值并且永远不会被覆盖；这需要配置，否则 Prometheus 会将诸如 instance 和 job 之类的标签设置为来自抓取作业的值。

您可以在我们的测试环境中的 http://192.168.42.12:9090/targets 端点检查聚合器 Prometheus 实例中联合目标的状态，如下所示：

我们还可以在全局 Prometheus Web 界面中测试指标的联合：即使这个实例没有抓取任何导出器，也没有记录规则，我们可以从 job:promhttp_metric_handler_requests:sum_rate1m metric，最初是在每个分片实例中产生的。请注意，返回的 job 标签来自原始作业，而不是联合抓取作业。此外，我们可以看到我们在实例中配置为外部标签的 shard 标签存在于此； external_labels 部分中定义的标签会自动添加到从 /federate 端点返回的指标中，如下所示：

现在我们了解了联合工作的机制，我们可以继续研究联合的常见模式和最佳实践。

当开始在 Prometheus 中实施联邦时，首先要注意的是，联邦指标集应该是预先聚合的或人工挑选的。尝试使用联合从一个 Prometheus 将大量数据甚至每个指标导入另一个 Prometheus 通常是一个坏主意，原因如下：

• Due to the massive amount of data being collected in each scrape, it will have a negative performance impact on both the instance producing the metrics and the one consuming them.
• Since scrape ingestion is atomic but not isolated, the Prometheus instance being targeted can present an incomplete snapshot of its time series due to races: it can be in the middle of processing scrape jobs and will return what is had processed at that moment. This is especially relevant for multi-series metric types such as histograms and summaries.
• Bigger scrapes are more likely to suffer from timeouts, which will in turn create gaps in the data on the Prometheus instance doing the federation scrapes.
• Trying to get all time series from a Prometheus instance into another defeats the point of federation. If it's a matter of proxying metrics, an actual proxy server would probably be a better choice. Nevertheless, the best practice is still to run Prometheus near what you're trying to monitor.

Prometheus 时间序列联邦有两种主要的实现方式：分层和跨服务。正如我们将看到的，这两种模式是互补的，可以一起使用。

拥有多个分片，甚至不止一个数据中心，意味着时间序列数据现在分布在不同的 Prometheus 实例中。分层联合旨在通过让一个或多个 Prometheus 服务器从其他 Prometheus 实例收集高级聚合时间序列来解决此问题。您可以拥有两个以上的联合级别，但这需要很大的规模。这允许更高层的 Prometheus 对基础设施及其应用程序有更广阔的视野。但是，由于只应联合聚合指标，因此具有最多上下文和详细信息的指标仍将驻留在较低层。下图说明了这是如何工作的：

例如，您可能希望了解多个数据中心的延迟情况。满足该要求的三层 Prometheus 层次结构可能如下所示：

• A couple of vertical shards scraping several jobs
• A datacenter instance scraping those shards for time series aggregated at the job level (__name__=~"job:.+")

• A global Prometheus that scrapes the datacenter instances for time series aggregated at the datacenter level (__name__=~"dc:.+")

在使用这种布局的监控平台时，通常从最高级别开始，然后向下钻取到下一个级别。这可以使用 Grafana 轻松完成，因为您可以将联合层次结构中的每一层都配置为数据源。

警报规则应尽可能靠近它们使用的时间序列的原点运行，因为需要跨越的每个联邦层都会在警报关键路径中引入新的故障点。在跨数据中心进行聚合时尤其如此，因为刮擦可能需要通过不太可靠的网络，甚至通过互联网链接。

当您需要从本地另一个 Prometheus 实例中选择一些时间序列来记录或警报规则时，这种类型的联合非常有用。回到示例场景，您有一个 Prometheus 实例负责抓取节点导出器和另一个用于应用程序，此模式将允许您联合特定的操作系统级指标，然后可以在应用程序警报中使用，如下图所示：

跨服务联合的配置看起来与之前的模式基本相同，但在这种情况下，抓取的 Prometheus 位于同一逻辑层中，并且使用的选择器应该匹配特定的指标而不是聚合。

在下一节中，我们将介绍一个在 Prometheus 社区中获得关注的新组件，并以一种新的有趣的方式解决拥有全局视图的挑战。

当您开始扩展 Prometheus 时，您很快就会遇到跨分片可见性的问题。事实上，Grafana 可以提供帮助，因为您可以在同一个仪表板面板中添加多个数据存储源，但这变得更难维护，尤其是在多个团队有不同需求的情况下。当没有明确定义的边界时，跟踪哪个分片具有哪个指标可能不是微不足道的 - 虽然当您每个团队都有一个分片时这可能不是问题，因为每个团队可能只关心自己的指标，当有问题时就会出现是由单个团队维护的多个分片，并作为服务公开给组织。

此外，通常的做法是运行两个相同的 Prometheus 实例以防止警报路径中的单点故障 (SPOF) - 称为 HA（或高可用性）对。这使仪表板进一步复杂化，因为每个实例的数据都会略有不同（尤其是在仪表指标方面），并且使用负载均衡器分配查询将导致仪表板数据刷新时的结果不一致。

值得庆幸的是，我们启动了一个项目来解决这个确切的问题– 这个项目被称为灭霸。它是在 Improbable I/O 上与 Fabian Reinartz（Prometheus 2.x 中新存储引擎/时间序列数据库的作者）合作开发的。

Prometheus 有明确的作用范围；例如，它不是为集群而构建的，到目前为止所做的所有决定都始终以可靠性和性能为首要目标。这些设计选择是 Prometheus 成功的一些基石，并允许它从处理少数目标的简单部署扩展到每秒处理一百万个摄取样本的大型实例，但选择几乎总是伴随着权衡。虽然 Prometheus 确实提供了一些解决方法来实现功能而不诉诸共享状态（即通过联合，正如我们之前所见），但它这样做有一些限制，例如必须选择要联合的指标。正是在这些情况下，创造性的解决方案似乎试图克服其中的一些限制。 Thanos 就是一个很好的例子，我们稍后会看到。

我们将在 第 14 章中讨论灭霸的更多功能, 将长期存储与 Prometheus 集成，但目前我们的重点将放在该项目的全局查询方面。

要使用 Thanos 获得全局视图，我们必须首先了解它的一些组件。与 Prometheus 一样，Thanos 是用 Go 编写的，并提供一个二进制文件（针对每个平台/架构），其行为取决于执行时提供的子命令。在我们的例子中，我们将扩展 sidecar 和 Query 组件。

简而言之，sidecar 使来自 Prometheus 实例的数据可用于其他 Thanos 组件，而 Query 组件是 Prometheus 的 API 兼容替代品，它将接收到的查询分发给其他 Thanos 组件，例如 Sidecar 甚至其他 Query 实例。从概念上讲，Thanos 采用的全局视图方法类似于下图：

可以返回查询结果的 Thanos 组件实现了所谓的 store API。当请求到达 Thanos 查询器时，它将扇出到为其配置的所有存储 API 节点，在我们的示例中，这些节点是使时间序列可从其各自的 Prometheus 服务器获得的 Thanos sidecar。查询器将整理响应（能够聚合脱节或去重的数据），然后对数据集执行所需的 PromQL 查询。在使用 Prometheus 服务器对实现高可用性时，重复数据删除功能特别有用。

现在，让我们来看看这些组件中的每一个，深入了解它们的工作原理以及如何设置它们。

Sidecar 组件旨在与 Prometheus 一起在本地部署，并通过其远程读取 API 连接到它。 Prometheus 的远程读取 API 允许与其他系统集成，以便他们可以访问样本，就好像它们在本地可供他们查询一样。这显然会在查询路径中引入网络，这可能会导致与带宽相关的问题。 Sidecar 利用这一点将 Prometheus 中的数据提供给其他 Thanos 组件。它将存储 API 公开为 gRPC 端点（默认绑定到端口 10901），然后将由 Thanos 查询组件使用，从查询者的角度有效地将 sidecar 转换为数据存储。 Sidecar 还在端口 10902 上公开了一个 HTTP 端点，其中包含 /metrics 的处理程序，以便您可以在 Prometheus 中收集其内部指标。

Sidecar 所附加的 Prometheus 实例必须设置 external_labels 以便唯一标识每个实例。这对于 Thanos 过滤出要查询的存储 API 和重复数据删除工作至关重要。

在我们的测试环境中，我们可以找到在每个可用分片中运行的 Thanos sidecar。为了快速验证正在使用的配置，我们可以在任何分片实例中运行以下指令：

vagrant@shard01:~$ systemctl cat thanos-sidecar
...
ExecStart=/usr/bin/thanos sidecar \
           --prometheus.url "http://localhost:9090"
...

前面的代码片段表明 sidecar 正在连接到本地 Prometheus 实例。 Sidecar 提供了更多功能，我们将在下一章中看到，但为了实现全局视图，这种配置就足够了。

查询组件实现了 Prometheus HTTP API，它使 PromQL 表达式能够针对来自所有已配置的 Thanos 存储 API 的数据运行。它还包括一个用于查询的 Web 界面，该界面基于 Prometheus 自己的 UI 并进行了一些小改动，让用户有宾至如归的感觉。该组件是完全无状态的，可以水平缩放。由于兼容 Prometheus API，可以直接在 Grafana 中作为 Prometheus 类型的数据源使用，实现对 Thanos 的 Prometheus 查询的 drop-in 替换。

这个 Thanos 组件也在我们的测试环境中运行，特别是在 global 实例中，运行以下指令可以查看其配置：

vagrant@global:~$ systemctl cat thanos-query
...
ExecStart=/usr/bin/thanos query \
            --query.replica-label "shard" \
            --store "shard01:10901" \
            --store "shard02:10901"
...

正如我们在前面的代码片段中看到的，我们需要使用我们希望通过查询器提供的存储 API 来指定所有组件。由于我们使用该组件的大部分默认值，因此 Web 界面在端口 10902 上可用，我们可以通过将浏览器指向 http://192.168.42.12 来验证： 10902/stores，如下截图所示：

--query.replica-label 标志允许使用特定的 Prometheus 外部标签对指标进行重复数据删除。例如，我们在 shard01 和 shard02 上有完全相同的 icmp 作业，并且都有一个 shard 外部标签以唯一标识它们。在没有任何重复数据删除的情况下，我们会在使用此作业进行查询时看到每个指标的两个结果，因为两个 sidecar 都有相关数据。通过将 shard 标记为标识副本的标签，查询者可以选择其中一个结果。我们可以通过应用程序编程接口（在 GET 参数中发送 dedup=true）或 Web 界面（选择 deduplication 选项）切换重复数据删除，取决于我们是想包含来自所有商店 API 的指标，还是只包含单个结果，就好像只有一个 Prometheus 实例有数据一样。以下屏幕截图说明了这种差异：

默认情况下启用重复数据删除功能，以便查询器可以在服务查询中无缝替换 Prometheus。这样一来，Grafana 等上游系统就可以在不知道查询层发生变化的情况下继续运行。

在本章中，我们解决了有关大规模运行 Prometheus 的问题。尽管单个 Prometheus 实例可以让您走得更远，但如果需要，让知识增长是个好主意。我们已经了解了垂直和水平分片的工作原理、何时使用分片以及分片带来的好处和关注点。我们在联合 Prometheus（分层或跨服务）时了解了常见模式，以及如何根据我们的要求在它们之间进行选择。由于有时我们想要的不仅仅是开箱即用的联邦，因此我们被介绍了 Thanos 项目以及它如何解决全局视图问题。

在下一章中，我们将解决另一个常见的需求，它不是 Prometheus 项目的核心关注点，即时间序列的长期存储。

1. When should you consider sharding Prometheus?
2. What's the difference between sharding vertically and horizontally?
3. Is there anything you can do before opting for a sharding strategy?
4. What type of metrics are best suited for being federated in a hierarchical pattern?
5. Why might you require cross-service federation?
6. What protocol is used between Thanos querier and sidecar?
7. If a replica label is not set in a Thanos querier that is configured with sidecars running alongside Prometheus HA pairs, what happens to the results of queries that are executed there?

• Scaling and Federating Prometheus: https://www.robustperception.io/scaling-and-federating-prometheus
• Thanos components: https://github.com/improbable-eng/thanos/tree/master/docs/components
• Thanos - Prometheus at scale: https://improbable.io/blog/thanos-prometheus-at-scale