Deploy Beyla with the Kubernetes Monitoring Helm chart

The Kubernetes Monitoring Helm chart deploys Beyla through its autoInstrumentation feature, alongside cluster monitoring. With Grafana Cloud, Beyla data powers Knowledge Graph and Application Observability. The chart deploys Beyla as a DaemonSet, together with a Beyla Kubernetes metadata cache. Grafana Alloy, which the chart also deploys, scrapes the Prometheus metrics from Beyla and sends them to your metrics destinations. If you enable the chart’s applicationObservability feature with an OTLP receiver, Beyla also sends traces to Alloy over OTLP by default, and Alloy sends them to your traces destinations.

To deploy Beyla on its own and send data directly to Grafana Cloud, refer to Deploy Beyla with the Beyla Helm chart for Grafana Cloud.

Before you begin

Before you deploy Beyla, make sure you have the following:

A Kubernetes cluster whose nodes meet the Beyla requirements and limitations
Helm and kubectl, configured for the cluster
Permission to create cluster-scoped resources and privileged Pods
An endpoint for metrics that accepts Prometheus remote write or OTLP, and an OTLP endpoint for traces, for example a Grafana Cloud stack with Kubernetes Monitoring activated. To activate Kubernetes Monitoring, follow the procedure in Activate and send data from your account.

With the default chart values, Beyla runs as a privileged DaemonSet in the host process ID (PID) and network namespaces of each node.

Deploy Beyla with Kubernetes Monitoring

To deploy Beyla, enable the autoInstrumentation feature in your Kubernetes Monitoring Helm chart values, then upgrade the chart:

If you haven’t installed the Kubernetes Monitoring Helm chart, install it. For Grafana Cloud, follow the procedure in Configuration steps for Kubernetes Monitoring with Helm chart or Configure Kubernetes Monitoring with a manual values file. For other backends, configure destinations as described in the chart’s destinations documentation.
If you don’t have a values.yaml file for the chart, save the current values:
sh
```
helm get values grafana-k8s-monitoring --namespace <NAMESPACE> --output yaml > values.yaml
```
Replace <NAMESPACE> with the namespace you installed the chart in. The commands on this page use the release name grafana-k8s-monitoring from the Grafana Cloud documentation. If you used a different release name, use that name instead. The file can contain credentials for your destinations, so store it securely.
Add the following to your values.yaml file:
YAML
```
autoInstrumentation:
  enabled: true
```

Upgrade the chart with your values file:

helm upgrade --install grafana-k8s-monitoring grafana/k8s-monitoring --namespace <NAMESPACE> --values values.yaml

Check that the Beyla and Beyla Kubernetes metadata cache Pods are running:
sh
```
kubectl get pods --namespace <NAMESPACE> --selector 'app.kubernetes.io/name in (beyla,beyla-k8s-cache)'
```
If a Pod isn’t running, check its logs with kubectl logs --namespace <NAMESPACE> <POD_NAME>, where <POD_NAME> is the Pod name from the previous command.

With this configuration, Beyla does the following:

Exposes Prometheus metrics, including span and service graph metrics, which the chart’s Alloy instance scrapes and sends to your metrics destinations
Sends traces to Alloy, if you enable applicationObservability with an OTLP receiver
Instruments applications in every namespace, except Alloy, OpenTelemetry Collector, and Beyla processes, Kubernetes system namespaces, and other namespaces that Beyla excludes by default

To receive traces, set applicationObservability.enabled to true and enable an OTLP receiver, for example applicationObservability.receivers.otlp.grpc.enabled. To turn traces off, set autoInstrumentation.beyla.deliverTracesToApplicationObservability to false.

Customize the Beyla configuration

To change which namespaces Beyla instruments, which Beyla version runs, or other Beyla options, add values under autoInstrumentation.beyla in your values.yaml file. Then run the helm upgrade --install command again.

For example:

autoInstrumentation:
  enabled: true
  beyla:
    image:
      tag: <BEYLA_VERSION>
    config:
      data:
        discovery:
          instrument:
            - k8s_namespace: alpha
            - k8s_namespace: bravo
            - k8s_namespace: delta

Replace <BEYLA_VERSION> with a Beyla release version. If you omit image.tag, the chart uses the Beyla version that it pins.

The example configures Beyla to do the following:

Instrument only three namespaces: alpha, bravo, and delta
Use the Beyla <BEYLA_VERSION> image instead of the version that the chart pins

Your instrument list replaces the chart’s default selection of every namespace. Unless you set exclude_instrument, the chart still excludes Alloy, Collector, and Beyla processes. Beyla also applies its default exclusions.

Settings the chart manages

The autoInstrumentation.beyla.config.data section contains a Beyla configuration file. For the available options, refer to Configure Beyla.

The chart sets the following keys, so values you set for them in config.data have no effect:

attributes.kubernetes.enable, always true
attributes.kubernetes.cluster_name, from cluster.name
internal_metrics.prometheus.port and prometheus_export.port, from autoInstrumentation.beyla.service.targetPort

To change the exported metric features, set prometheus_export.features. The chart sets prometheus_export.features, and Beyla gives that list precedence over metrics.features, so a metrics.features list has no effect.