Grafana的Kubernetes监控Helm Chart v4版本修复了问题

Grafana Labs 发布了第4版的 "Kubernetes Monitoring Helm Chart，称这是自该Chart推出以来最重要的更新。Pete Wall和Beverly Buchanan在2026年4月宣布了此次发布，目标是修复随着用户扩展到更大、更复杂部署时暴露的一系列配置问题。 该Kubernetes Monitoring Helm Chart提供了一种机制，用于将Kubernetes集群的指标、日志、追踪和profile发送到Grafana Cloud或自托管的Grafana技术栈。Wall和Buchanan表示，v4代表了近六个月的规划与开发，旨在解决用户在监控系统扩展过程中遇到的实际痛点。作者写道，该Chart现在“更可预测、更灵活、也更易维护，无论你管理一个集群还是一百个”。 “经过近六个月的规划与开发，它旨在解决随着监控系统增长用户遇到的实际痛点。”- Pete Wall和Beverly Buchanan 一个具有重要意义的结构性变更是把destinations从列表改为map。在v3中，destinations定义为对象列表。这给使用共享配置文件管理多集群的团队以及使用Argo CD、Terraform或Flux等GitOps工具的团队带来了问题。覆盖单个属性（比如密码）需要按列表中的位置引用目标，如果目标顺序发生变化，这些覆盖将无声地作用到错误的目标上。在v4中，每个destination都有了稳定的名称，因此destinations.prometheus.auth.password无论排序如何都始终指向Prometheus目标。Helm跨文件合并基于map的配置能力也使多集群GitOps工作流更可靠。 Collectors也经历了类似的重构。v3带有硬编码的collector名称，如alloy-metrics、alloy-logs和alloy-singleton，每个名称与特定的部署类型绑定。功能到collector的路由被埋在Chart的内部代码中，这意味着要弄清某个功能运行在哪个collector上需要阅读源码而非配置文件。v4完全移除了这些硬编码名称。用户现在以map的形式定义collectors，并为其分配一个或多个描述部署形态的preset，如clustered、statefulset或daemonset。然后把功能显式分配给命名的collector，从而移除了Chart内部的隐藏路由逻辑。 “如果你忘记指定，它会给出一条消息，告诉你哪些功能仍需分配到collector，而不是为你悄悄选择一个。”- Pete Wall和Beverly Buchanan 此次发布还把后端服务的部署与消费其数据的功能进行了分离。在v3中，启用像clusterMetrics这样的功能会在后台无声地部署Node Exporter、kube-state-metrics和OpenCost等服务。这给已经运行这些服务的团队带来了问题，因为会出现未预期的重复部署。v4引入了telemetryServices键，将服务部署变为显式步骤。已经运行Node Exporter的团队可以指示Chart跳过部署并把功能指向现有实例。正如Wall和Buchanan所说，这意味着“不再有意外部署”。 集群指标的处理被重新组织为三个独立的功能。v3中的clusterMetrics功能在单一配置块中涵盖了Kubernetes集群指标、Linux和Windows主机指标、通过Kepler提供的能源指标以及通过OpenCost提供的成本指标。v4将这些拆分为clusterMetrics、hostMetrics和costMetrics，每个都有自己的values文件。每个功能的配置只暴露与其关注点相关的选项。 另一项变更则解决了pod日志流水线的内存使用问题。在v3中，Chart把所有Kubernetes pod标签和注释作为日志标签应用，然后使用labelsToKeep列表进行过滤。这要求Alloy为可能的数百个标签分配内存，随后丢弃大多数标签。一些用户报告他们的日志收集Alloy实例出现的内存问题可直接追溯到这一行为。v4完全移除了labelsToKeep，pod标签和注释不再批量应用。取而代之的是，用户显式声明希望提升的标签。根据 Grafana文档 "，添加标签现在是按行进行更改，而不是重定义默认列表。 Grafana Kubernetes Monitoring Helm Chart并非唯一的集群级监控方案。由prometheus-community维护的 kube-prometheus-stack "将Prometheus、Grafana、Alertmanager、Node Exporter、kube-state-metrics和Prometheus Operator打包为一次Helm安装。该Chart使用Prometheus Operator的自定义资源（比如，ServiceMonitors和PrometheusRules）提供声明式的抓取配置，是那些构建独立于Grafana Cloud的自托管可观测性技术栈团队的常见选择。相比之下，Grafana的Chart面向将遥测发送到Grafana Cloud或托管Grafana技术栈的团队，并开箱即支持profile和成本指标。两者服务于相关但不同的用例。 Grafana Labs提供了一个 迁移工具 "，接受v3的values文件并生成兼容v4的输出。该工具处理结构性转换，包括将列表转换为map和拆分重载的功能。Grafana文档和仓库中的所有Chart示例都已更新为v4格式。 该发布在Kubernetes社区引发了讨论。 Kubesimplify在LinkedIn上写道 "，“v3中几乎所有脆弱的模式都被替换了”，特别指出从列表到map的转换以及pod日志标签的按需选择是最能带来实际好处的改动。Kubesimplify还指出，Alloy内存减少是标签变更的“直接结果”。 关于生产环境中监控Kubernetes的背景，InfoQ在2025年3月发布了一份由Ran Isenberg和Elad Beber编写的清单，涵盖了SRE团队的可观测性实践，其中包括在集群环境中使用Prometheus和Grafana的指导，参见 相关文章 "。 大量的 示例 "也可以在Kubernetes Monitoring Helm Chart的 仓库 "中找到。