参考

高级架构

组件

Store-gateway

开源

Grafana Mimir store-gateway

Store-gateway 组件是有状态的，它从长期存储中查询块。在读取路径上，无论是来自用户的查询还是评估规则时产生的查询，querier 和 ruler 都会使用 store-gateway。

Bucket 索引

为了在查询时找到要查找的正确块，store-gateway 需要长期存储中 bucket 的视图。Store-gateway 通过定期下载bucket 索引来保持 bucket 视图的更新。

为了发现每个租户的块和块删除标记，store-gateway 在启动时会为其分片中的每个租户从长期存储中抓取bucket 索引。

对于发现的每个块，store-gateway 会将索引头下载到本地磁盘。在这个初始 bucket 同步阶段，store-gateway 的 /ready 就绪探测端点会报告未就绪状态。

有关 bucket 索引的更多信息，请参阅bucket 索引。

Store-gateway 定期重新下载 bucket 索引，以获取长期存储的更新视图，并发现由 ingester 和 compactor 上传的新块，或由 compactor 删除的块。

自 store-gateway 最后一次检查块以来，compactor 可能已经删除了块或标记了其他块进行删除。Store-gateway 会下载新块的索引头，并卸载（删除）已删除块的本地索引头副本。你可以通过配置 -blocks-storage.bucket-store.sync-interval 标志来控制 store-gateway 检查长期存储更改的频率。

当查询执行时，store-gateway 会下载 chunks，但不会完全下载整个块；store-gateway 只会下载运行给定查询所需的索引和 chunks 部分。为了避免 store-gateway 在后续重启时不得不重新下载索引头，我们建议在运行 store-gateway 时使用持久化磁盘。例如，如果你在 Kubernetes 中运行 Grafana Mimir 集群，可以为 store-gateway 使用带有 PersistentVolumeClaim 的 StatefulSet。

有关索引头的更多信息，请参阅二进制 index-header 文档。

块分片和复制

Store-gateway 使用块分片来在大型集群中水平扩展块。

块会根据通过 -store-gateway.sharding-ring.replication-factor 配置的复制因子在多个 store-gateway 实例之间进行复制。块复制用于防止因某些块在给定时间未被任何 store-gateway 实例加载而导致的查询失败，例如在 store-gateway 故障或重启 store-gateway 实例（例如，在滚动更新期间）时。

Store-gateway 实例构建一个hash 环，并在环中注册的 store-gateway 实例池中对块进行分片和复制。

Store-gateway 持续监控环状态。当环拓扑发生变化时，例如，添加或删除新实例，或实例变得健康或不健康时，每个 store-gateway 实例会重新同步分配给其分片的块。store-gateway 重新同步过程使用与环中分配给该实例的令牌范围匹配的块 ID 哈希。

store-gateway 会加载属于其 store-gateway 分片的每个块的索引头。store-gateway 加载块的索引头后，该块即可供 querier 查询。当 querier 通过 store-gateway 查询块时，响应中包含被查询的块 ID 列表。如果 querier 尝试查询 store-gateway 尚未加载的块，则 querier 会在另一个 store-gateway 上重试查询，最多重试到 -store-gateway.sharding-ring.replication-factor 的值（默认为 3）。如果无法从任何副本成功查询到该块，则查询失败。

注意
你必须通过 -store-gateway.sharding-ring.* 标志或其相应的 YAML 配置参数来配置hash 环。

分片策略

Store-gateway 使用 shuffle 分片将每个租户的块分散到 store-gateway 实例的一个子集上。

注意
使用 shuffle 分片时，只有一部分 store-gateway 实例会加载租户的块。
这将租户工作负载引入的问题影响范围限制在其分片实例内。

-store-gateway.tenant-shard-size 标志（或其相应的 YAML 配置参数）决定了每个租户的默认 store-gateway 实例数量。limits overrides 中的 store_gateway_tenant_shard_size 可以按租户覆盖分片大小。

默认的 -store-gateway.tenant-shard-size 值为 0，这意味着租户的块会分布在所有 store-gateway 实例上。

有关 shuffle 分片的更多信息，请参阅配置 shuffle 分片。

自动遗忘

Store-gateway 包含一个自动遗忘功能，当 store-gateway 未正确关闭时，可以使用此功能将实例从另一个 store-gateway 的环中注销。在正常情况下，当 store-gateway 实例关闭时，它会自动从环中注销。但是，如果发生崩溃或节点故障，实例可能无法正确注销，这会在环中留下一个虚假条目。

自动遗忘功能的工作原理如下：当一个健康的 store-gateway 实例识别到环中的某个实例不健康时长超过配置的 -store-gateway.sharding-ring.heartbeat-timeout 值的 10 倍时，健康的实例会将不健康的实例从环中移除。

通过设置 -store-gateway.sharding-ring.auto-forget-enabled=false 可以禁用 store-gateway 自动遗忘功能。

区域感知

Store-gateway 复制可选地支持区域感知。当你启用区域感知复制且块复制因子大于 1 时，每个块都会被复制到位于不同可用区的 store-gateway 实例中。

为 store-gateway 启用区域感知复制:

通过 -store-gateway.sharding-ring.instance-availability-zone CLI 标志或其相应的 YAML 配置参数配置每个 store-gateway 的可用区。
通过 -store-gateway.sharding-ring.zone-awareness-enabled CLI 标志或其相应的 YAML 配置参数启用块区域感知复制。在 store-gateway、querier 和 ruler 上设置此区域感知复制标志。
要应用新配置，请滚动更新 store-gateway、querier 和 ruler。

启动时等待环稳定

如果集群冷启动或同时扩容到两个或更多 store-gateway 实例，这些 store-gateway 可能会在不同时间启动。因此，store-gateway 会根据 hash 环的不同状态运行初始块同步。

例如，在冷启动时，第一个加入环的 store-gateway 可能会加载所有块，因为分片逻辑是基于环的当前状态运行的，而当前环中只有一个 store-gateway。

为了减少 store-gateway 在不同时间启动的可能性，你可以配置 store-gateway 在启动时等待环稳定。当在 -store-gateway.sharding-ring.wait-stability-min-duration 标志中指定的最小持续时间内没有实例被添加到或从环中移除时，环被认为是稳定的。如果在达到 -store-gateway.sharding-ring.wait-stability-max-duration 标志中指定的最大持续时间后环仍在变化，store-gateway 将停止等待稳定环并继续启动。

要在启动时启用等待环稳定，请使用 -store-gateway.sharding-ring.wait-stability-min-duration=1m 启动 store-gateway，这是生产系统的推荐值。

块索引头

索引头是块索引的一个子集，store-gateway 从长期存储下载并保存在本地磁盘上。将索引头保存在本地磁盘上可以加快查询执行速度。

索引头懒加载

默认情况下，store-gateway 将索引头下载到磁盘，直到需要时才加载到内存。当查询需要时，索引头会被加载，并在经过你在 -blocks-storage.bucket-store.index-header.lazy-loading-idle-timeout 中指定的不活动时间后由 store-gateway 自动释放。

Grafana Mimir 提供了一个配置标志 -blocks-storage.bucket-store.index-header.lazy-loading-enabled=false 来禁用索引头懒加载。禁用后，store-gateway 在启动时会加载所有索引头，这使得查询时可以更快地访问索引头中的数据，但代价是启动时间更长。然而，在一个拥有大量块的集群中，每个 store-gateway 可能都会加载大量的索引头，而不管它们在查询时被使用的频率如何。

加载索引头时，只有一部分会保留在内存中以减少内存使用。索引头的其余部分根据需要从磁盘读取。这要求 store-gateway 有可用的内存供操作系统用于缓存磁盘访问。

缓存

store-gateway 支持以下类型的缓存

索引缓存
Chunks 缓存
元数据缓存

我们建议你在生产环境中使用缓存。有关配置缓存的更多信息，请参阅生产环境技巧。

索引缓存

Store-gateway 可以使用缓存来加速从块索引中查找序列和标签。store-gateway 支持以下后端

inmemory
memcached

内存索引缓存

默认情况下，inmemory 索引缓存是启用的。

使用内存索引缓存的权衡考量如下

优点：没有延迟。
缺点：当复制因子 > 1 时，驻留在 store-gateway 内存中的数据会在不同实例之间重复。这会导致整体内存使用量增加和缓存命中率降低。

你可以使用 -blocks-storage.bucket-store.index-cache.inmemory.max-size-bytes 标志或其相应的 YAML 配置参数来配置索引缓存最大大小。

Memcached 索引缓存

memcached 索引缓存使用 Memcached 作为缓存后端。

使用 Memcached 索引缓存的权衡考量如下

优点：通过创建 Memcached 集群，你可以扩展到单个节点的内存之外，该集群由多个 store-gateway 实例共享。
缺点：与使用内存缓存相比，系统在缓存往返中会遇到更高的延迟。

Memcached 客户端使用跳跃哈希算法将缓存条目分片到 Memcached 服务器集群中。由于 memcached 客户端使用跳跃哈希算法，请确保 memcached 服务器未位于负载均衡器之后，并配置 memcached 服务器的地址，以便在进行扩容或缩容时，服务器可以从列表的末尾添加或移除。

例如，如果你在 Kubernetes 中运行 Memcached，你可以

使用 StatefulSet 部署你的 Memcached 集群。
为 Memcached StatefulSet 创建一个 headless service。
使用 dnssrvnoa+ 服务发现配置 Mimir 的 Memcached 客户端地址。

配置 Memcached 后端:

使用 -blocks-storage.bucket-store.index-cache.backend=memcached。
使用 -blocks-storage.bucket-store.index-cache.memcached.addresses 标志设置 Memcached 服务的地址。

DNS 服务发现会解析 Memcached 服务器的地址。

Chunks 缓存

Store-gateway 还可以使用缓存来存储从长期存储中抓取的chunks。Chunks 包含实际样本，如果查询在同一时间范围内命中相同的序列，则可以重复使用。Chunks 只能缓存到 Memcached 中。

要启用 chunks 缓存，请设置 -blocks-storage.bucket-store.chunks-cache.backend=memcached。你可以通过包含前缀 -blocks-storage.bucket-store.chunks-cache.memcached.* 的标志来配置 Memcached 客户端。