Summary:

• Patch-level update with additive features. No breaking API changes detected for the Go API used here.
• New configuration options were added (optional), and defaults were updated for certain metrics labels. No code changes are required to adopt v2.7.8, though you may want to review telemetry label cardinality behavior (see notes).

Evidence and relevant changes:

• Documentation in this PR updates Beyla to v2.7.8 and exposes new options in Alloy’s beyla.ebpf component:
  • New Kubernetes metadata cache address:

    | `meta_cache_address` | `string` | Address of the Kubernetes metadata cache service. | "" | no |
    

  • New metrics label options:

    | `extra_resource_labels`      | `list(string)` | List of OTEL resource labels to include on `target_info`. | [] |
    | `extra_span_resource_labels` | `list(string)` | List of OTEL resource labels to include on span metrics.  | ["k8s.cluster.name", "k8s.namespace.name", "service.version", "deployment.environment"] |
    

• Alloy integration added the new fields and forwards them to Beyla:
  • Kubernetes meta cache address (optional):

    type KubernetesDecorator struct {
      ...

• MetaCacheAddress      string        `alloy:"meta_cache_address,attr,optional"`
  

  }

  ```diff
  if args.Kubernetes.MetaCacheAddress != "" {
    attrs.Kubernetes.MetaCacheAddress = args.Kubernetes.MetaCacheAddress
  }
  

  • Metrics resource label options (optional):

    type Metrics struct {
      ...

• ExtraResourceLabels             []string `alloy:"extra_resource_labels,attr,optional"`
  

• ExtraSpanResourceLabels         []string `alloy:"extra_span_resource_labels,attr,optional"`
  

  }

  ```diff
  if args.ExtraResourceLabels != nil {
    p.ExtraResourceLabels = args.ExtraResourceLabels
  }
  if args.ExtraSpanResourceLabels != nil {
    p.ExtraSpanResourceLabels = args.ExtraSpanResourceLabels
  }
  

Potential behavior consideration:

• Beyla 2.7.8 introduces default extra_span_resource_labels (k8s cluster/namespace, service.version, deployment.environment). If you want to maintain prior behavior (no extra span resource labels), explicitly set:

  metrics {

• new defaults include additional span resource labels

• extra_span_resource_labels = []
  }

Conclusion:
- No code changes are required to upgrade. Review configuration to ensure desired label cardinality, especially if downstream metrics storage/aggregation is sensitive to new labels.
</details>

<details>
<summary>go.opentelemetry.io/obi (replace) github.com/grafana/opentelemetry-ebpf-instrumentation v1.3.7 -> v1.3.10 — ⚠️ Needs Review</summary>

Summary:
- The underlying replacement of `go.opentelemetry.io/obi` to `github.com/grafana/opentelemetry-ebpf-instrumentation` was updated from v1.3.7 to v1.3.10.
- The updated library introduces/uses internal metrics that need a meter. To preserve previous behavior (no additional OTel metrics from the eBPF profiler), the code initializes the profiler’s metrics with a noop meter.

Observed code change required (already applied in this PR):
```diff
import (
 ...
+  ebpfmetrics "go.opentelemetry.io/ebpf-profiler/metrics"
+  metricnoop "go.opentelemetry.io/otel/metric/noop"
)

func init() {
 ...
-  // no explicit metrics initialization
+  // Disable ebpf profiler metrics to keep prior behavior
+  ebpfmetrics.Start(metricnoop.Meter{})
}

Why:

• Between v1.3.7 and v1.3.10, the profiler’s metrics package is started explicitly. Without a meter init, you may see unexpected OTel metric exports or risk inconsistent init depending on defaults. Using a noop meter keeps behavior aligned with previous versions in environments where these metrics were not desired.

Action:

• If you want to keep metrics disabled: keep the noop initialization (as in this PR).
• If you want to export profiler metrics: replace the noop meter with a real OTel MeterProvider.

Conclusion:

• Minor integration change is required to initialize or disable metrics. The PR’s new init is appropriate to maintain current behavior.