文档

Helm chart

Grafana mimir-distributed Helm chart

迁移指南

从单区域复制迁移到 Mimir Helm chart 4.0 版本中的区域感知复制

Enterprise 开源

从单区域复制迁移到 Mimir Helm chart 4.0 版本中的区域感知复制

mimir-distributed Helm chart 4.0 版本默认启用区域感知复制。这对现有安装是一个破坏性变更，需要进行迁移。

本文档说明如何使用 Helm 将有状态组件从单区域迁移到区域感知复制。涉及的三个组件是 alertmanager、store-gateway 和 ingester。

Alertmanager 和 store-gateway 的迁移路径比较直接，但迁移 ingester 则更为复杂。

本文档适用于 Grafana Mimir 和 Grafana Enterprise Metrics。

先决条件

根据当前安装的 mimir-distributed Helm chart 版本，请确保满足以下要求。

如果当前安装的 mimir-distributed Helm chart 版本低于 4.0.0 (版本 < 4.0.0)。
1. 请遵循 CHANGELOG.md 中 4.0.0 版本的升级说明。特别是，在升级 chart 之前，请务必禁用区域感知功能
  yaml
```
ingester:
  zoneAwareReplication:
    enabled: false
store_gateway:
  zoneAwareReplication:
    enabled: false
rollout_operator:
  enabled: false
```
  注意
```
  A direct upgrade from non-zone aware ingesters to zone-aware ingesters will cause data loss.
```
2. 如果您修改了 mimir.config 值，请确保合并 chart 中的最新版本，或者考虑使用 mimir.structuredConfig。
  有关更多信息，请参见使用 Helm 管理 Grafana Mimir 的配置。
如果当前安装的 mimir-distributed Helm chart 版本高于 4.0.0 (版本 >= 4.0.0)。
1. 请确保相关组件已关闭区域感知复制功能。
  例如，store-gateway
  yaml
```
store_gateway:
  zoneAwareReplication:
    enabled: false
```
2. 如果您修改了 mimir.config 值，请确保合并 chart 中的最新版本，或者考虑使用 mimir.structuredConfig。
  有关更多信息，请参见使用 Helm 管理 Grafana Mimir 的配置。

将 alertmanager 迁移到区域感知复制

对 alertmanager 使用区域感知复制是可选的，并且仅在 alertmanager 作为 StatefulSet 部署时可用。

配置 Alertmanager 的区域感知复制

本节介绍如何规划和配置 alertmanager.zoneAwareReplication Helm value 下定义的可用区。

通常有两种用例

当副本数大于 3 时，加快 alertmanager 的 rollout 速度。在这种情况下，请使用 small.yaml、large.yaml、capped-small.yaml 或 capped-large.yaml 中的默认值。默认值定义了 3 个“虚拟”区域并设置了亲和性规则，以确保不同区域的 alertmanager 不会混用，但允许同一区域的多个 alertmanager 在同一节点上运行
yaml
```
alertmanager:
  zoneAwareReplication:
    topologyKey: "kubernetes.io/hostname" # Triggers creating anti-affinity rules
```

地理冗余。在这种情况下，您需要设置合适的 nodeSelector 值来选择每个区域的 pod 放置位置。设置 topologyKey 将指示 Helm chart 创建反亲和性规则，以确保不同区域的 alertmanager 不会混用，但允许同一区域的多个 alertmanager 在同一节点上运行。例如

alertmanager:
  zoneAwareReplication:
    topologyKey: "kubernetes.io/hostname" # Triggers creating anti-affinity rules
    zones:
      - name: zone-a
        nodeSelector:
          topology.kubernetes.io/zone: us-central1-a
      - name: zone-b
        nodeSelector:
          topology.kubernetes.io/zone: us-central1-b
      - name: zone-c
        nodeSelector:
          topology.kubernetes.io/zone: us-central1-c

注意：由于 zones 是一个数组，您必须复制并修改它才能进行更改，无法仅覆盖数组的部分内容！

在您的自定义 values 文件（例如 custom.yaml）中设置选定的配置。

注意：将启动的 alertmanager Pod 数量来源于 alertmanager.replicas。每个区域将启动 alertmanager.replicas / 区域数量 个 pod，向上取整到最接近的整数值。例如，如果您有 3 个区域，则 alertmanager.replicas=3 将每个区域生成 1 个 alertmanager，但 alertmanager.replicas=4 将每个区域生成 2 个，总共 6 个。

迁移 Alertmanager

在开始此过程之前，请根据配置 Alertmanager 的区域感知复制设置您的区域。

创建一个新的空 YAML 文件，命名为 migrate.yaml。

开始迁移。

将以下内容复制到 migrate.yaml 文件中

alertmanager:
  zoneAwareReplication:
    enabled: true
    migration:
      enabled: true

rollout_operator:
  enabled: true

使用 helm 命令升级安装，并确保将标志 -f migrate.yaml 作为最后一个标志提供。
在此步骤中，使用默认区域启用区域感知功能，并为区域感知 alertmanager 创建新的 StatefulSet，但不会启动新的 pod。
等待所有 alertmanager 重启并准备就绪。

扩容区域感知 alertmanager。

将 migrate.yaml 文件内容替换为

alertmanager:
  zoneAwareReplication:
    enabled: true
    migration:
      enabled: true
      writePath: true

rollout_operator:
  enabled: true

使用 helm 命令升级安装，并确保将标志 -f migrate.yaml 作为最后一个标志提供。
等待所有新的区域感知 alertmanager 启动并准备就绪。
设置最终配置。
将以下 values 合并到您的自定义 Helm values 文件中
yaml
```
alertmanager:
  zoneAwareReplication:
    enabled: true

rollout_operator:
  enabled: true
```
使用常规命令行标志，通过 helm 命令升级安装。
确保非区域感知 alertmanager 的 Service 和 StatefulSet 资源已被删除。上一步也移除了旧的非区域感知 alertmanager 的 Service 和 StatefulSet manifest。在某些情况下，例如使用来自 Tanka 的 Helm 时，即使 Helm chart 不再渲染这些资源，它们也不会从您的 Kubernetes 集群中自动删除。如果旧资源仍然存在，请手动删除它们。如果不删除，在使用 Prometheus operator 进行元监控时，某些 pod 可能会被多次抓取。
等待旧的非区域感知 alertmanager 终止。

将 store-gateway 迁移到区域感知复制

配置 store-gateway 的区域感知复制

本节介绍如何规划和配置 store_gateway.zoneAwareReplication Helm value 下定义的可用区。

通常有两种用例

当副本数大于 3 时，加快 store-gateway 的 rollout 速度。在这种情况下，请使用 small.yaml、large.yaml、capped-small.yaml 或 capped-large.yaml 中的默认值。默认值定义了 3 个“虚拟”区域并设置了亲和性规则，以确保不同区域的 store-gateway 不会混用，但允许同一区域的多个 store-gateway 在同一节点上运行
yaml
```
store_gateway:
  zoneAwareReplication:
    enabled: false # Do not turn on zone-awareness without migration because of potential query errors
    topologyKey: "kubernetes.io/hostname" # Triggers creating anti-affinity rules
```

地理冗余。在这种情况下，您需要设置合适的 nodeSelector 值来选择每个区域的 pod 放置位置。设置 topologyKey 将指示 Helm chart 创建反亲和性规则，以确保不同区域的 store-gateway 不会混用，但允许同一区域的多个 store-gateway 在同一节点上运行。例如

store_gateway:
  zoneAwareReplication:
    enabled: false # Do not turn on zone-awareness without migration because of potential query errors
    topologyKey: "kubernetes.io/hostname" # Triggers creating anti-affinity rules
    zones:
      - name: zone-a
        nodeSelector:
          topology.kubernetes.io/zone: us-central1-a
      - name: zone-b
        nodeSelector:
          topology.kubernetes.io/zone: us-central1-b
      - name: zone-c
        nodeSelector:
          topology.kubernetes.io/zone: us-central1-c

注意：由于 zones 是一个数组，您必须复制并修改它才能进行更改，无法仅覆盖数组的部分内容！

在您的自定义 values 文件（例如 custom.yaml）中设置选定的配置。

注意：将启动的 store-gateway pod 数量来源于 store_gateway.replicas。每个区域将启动 store_gateway.replicas / 区域数量 个 pod，向上取整到最接近的整数值。例如，如果您有 3 个区域，则 store_gateway.replicas=3 将每个区域生成 1 个 store-gateway，但 store_gateway.replicas=4 将每个区域生成 2 个，总共 6 个。

决定 store-gateway 的迁移路径

有两种迁移方法

需要停机。在此过程中，旧的非区域感知 store-gateway 将停止，这将导致查询超过 12 小时（或设置的 querier.query_store_after Mimir 参数值）的数据失败。数据摄取不受影响。这是更快更简单的方法。
无需停机。这是一个多步骤过程，需要额外的硬件资源，因为新旧 store-gateway 会并行运行一段时间。

需要停机迁移 store-gateway

在开始此过程之前，请根据配置 store-gateway 的区域感知复制设置您的区域。

创建一个新的空 YAML 文件，命名为 migrate.yaml。
将当前 store-gateway 副本数缩减到 0。
将以下内容复制到 migrate.yaml 文件中
yaml
```
store_gateway:
  replicas: 0
  zoneAwareReplication:
    enabled: false
```
使用 helm 命令升级安装，并确保将标志 -f migrate.yaml 作为最后一个标志提供。
等待所有 store-gateway 终止。
设置最终配置。
将以下 values 合并到您的自定义 Helm values 文件中
yaml
```
store_gateway:
  zoneAwareReplication:
    enabled: true

rollout_operator:
  enabled: true
```
这些值实际上是默认值，这意味着移除 store_gateway.zoneAwareReplication.enabled 和 rollout_operator.enabled 这两个值也是有效的步骤。
使用常规命令行标志，通过 helm 命令升级安装。
确保非区域感知 store-gateway 的 Service 和 StatefulSet 资源已被删除。上一步也移除了旧的非区域感知 store-gateway 的 Service 和 StatefulSet manifest。在某些情况下，例如使用来自 Tanka 的 Helm 时，即使 Helm chart 不再渲染这些资源，它们也不会从您的 Kubernetes 集群中自动删除。如果旧资源仍然存在，请手动删除它们。如果不删除，在使用 Prometheus operator 进行元监控时，某些 pod 可能会被多次抓取。
等待所有 store-gateway 运行并准备就绪。

无需停机迁移 store-gateway

在开始此过程之前，请根据配置 store-gateway 的区域感知复制设置您的区域。

创建一个新的空 YAML 文件，命名为 migrate.yaml。

创建新的区域感知 store-gateway

将以下内容复制到 migrate.yaml 文件中

store_gateway:
  zoneAwareReplication:
    enabled: true
    migration:
      enabled: true

rollout_operator:
  enabled: true

使用 helm 命令升级安装，并确保将标志 -f migrate.yaml 作为最后一个标志提供。
等待所有新的 store-gateway 启动并准备就绪。

使读路径使用新的区域感知 store-gateway。

将 migrate.yaml 文件内容替换为

store_gateway:
  zoneAwareReplication:
    enabled: true
    migration:
      enabled: true
      readPath: true

rollout_operator:
  enabled: true

使用 helm 命令升级安装，并确保将标志 -f migrate.yaml 作为最后一个标志提供。
等待所有 querier 和 ruler 重启并准备就绪。
设置最终配置。
将以下 values 合并到您的自定义 Helm values 文件中
yaml
```
store_gateway:
  zoneAwareReplication:
    enabled: true

rollout_operator:
  enabled: true
```
这些值实际上是默认值，这意味着移除 store_gateway.zoneAwareReplication.enabled 和 rollout_operator.enabled 这两个值也是有效的步骤。
使用常规命令行标志，通过 helm 命令升级安装。
确保非区域感知 store-gateway 的 Service 和 StatefulSet 资源已被删除。上一步也移除了旧的非区域感知 store-gateway 的 Service 和 StatefulSet manifest。在某些情况下，例如使用来自 Tanka 的 Helm 时，即使 Helm chart 不再渲染这些资源，它们也不会从您的 Kubernetes 集群中自动删除。如果旧资源仍然存在，请手动删除它们。如果不删除，在使用 Prometheus operator 进行元监控时，某些 pod 可能会被多次抓取。
等待非区域感知 store-gateway 终止。

将 ingester 迁移到区域感知复制

配置 ingester 的区域感知复制

本节介绍如何规划和配置 ingester.zoneAwareReplication Helm value 下定义的可用区。

通常有两种用例

当副本数大于 3 时，加快 ingester 的 rollout 速度。在这种情况下，请使用 small.yaml、large.yaml、capped-small.yaml 或 capped-large.yaml 中的默认值。默认值定义了 3 个“虚拟”区域并设置了亲和性规则，以确保不同区域的 ingester 不会混用，但允许同一区域的多个 ingester 在同一节点上运行
yaml
```
ingester:
  zoneAwareReplication:
    enabled: false # Do not turn on zone-awareness without migration because of potential data loss
    topologyKey: "kubernetes.io/hostname" # Triggers creating anti-affinity rules
```

地理冗余。在这种情况下，您需要设置合适的 nodeSelector 值来选择每个区域的 pod 放置位置。设置 topologyKey 将指示 Helm chart 创建反亲和性规则，以确保不同区域的 ingester 不会混用，但允许同一区域的多个 ingester 在同一节点上运行。例如

ingester:
  zoneAwareReplication:
    enabled: false # Do not turn on zone-awareness without migration because of potential data loss
    topologyKey: "kubernetes.io/hostname" # Triggers creating anti-affinity rules
    zones:
      - name: zone-a
        nodeSelector:
          topology.kubernetes.io/zone: us-central1-a
      - name: zone-b
        nodeSelector:
          topology.kubernetes.io/zone: us-central1-b
      - name: zone-c
        nodeSelector:
          topology.kubernetes.io/zone: us-central1-c

注意：由于 zones 是一个数组，您必须复制并修改它才能进行更改，无法仅覆盖数组的部分内容！

在您的自定义 values 文件（例如 custom.yaml）中设置选定的配置。

注意：将启动的 ingester pod 数量来源于 ingester.replicas。每个区域将启动 ingester.replicas / 区域数量 个 pod，向上取整到最接近的整数值。例如，如果您有 3 个区域，则 ingester.replicas=3 将每个区域生成 1 个 ingester，但 ingester.replicas=4 将每个区域生成 2 个，总共 6 个。

决定 ingester 的迁移路径

有两种迁移方法

需要停机。在此过程中，当 ingester 迁移时，集群的 ingress 会停止。这是更快更简单的方法。执行此迁移所需的时间取决于 ingester 重启和将数据上传到对象存储的速度，但通常应在一小时内完成。
无需停机。这是一个多步骤过程，需要额外的硬件资源，因为新旧 ingester 会并行运行一段时间。这是一个复杂的迁移，可能需要数天，并且需要监控资源利用率的增加。执行此迁移所需的最短时间可以计算为 (querier.query_store_after) + (2小时 TSDB block 范围周期 + blocks_storage.tsdb.head_compaction_idle_timeout) * (1 + ingester 数量 / 21)。使用默认值时，这意味着 12 小时 + 3 小时 * (1 + ingester 数量 / 21) = 15 小时 + 3 小时 * (ingester 数量 / 21)。如果启用了 shuffle sharding，请额外增加 12 小时。

需要停机迁移 ingester

在开始此过程之前，请根据配置 ingester 的区域感知复制设置您的区域。

创建一个新的空 YAML 文件，命名为 migrate.yaml。

启用在 ingester 关闭时将数据刷新到存储。

将以下内容复制到 migrate.yaml 文件中

mimir:
  structuredConfig:
    blocks_storage:
      tsdb:
        flush_blocks_on_shutdown: true
    ingester:
      ring:
        unregister_on_shutdown: true

ingester:
  zoneAwareReplication:
    enabled: false

使用 helm 命令升级安装，并确保将标志 -f migrate.yaml 作为最后一个标志提供。
等待所有 ingester 重启并准备就绪。

关闭到该安装的流量。

将 migrate.yaml 文件内容替换为

mimir:
  structuredConfig:
    blocks_storage:
      tsdb:
        flush_blocks_on_shutdown: true
    ingester:
      ring:
        unregister_on_shutdown: true

ingester:
  zoneAwareReplication:
    enabled: false

nginx:
  replicas: 0
gateway:
  replicas: 0

使用 helm 命令升级安装，并确保将标志 -f migrate.yaml 作为最后一个标志提供。
等待直到没有 nginx 或 gateway 运行。

将当前 ingester 副本数缩减到 0。

将 migrate.yaml 文件内容替换为

mimir:
  structuredConfig:
    blocks_storage:
      tsdb:
        flush_blocks_on_shutdown: true
    ingester:
      ring:
        unregister_on_shutdown: true

ingester:
  replicas: 0
  zoneAwareReplication:
    enabled: false

nginx:
  replicas: 0
gateway:
  replicas: 0

使用 helm 命令升级安装，并确保将标志 -f migrate.yaml 作为最后一个标志提供。
等待直到没有 ingester 运行。

启动新的区域感知 ingester。

将 migrate.yaml 文件内容替换为

ingester:
  zoneAwareReplication:
    enabled: true

nginx:
  replicas: 0
gateway:
  replicas: 0

rollout_operator:
  enabled: true

使用 helm 命令升级安装，并确保将标志 -f migrate.yaml 作为最后一个标志提供。
等待所有请求的 ingester 运行并准备就绪。
启用到该安装的流量。
将以下 values 合并到您的自定义 Helm values 文件中
yaml
```
ingester:
  zoneAwareReplication:
    enabled: true

rollout_operator:
  enabled: true
```
这些值实际上是默认值，这意味着移除 ingester.zoneAwareReplication.enabled 和 rollout_operator.enabled 这两个值也是有效的步骤。
确保非区域感知 ingester 的 Service 和 StatefulSet 资源已被删除。上一步也移除了旧的非区域感知 ingester 的 Service 和 StatefulSet manifest。在某些情况下，例如使用来自 Tanka 的 Helm 时，即使 Helm chart 不再渲染这些资源，它们也不会从您的 Kubernetes 集群中自动删除。如果旧资源仍然存在，请手动删除它们。如果不删除，在使用 Prometheus operator 进行元监控时，某些 pod 可能会被多次抓取。
使用常规命令行标志，通过 helm 命令升级安装。

无需停机迁移 ingester

在开始此过程之前，请根据配置 ingester 的区域感知复制设置您的区域

将租户和 ingester 的时间序列限制加倍。
解释：当添加新的 ingester 时，一些时间序列将开始写入新的 ingester，但是这些时间序列也将存在于旧的 ingester 上，因此时间序列将对限制计数两次。不更新限制可能会导致由于违反限制而拒绝写入。
limits.max_global_series_per_user Mimir 配置参数的非零默认值为 150000。通过设置将其默认值或您的值加倍
yaml
```
mimir:
  structuredConfig:
    limits:
      max_global_series_per_user: 300000 # <-- or your value doubled
```
如果您已通过 mimir.config 或 mimir.structuredConfig 或运行时覆盖设置了 Mimir 配置参数 ingester.instance_limits.max_series，请在迁移期间将其加倍。
如果您已通过 mimir.config 或 mimir.structuredConfig 或运行时覆盖在 Mimir 配置参数 limits.max_global_series_per_user、limits.max_global_series_per_metric 中设置了每个租户的限制，请将设置的限制加倍。例如
yaml
```
runtimeConfig:
  ingester_limits:
    max_series: X # <-- double it
  overrides:
    tenantA:
      max_global_series_per_metric: Y # <-- double it
      max_global_series_per_user: Z # <-- double it
```
创建一个新的空 YAML 文件，命名为 migrate.yaml。

开始迁移。

将以下内容复制到 migrate.yaml 文件中

ingester:
  zoneAwareReplication:
    enabled: true
    migration:
      enabled: true
      replicas: 0

rollout_operator:
  enabled: true

使用 helm 命令升级安装，并确保将标志 -f migrate.yaml 作为最后一个标志提供。
在此步骤中，将创建新的区域感知 StatefulSet，但尚未启动新的 pod。参数 ingester.ring.zone_awareness_enabled: true 通过 mimir.config 值在 Mimir 配置中设置。标志 -ingester.ring.zone-awareness-enabled=false 在 distributor、ruler 和 querier 上设置。标志 -blocks-storage.tsdb.flush-blocks-on-shutdown 和 -ingester.ring.unregister-on-shutdown 对于 ingester 设置为 true。
等待所有 Mimir 组件重启并准备就绪。
添加区域感知 ingester 副本，每次最多 21 个。
解释：当添加新的 ingester 时，一些时间序列将开始写入新的 ingester，但是这些时间序列也将存在于旧的 ingester 上，因此时间序列将对限制计数两次。每次仅添加 21 个副本可以减少受影响的时间序列数量，从而降低超出最大时间序列限制的可能性。
1. 将 migrate.yaml 文件内容替换为
  yaml
```
ingester:
  zoneAwareReplication:
    enabled: true
    migration:
      enabled: true
      replicas: <N>

rollout_operator:
  enabled: true
```
  注意：在每个步骤中，将 <N> 替换为副本数量，直到 <N> 达到与 ingester.replicas 中相同的数量，并且每次增加 <N> 不超过 21。
2. 使用 helm 命令升级安装，并确保将标志 -f migrate.yaml 作为最后一个标志提供。
3. 新的 ingester 启动并准备就绪后，至少等待 3 小时。
  这 3 小时是根据 2 小时 TSDB block 范围周期 + blocks_storage.tsdb.head_compaction_idle_timeout Grafana Mimir 参数计算得出的，以便给 ingester 足够的时间从内存中移除过时的时间序列。由于时间序列在 ingester 之间移动，过时的时间序列将仍然存在。
4. 如果上面 ingester.zoneAwareReplication.migration.replicas 中的当前 <N> 小于 ingester.replicas，请返回并增加 <N>（最多增加 21），然后重复这四个步骤。
如果您正在使用shuffle sharding，此时必须在读路径上关闭它。
1. 使用这些值更新您的配置，并保持它们直到另行指示。
  yaml
```
querier:
  extraArgs:
    "querier.shuffle-sharding-ingesters-enabled": "false"
ruler:
  extraArgs:
    "querier.shuffle-sharding-ingesters-enabled": "false"
```
2. 使用 helm 命令升级安装，并确保将标志 -f migrate.yaml 作为最后一个标志提供。
3. 等待 querier 和 ruler 重启并准备就绪。
4. 监控 querier 和 ruler 的资源利用率，并在必要时进行扩容。关闭 shuffle sharding 可能会增加资源利用率。

在写路径上启用区域感知。

将 migrate.yaml 文件内容替换为

ingester:
  zoneAwareReplication:
    enabled: true
    migration:
      enabled: true
      writePath: true

rollout_operator:
  enabled: true

使用 helm 命令升级安装，并确保将标志 -f migrate.yaml 作为最后一个标志提供。
在此步骤中，标志 -ingester.ring.zone-awareness-enabled=false 将从 distributor 和 ruler 中移除。
所有 distributor 和 ruler 重启并准备就绪后，等待 12 小时。
这 12 小时是根据 querier.query_store_after Grafana Mimir 参数计算得出的。

在读路径上启用区域感知。

将 migrate.yaml 文件内容替换为

ingester:
  zoneAwareReplication:
    enabled: true
    migration:
      enabled: true
      writePath: true
      readPath: true

rollout_operator:
  enabled: true

使用 helm 命令升级安装，并确保将标志 -f migrate.yaml 作为最后一个标志提供。
在此步骤中，标志 -ingester.ring.zone-awareness-enabled=false 将从 querier 中移除。
等待所有 querier 重启并准备就绪。

从写路径中排除非区域感知 ingester。

将 migrate.yaml 文件内容替换为

ingester:
  zoneAwareReplication:
    enabled: true
    migration:
      enabled: true
      writePath: true
      readPath: true
      excludeDefaultZone: true

rollout_operator:
  enabled: true

使用 helm 命令升级安装，并确保将标志 -f migrate.yaml 作为最后一个标志提供。
在此步骤中，标志 -ingester.ring.excluded-zones=zone-default 将添加到 distributor 和 ruler 中。
等待所有 distributor 和 ruler 重启并准备就绪。

将非区域感知 ingester 副本数缩减到 0。

将 migrate.yaml 文件内容替换为

ingester:
  zoneAwareReplication:
    enabled: true
    migration:
      enabled: true
      writePath: true
      readPath: true
      excludeDefaultZone: true
      scaleDownDefaultZone: true

rollout_operator:
  enabled: true

使用 helm 命令升级安装，并确保将标志 -f migrate.yaml 作为最后一个标志提供。
等待所有非区域感知 ingester 终止。
删除默认区域。
将以下 values 合并到您的自定义 Helm values 文件中
yaml
```
ingester:
  zoneAwareReplication:
    enabled: true

rollout_operator:
  enabled: true
```
这些值实际上是默认值，这意味着从您的 custom.yaml 中移除 ingester.zoneAwareReplication.enabled 和 rollout_operator.enabled 这两个值也是有效的步骤。
使用常规命令行标志，通过 helm 命令升级安装。
确保非区域感知 ingester 的 Service 和 StatefulSet 资源已被删除。上一步也移除了旧的非区域感知 ingester 的 Service 和 StatefulSet manifest。在某些情况下，例如使用来自 Tanka 的 Helm 时，即使 Helm chart 不再渲染这些资源，它们也不会从您的 Kubernetes 集群中自动删除。如果旧资源仍然存在，请手动删除它们。如果不删除，在使用 Prometheus operator 进行元监控时，某些 pod 可能会被多次抓取。
至少等待 3 小时。
这 3 小时是根据 2 小时 TSDB block 范围周期 + blocks_storage.tsdb.head_compaction_idle_timeout Grafana Mimir 参数计算得出的，以便给 ingester 足够的时间从内存中移除过时的时间序列。由于时间序列在 ingester 之间移动，过时的时间序列将仍然存在。
如果您正在使用shuffle sharding
1. 额外等待 12 小时。
  这 12 小时是根据 querier.query_store_after Grafana Mimir 参数计算得出的。在此时间之后，没有时间序列会存储在其专用 shard 之外，这意味着可以安全地在读路径上启用 shuffle sharding。
2. 从您的配置中移除这些值
  yaml
```
querier:
  extraArgs:
    "querier.shuffle-sharding-ingesters-enabled": "false"
ruler:
  extraArgs:
    "querier.shuffle-sharding-ingesters-enabled": "false"
```
3. 使用常规命令行标志，通过 helm 命令升级安装。
4. 等待 querier 和 ruler 重启并准备就绪。
5. querier 和 ruler 的资源利用率应恢复到迁移前水平，您可以将其副本数缩减到之前的数量。
撤销第一步中将时间序列限制加倍的操作。
使用常规命令行标志，通过 helm 命令升级安装。

此页面是否有帮助？

发送邮件至 docs@grafana.com

帮助与支持

社区