Why Version 4 of the Grafana Helm Chart Matters Now
If you have managed Kubernetes monitoring for any length of time, you have probably felt the pain of configuration files that grow brittle as clusters multiply. Grafana Labs recognized this pattern across thousands of deployments and spent nearly six months rebuilding their Kubernetes Monitoring Helm chart from the ground up. The result, version 4, arrived in April 2026 and tackles three specific categories of failure that have plagued operators since the chart first appeared.
Pete Wall and Beverly Buchanan announced the release with a focus on real-world pain points rather than theoretical improvements. The chart now handles metrics, logs, traces, and profiles for clusters large and small. But the real story lies in how the team rethought the underlying data structures. These three essential fixes address the most common reasons why monitoring setups break as they scale.
Fix 1: Destinations Move from Fragile Lists to Stable Maps
The Problem with Position-Based Configuration
In version 3, destinations existed as a list of objects. This meant that when you wanted to override a single property, such as an authentication token for your Prometheus destination, you had to reference it by its numerical position in the list. The first destination was index 0, the second was index 1, and so on. This approach worked fine for a single cluster with a single configuration file.
But as teams grew to manage ten, twenty, or a hundred clusters, the list structure became a liability. GitOps tools like Argo CD, Flux, and Terraform rely on deterministic configuration merging. If one cluster needed a different password for the same destination, operators had to ensure the destination appeared at the exact same position in every values file. A single reordering would silently apply credentials to the wrong target, causing authentication failures that were difficult to trace.
Consider a scenario where you have three destinations: Prometheus, Loki, and Tempo. In version 3, your override for the Prometheus password looked something like destinations[0].auth.password. If another team member added a new destination before Prometheus, the index shifted, and your override now pointed at Loki instead. No error message appeared. Your metrics simply stopped flowing.
How Version 4 Solves the Index Problem
Version 4 converts destinations from a list to a map. Each destination now has a stable, human-readable name. Instead of destinations[0].auth.password, you write destinations.prometheus.auth.password. The name prometheus never changes, regardless of how many other destinations you add or remove.
This change has a profound effect on multi-cluster workflows. Helm’s built-in merge functionality works naturally with maps, so you can define a base configuration file with shared destination settings and then layer cluster-specific overrides on top. The password override for Prometheus always targets the correct destination, even if the order of destinations varies between environments.
The map structure also improves readability. When you open a values file in version 4, you see destinations.prometheus, destinations.loki, and destinations.tempo at a glance. There is no need to count array positions or cross-reference documentation to understand which destination is which. This single change reduces the cognitive load of managing monitoring configurations significantly.
Fix 2: Collectors Become Explicit Instead of Hidden
The Confusion of Hard-Coded Collector Names
Version 3 shipped with collector names baked into the chart’s internal code. You had alloy-metrics, alloy-logs, and alloy-singleton, each tied to a specific deployment type. The problem was that the routing logic that determined which feature ran on which collector lived inside the chart’s source code, not in the configuration files that operators could see and modify.
If you wanted to understand why your logs were being processed by a particular collector, you had to dig through the chart’s internal templates. This was not a task that most operators performed regularly. As a result, many teams lived with a black-box understanding of their monitoring pipeline. They knew that metrics appeared in Grafana, but they could not explain the exact path the data traveled to get there.
This hidden routing caused particular trouble during debugging. When metrics stopped arriving, operators had to guess which collector was responsible. The chart gave no clear indication of which feature was assigned to which collector. Troubleshooting became a process of elimination rather than a straightforward inspection.
Map-Based Collectors with Named Assignment
Version 4 removes all hard-coded collector names. You now define collectors as a map, giving each one a name that makes sense for your environment. You also assign one or more presets that describe the deployment shape, such as clustered, statefulset, or daemonset.
The critical improvement is that features are now explicitly assigned to a named collector. If you want your metrics feature to run on the collector you named primary-metrics, you write that assignment in your values file. There is no hidden routing logic. The chart no longer guesses where your data should go.
What happens if you forget to assign a feature? The chart prints a clear message telling you which feature still needs a collector assignment. It does not silently pick one for you, which was the behavior in version 3. This explicit approach eliminates the guesswork from collector configuration and makes your monitoring pipeline fully transparent.
For teams managing multiple clusters, this change is particularly valuable. You can define a standard set of collectors in a shared configuration file and then assign features differently per cluster. A development cluster might run all features on a single collector for simplicity, while a production cluster distributes features across multiple collectors for redundancy and performance.
Fix 3: Backing Services and Features Are Finally Separated
The Surprise Deployment Problem
In version 3, enabling a feature often triggered silent deployments of backing services. When you turned on clusterMetrics, the chart automatically deployed Node Exporter, kube-state-metrics, and OpenCost behind the scenes. This behavior seemed convenient at first, but it caused serious problems for teams that already ran these services in their clusters.
Duplicate deployments appeared without warning. You might have had Node Exporter running as part of your base monitoring stack, and then the Grafana chart deployed another instance. The two instances competed for resources, sometimes causing data duplication or collection failures. Identifying the source of the duplicate required careful inspection of running pods and their labels.
The problem was especially acute in organizations with multiple teams. One team might deploy Node Exporter as part of a cluster-wide monitoring initiative, while another team enabled clusterMetrics in their Grafana chart without knowing about the existing deployment. The result was confusion, wasted resources, and monitoring gaps that took hours to resolve.
Explicit Telemetry Services Control
Version 4 introduces a telemetryServices key that makes service deployment an explicit choice. When you enable a feature that requires a backing service, the chart does not deploy anything automatically. Instead, you must decide whether you want the chart to deploy the service or point to an existing instance.
If your cluster already runs Node Exporter, you instruct the chart to skip deployment and provide the endpoint of your existing instance. The chart connects to that instance and collects the data it needs. No duplicate deployments, no resource waste, no confusion.
If your cluster does not have the backing service, you tell the chart to deploy it. The chart handles the deployment exactly as it did in version 3, but now the action is explicit rather than hidden. You see the deployment happening and understand why.
Wall and Buchanan described this change as eliminating surprise deployments. The phrase captures the frustration that many operators felt when they discovered unexpected pods running in their clusters. Version 4 puts control back in the hands of the operator, making every deployment a conscious decision.
You may also enjoy reading: One Tool Call to Rule Them All: Speed Up AI Dev with Runpod.
Additional Refinements That Reduce Operational Overhead
Cluster Metrics Split into Three Focused Features
Version 3’s clusterMetrics feature was a monolith. It covered Kubernetes cluster metrics, Linux and Windows host metrics, energy metrics via Kepler, and cost metrics via OpenCost, all within a single configuration block. This bundling made sense for simplicity, but it forced operators to wade through options that were irrelevant to their specific needs.
Version 4 splits this monolith into three separate features: clusterMetrics, hostMetrics, and costMetrics. Each feature has its own values file and only exposes options relevant to its concern. If you only need host metrics, you enable hostMetrics and ignore the other two. The configuration file stays small and focused.
This split also makes it easier to apply different configurations to different clusters. A cluster running on bare metal might need host metrics and cost metrics, while a cluster running on virtual machines might only need cluster metrics. You enable exactly what you need, nothing more.
Label Filtering Memory Problems Solved
One of the more subtle but painful issues in version 3 involved log labels. The chart applied all pod labels and annotations as log labels by default, then used a labelsToKeep filter to decide which ones to retain. This approach consumed significant memory because the chart processed every label before filtering.
In clusters with many pods and rich labeling schemes, the memory overhead became substantial. Operators reported pods running out of memory during label processing, causing collection failures that were difficult to diagnose. The labelsToKeep filter worked, but it worked inefficiently.
Version 4 removes the labelsToKeep approach entirely. Instead, you explicitly declare which labels you want to promote to log labels. Adding a label is now a one-line change in your values file. The chart only processes the labels you specify, eliminating the memory overhead of processing every label on every pod.
This change has a direct impact on cluster resource utilization. For clusters with thousands of pods and dozens of labels each, the memory savings can be significant. Operators no longer need to worry about label processing consuming resources that should go to actual monitoring work.
Practical Migration Steps for Version 4
Audit Your Current Configuration
Before migrating, take inventory of your version 3 values files. Identify every destination reference that uses positional indexing, every collector name that matches the old hard-coded pattern, and every feature that relies on automatic backing service deployment. Document these patterns so you know exactly what needs to change.
Pay special attention to any GitOps workflows that reference destinations by index. These will break silently if you migrate without updating the references. The map-based structure in version 4 makes these workflows more reliable, but only if you update the references first.
Map Your Destinations First
Start the migration by converting your destinations from list format to map format. Give each destination a stable name that reflects its purpose. For example, prometheus-prod, loki-prod, and tempo-dev are clear and descriptive names. Once the destinations are mapped, update all downstream references to use the named format.
Define Your Collectors Explicitly
Next, define your collectors as a map. Give each collector a name and assign the appropriate presets. Then assign each feature to a collector explicitly. This step requires you to understand your monitoring pipeline in detail, which is a good thing. You will emerge with a configuration that you fully understand and can explain to others.
Handle Backing Services Deliberately
Finally, review each feature that requires a backing service. Decide whether you want the chart to deploy the service or connect to an existing instance. Update your values file with the appropriate telemetryServices configuration. This step ensures that your cluster runs exactly the services you intend, with no surprises.
Why This Update Represents a New Baseline for Kubernetes Monitoring
The three essential fixes in version 4 address the most common failure modes that operators encounter when scaling Kubernetes monitoring. Destinations that break when order changes, collectors that hide their routing logic, and backing services that appear without warning are not edge cases. They are the daily reality for teams managing multiple clusters.
By converting lists to maps, making collectors explicit, and separating services from features, Grafana Labs has created a chart that behaves predictably at any scale. The configuration files are more readable, the deployment logic is transparent, and the resource usage is more efficient. These improvements do not require new tools or workflows. They simply make the existing Helm-based approach work better.
For teams that have struggled with brittle configurations and surprise deployments, version 4 offers a clear path forward. The migration requires some upfront work, but the result is a monitoring setup that you can trust to work correctly across one cluster or a hundred.
