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 的仓库中找到。