从 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 配置来丢弃来自新部署的日志,例如像这样:
- 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
部署新的 Loki 集群
接下来,您将在与现有
loki-distributed
安装相同的命名空间中部署新的loki
chart。确保使用与现有安装相同的存储桶和存储配置。您还需要设置一些特殊的migrate
值: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 查询。
- 带有标签
- 确认新旧日志都在新的部署中。在 Grafana 中使用新部署的 Loki 数据源,查找:
将所有客户端转换为向新的
loki
部署推送日志假设一切按预期工作,您现在可以修改 Grafana Agent 或 Promtail 配置的
clients
部分,以将日志推送到新的部署。进行此更改后,loki-distributed
集群将不再接收新日志,并且可以小心地缩容。部署此更改后,查询新的
loki
集群的 Loki 数据源以确保新日志仍然在被采集。拆除旧的 Loki Canary
如果您之前通过
loki-canary
Helm Chart 部署了 canary,您现在可以将其拆除。新 chart 默认包含 canary 并自动配置为抓取它。更新
loki-distributed
部署上的 Flush 配置您几乎准备好开始缩容旧的
loki-distributed
集群了。但是,在开始之前,重要的是要确保loki-distributed
ingester 配置为在关闭时进行 flush。由于这些 ingester 将不会重新启动,因此它们没有机会重放其 WAL,因此它们需要在关闭前 flush 所有内存中的日志以防止数据丢失。最简单的方法是通过
loki-distributed
chart 的ingester
部分中的extraArgs
参数来实现。您可能还想将 ingester 的日志级别设置为debug
,以便查看有关 flush 过程的消息。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.
每次缩容一个 Ingester
现在是时候开始缩容
loki-distributed
了。每次缩容 ingester StatefulSet 或 Deployment(取决于您的loki-distributed
chart 如何部署)1个副本。如果启用了debug
日志,您可以在 ingester 终止时监控其日志,以确保 flush 过程成功。一旦 ingester pod 完全终止,继续减少 1 个副本。重复此过程,直到 ingester 的运行实例数为 0。您可以使用以下命令编辑 ingester StatefulSet 以更改副本数(确保将 <NAMESPACE> 替换为正确的命名空间):
kubectl -n <NAMESPACE> edit statefulsets.apps loki-distributed-ingester
移除
loki-distributed
集群再次检查日志是否仍然进入新集群。如果出现问题,在拆除整个集群之前快速扩容
loki-distributed
ingester 会更容易进行排查。如果一切正常,您可以使用helm uninstall
拆除loki-distributed
。例如:helm uninstall -n loki loki-distributed
现在编辑新的
loki
集群,移除首次安装时添加的migrate
选项。从您的values.yaml
中移除以下所有内容:migrate: fromDistributed: enabled: true memberlistService: loki-loki-distributed-memberlist
应用新配置(假设您将新 chart 安装为
loki
到 loki 命名空间中):helm upgrade -n loki loki grafana/loki --values values.yaml
migrate.fromDistributed.memberlistService
是作为一个额外的 memberlist join member 添加的,因此一旦推送了新配置,组件应该可以无中断地滚动更新。检查仪表盘
迁移完成后,您可以检查新的
loki
chart 中包含的仪表盘,确保一切正常运行。您还可以检查 loki canary 的指标,以确保迁移过程中没有数据丢失。假设所有内容都在loki
命名空间中,如果在迁移开始前到迁移完成后运行以下查询,应该可以清楚地显示何时指标开始来自新的 canary,以及在过程中是否有数据被任何一个检测到:( sum(increase(loki_canary_missing_entries_total{namespace="loki"}[$__range])) by (job) / sum(increase(loki_canary_entries_total{namespace="loki"}[$__range])) by (job) )*100