菜单
文档breadcrumb arrow Grafana Lokibreadcrumb arrow 设置breadcrumb arrow 迁移breadcrumb arrow loki-distributed 迁移
开源

loki-distributed Helm chart 迁移

本指南将引导您从 loki-distributed Helm Chart(编写本文时为 v0.63.2)迁移到 loki Helm Chart(v3.0 或更高版本)。该过程包括将新的 loki Helm Chart 与现有的 loki-distributed 安装一起部署。通过将新集群加入现有集群的环,您将创建一个大型集群。这将允许您安全地手动关闭 loki-distributed 组件,以避免任何数据丢失。

开始之前

我们建议准备一个 Grafana 实例来监控现有集群和新集群,以确保在迁移过程中没有数据丢失。loki chart 附带了自监控功能,包括仪表盘。这些对于监控新集群启动时的健康状况非常有用。

首先更新您现有的 Grafana Agent 或 Promtail 配置(用于抓取您环境中日志的任何配置),以便排除新的部署。新的 loki chart 附带了自己的自监控机制,我们希望确保它不会被抓取两次,从而产生重复日志。最好的方法是使用 relabel 配置来丢弃来自新部署的日志,例如像这样:

yaml
- source_labels:
    - "__meta_kubernetes_pod_label_app_kubernetes_io_component"
  regex: "(canary|read|write)"
  action: "drop"

这利用了新部署会为 Read pods 添加 app.kubernetes.io/component 标签(值为 read),为 Write pods 添加 write 标签,以及为 Loki Canary pods 添加 canary 标签这一事实。这些注释不存在于 loki-distributed 部署中,因此这将只匹配来自新部署的日志。

loki-distributed 迁移到 loki

  1. 部署新的 Loki 集群

    接下来,您将在与现有 loki-distributed 安装相同的命名空间中部署新的 loki chart。确保使用与现有安装相同的存储桶和存储配置。您还需要设置一些特殊的 migrate 值:

    yaml
    migrate:
      fromDistributed:
        enabled: true
        memberlistService: loki-loki-distributed-memberlist

    memberlistService 的值必须是为 loki-distributed 部署中的 Memberlist DNS 目的而创建的 kubernetes 服务。它应该与 loki-distributed 部署配置中 memberlist.join_members 的值匹配。这就是使新集群加入现有集群环的原因。重要的是要加入所有现有的环,如果您对不同的环使用不同的 memberlist DNS,则必须手动为每个适用的环设置每个 join_members 配置的值。如果对所有环使用相同的 memberlist DNS(如 loki-distributed chart 中的默认设置),设置 migrate.memberlistService 应该就足够了。

    新集群启动后,在 Grafana 中为新集群添加相应的数据源。检查以下查询是否返回结果:

    • 确认新旧日志都在新的部署中。在 Grafana 中使用新部署的 Loki 数据源,查找:
      • 具有现有 Promtail 或 Grafana Agent 独有 job 的日志,即我们上面调整过的,用于排除尚未向新部署推送日志的新部署的日志。如果您可以通过新部署查询到这些日志,则表明我们没有丢失历史日志。
      • 带有标签 job="loki/loki-read" 的日志。loki-distributed 中不存在 read 组件,因此这表明新的 Loki 集群自监控工作正常。
    • 确认新日志都在旧部署中。在 Grafana 中使用旧部署的 Loki 数据源,查找:
      • 带有标签 job="loki/loki-read" 的日志。由于您已将来自新部署的日志排除在 loki-distributed 部署之外,如果您可以通过 loki-distributed Loki 数据源查询到它们,则表明 ingester 已加入同一环,并且可以从 loki-distributed querier 查询。
  2. 将所有客户端转换为向新的 loki 部署推送日志

    假设一切按预期工作,您现在可以修改 Grafana Agent 或 Promtail 配置的 clients 部分,以将日志推送到新的部署。进行此更改后,loki-distributed 集群将不再接收新日志,并且可以小心地缩容。

    部署此更改后,查询新的 loki 集群的 Loki 数据源以确保新日志仍然在被采集。

  3. 拆除旧的 Loki Canary

    如果您之前通过 loki-canary Helm Chart 部署了 canary,您现在可以将其拆除。新 chart 默认包含 canary 并自动配置为抓取它。

  4. 更新 loki-distributed 部署上的 Flush 配置

    您几乎准备好开始缩容旧的 loki-distributed 集群了。但是,在开始之前,重要的是要确保 loki-distributed ingester 配置为在关闭时进行 flush。由于这些 ingester 将不会重新启动,因此它们没有机会重放其 WAL,因此它们需要在关闭前 flush 所有内存中的日志以防止数据丢失。

    最简单的方法是通过 loki-distributed chart 的 ingester 部分中的 extraArgs 参数来实现。您可能还想将 ingester 的日志级别设置为 debug,以便查看有关 flush 过程的消息。

    yaml
    ingester:
      replicas: 3
      extraArgs:
        - '-ingester.flush-on-shutdown=true'
        - '-log.level=debug'
        ```
    
    Deploy this change, and make sure all ingesters restart and are running the latest configuration.
  5. 每次缩容一个 Ingester

    现在是时候开始缩容 loki-distributed 了。每次缩容 ingester StatefulSet 或 Deployment(取决于您的 loki-distributed chart 如何部署)1个副本。如果启用了 debug 日志,您可以在 ingester 终止时监控其日志,以确保 flush 过程成功。一旦 ingester pod 完全终止,继续减少 1 个副本。重复此过程,直到 ingester 的运行实例数为 0。

    您可以使用以下命令编辑 ingester StatefulSet 以更改副本数(确保将 <NAMESPACE> 替换为正确的命名空间):

    bash
    kubectl -n <NAMESPACE> edit statefulsets.apps loki-distributed-ingester
  6. 移除 loki-distributed 集群

    再次检查日志是否仍然进入新集群。如果出现问题,在拆除整个集群之前快速扩容 loki-distributed ingester 会更容易进行排查。如果一切正常,您可以使用 helm uninstall 拆除 loki-distributed。例如:

    bash
    helm uninstall -n loki loki-distributed

    现在编辑新的 loki 集群,移除首次安装时添加的 migrate 选项。从您的 values.yaml 中移除以下所有内容:

    yaml
    migrate:
      fromDistributed:
        enabled: true
        memberlistService: loki-loki-distributed-memberlist

    应用新配置(假设您将新 chart 安装为 lokiloki 命名空间中):

    bash
    helm upgrade -n loki loki grafana/loki --values values.yaml

    migrate.fromDistributed.memberlistService 是作为一个额外的 memberlist join member 添加的,因此一旦推送了新配置,组件应该可以无中断地滚动更新。

  7. 检查仪表盘

    迁移完成后,您可以检查新的 loki chart 中包含的仪表盘,确保一切正常运行。您还可以检查 loki canary 的指标,以确保迁移过程中没有数据丢失。假设所有内容都在 loki 命名空间中,如果在迁移开始前到迁移完成后运行以下查询,应该可以清楚地显示何时指标开始来自新的 canary,以及在过程中是否有数据被任何一个检测到:

    logql
    (
      sum(increase(loki_canary_missing_entries_total{namespace="loki"}[$__range])) by (job)
      /
      sum(increase(loki_canary_entries_total{namespace="loki"}[$__range])) by (job)
    )*100