Grafana Mimir 分发器

分发器是一个无状态组件，它接收来自 Prometheus 或 Grafana Alloy 的时序数据。分发器验证数据的正确性，并确保它在给定租户的配置限制内。然后，分发器将数据分成批次，并行发送到多个 ingesters，在 ingesters 之间分片时序，并按配置的复制因子复制每个时序。默认情况下，配置的复制因子为三。

验证

分发器在将接收到的数据写入 ingesters 之前进行清理和验证。由于单个请求可能包含有效和无效的指标、样本、元数据和 exemplar，分发器只将有效数据传递给 ingesters。分发器不会在发送给 ingesters 的请求中包含无效数据。如果请求包含无效数据，分发器返回 400 HTTP 状态码，并在响应体中显示详细信息。关于第一个无效数据的详细信息通常由发送方（无论是 Prometheus 还是 Grafana Alloy）记录。

分发器数据清理包括以下转换：

指标元数据 help 会被截断以符合通过 -validation.max-metadata-length 标志定义的长度。

分发器验证包括以下检查：

指标元数据和标签符合 Prometheus 暴露格式。
指标元数据（name 和 unit）的长度不超过通过 -validation.max-metadata-length 标志定义的长度。
每个指标的标签数量不超过 -validation.max-label-names-per-series。
每个指标标签名称的长度不超过 -validation.max-length-label-name。
每个指标标签值的长度不超过 -validation.max-length-label-value。
每个样本时间戳不晚于 -validation.create-grace-period。
每个 exemplar 具有时间戳和至少一对非空的标签名称和值对。
每个 exemplar 不超过 128 个标签。

注意
对于每个租户，您可以通过修改运行时配置中的 overrides 部分来覆盖验证检查。

速率限制

分发器包含两种不同的速率限制器，适用于每个租户。

请求速率
每个租户在 Grafana Mimir 集群中每秒可以服务的最大请求数。
摄取速率
每个租户在 Grafana Mimir 集群中每秒可以摄取的最大样本数。

如果超出任何这些速率，分发器将丢弃请求并返回 HTTP 429 响应码。

在内部，这些限制是使用每个分发器的本地速率限制器实现的。每个分发器的本地速率限制器配置的限制为 limit / N，其中 N 是健康的分发器副本数量。如果分发器副本数量发生变化，分发器会自动调整请求和摄取速率限制。由于这些速率限制是使用每个分发器的本地速率限制器实现的，因此它们要求写入请求在分发器池中均匀分布。

使用以下标志配置速率限制：

-distributor.request-rate-limit：请求速率限制，按租户计算，单位为请求/秒
-distributor.request-burst-size：允许的请求突发大小（请求数量），按租户计算
-distributor.ingestion-rate-limit：摄取速率限制，按租户计算，单位为样本/秒
-distributor.ingestion-burst-size：允许的摄取突发大小（样本数量），按租户计算

注意
您可以通过在运行时配置的 overrides 部分设置 request_rate、ingestion_rate、request_burst_size 和 ingestion_burst_size 来按租户覆盖速率限制。

注意
默认情况下，Prometheus 远程写入不会在 HTTP 429 响应状态码时重试请求。要修改此行为，请在 Prometheus 的 remote_write 配置中使用 retry_on_http_429: true。

配置

分发器形成一个哈希环（称为分发器环）来相互发现并正确强制执行限制。要配置分发器哈希环，请参阅配置哈希环。

高可用性跟踪器

远程写入发送方（如 Prometheus）可以配置成对，这意味着即使其中一个远程写入发送方因维护而关闭或因故障不可用，指标也会继续被抓取并写入 Grafana Mimir。我们将此配置称为高可用性 (HA) 对。

分发器包含一个 HA 跟踪器。启用 HA 跟踪器后，分发器会从 Prometheus HA 对中接收到的时序进行去重。这使您可以拥有同一 Prometheus 服务器的多个 HA 副本，它们将相同的时序写入 Mimir，然后在 Mimir 分发器中对时序进行去重。

有关 HA 去重以及如何配置的更多信息，请参阅配置 HA 去重。

分片和复制

分发器在 ingesters 之间分片和复制接收到的时序。您可以通过 -ingester.ring.replication-factor 标志配置每个时序写入的 ingester 副本数量，默认值为 3。分发器使用一致性哈希结合可配置的复制因子来确定哪些 ingesters 接收给定的时序。

分片和复制使用 ingesters 的哈希环。对于每个接收到的时序，分发器使用指标名称、标签和租户 ID 计算哈希。计算出的哈希称为令牌。分发器在哈希环中查找令牌以确定将时序写入哪些 ingesters。

有关更多信息，请参阅哈希环。

多数一致性

由于分发器共享对同一个哈希环的访问，写入请求可以发送到任何分发器。您还可以在其前面设置一个无状态负载均衡器。

为确保查询结果一致，Mimir 在读取和写入时使用 Dynamo 式多数一致性。分发器等待 n/2 + 1 个 ingesters 的成功响应（其中 n 是配置的复制因子），然后向 Prometheus 写入请求发送成功响应。

跨分发器的负载均衡

我们建议在分发器实例之间随机负载均衡写入请求。如果您在 Kubernetes 集群中运行 Grafana Mimir，您可以定义一个 Kubernetes 服务作为分发器的入口。

注意
Kubernetes Service 在 Kubernetes 端点之间均衡 TCP 连接，但不会在单个 TCP 连接内均衡 HTTP 请求。
如果启用 HTTP 持久连接（也称为 HTTP keep-alive），Prometheus 会为远程写入分片的每个远程写入 HTTP 请求重用同一个 TCP 连接。这可能导致分发器接收到的远程写入 HTTP 请求分布不均。
为了改善分发器之间的请求均衡，请考虑增加 Prometheus 的 remote write 配置中的 min_shards。