Update to Beyla 2.7.10

[rafaelroquetto]

PR Description

Update Alloy to latest Beyla 2.7

Which issue(s) this PR fixes

[github-actions]

🔍 Dependency Review

Below are the reviewed dependency updates detected in go.mod. Each section summarizes potential impact, links to upstream references, and any code changes you may need to consider.

Scope: Only dependencies changed in go.mod/go.sum are assessed. No assumptions are made beyond what can be inferred from versioning and publicly documented surfaces. Patch releases typically avoid breaking changes, but please verify against your code paths.

---

github.com/grafana/beyla/v2 v2.7.8 -> v2.7.10 — ⚠️ Needs Review

Reasoning:

• Patch-level update (v2.7.x). By SemVer, breaking API changes are not expected; however, Beyla often evolves telemetry attributes and defaults that can affect downstream processing even without API breaks.
• If your project imports Beyla packages (not just using the binary), any subtle behavior changes (e.g., configuration parsing, default detectors, attribute sets) can affect runtime behavior.

What to check:

• Changelog between v2.7.8 and v2.7.10 for:
  • Changes to exported telemetry attribute names/values (HTTP, gRPC, DB, messaging) that your code assumes in tests, processors, or dashboards.
  • Any deprecations or changes in configuration structs in public packages (e.g., config types, option functions).
  • Any changes in default settings (sampling, discovery, protocol detectors) that could alter produced telemetry volume or shape.

Suggested verification:

• Compile and run unit tests focusing on:
  • Code paths that parse or depend on Beyla-generated telemetry.
  • Any usage of Beyla’s public config types and option functions.
• Run a short integration test to validate emitted span/metric labels still match expectations.

Code changes likely required:

• None identified at the API level for a patch bump. If you key on specific attribute names in your code, verify and adjust selectors accordingly.

Example selector resilience (if you rely on attribute strings; prefer semconv constants where possible):

- // Before (string literal usage risks breakage)
- if attrs["http.scheme"] == "https" { ... }

+ // After (use semconv constants to avoid drift)
+ scheme, _ := attrs[semconv.HTTPSchemeKey]
+ if string(scheme.AsString()) == "https" { ... }

References:

• Releases/Changelog: https://github.com/grafana/beyla/releases (review 2.7.9 and 2.7.10)

---

replace go.opentelemetry.io/obi => github.com/grafana/opentelemetry-ebpf-instrumentation v1.3.10 -> v1.3.13 — ⚠️ Needs Review

Reasoning:

• This is a replace update affecting all imports of go.opentelemetry.io/obi. Even as a patch update, eBPF instrumentation layers can tweak event schemas or defaults.
• If your code imports go.opentelemetry.io/obi packages (types, event models, loaders/options), confirm no API drift or behavior changes.

What to check:

• Changelog between v1.3.10 and v1.3.13 for:
  • Struct field additions/renames in any exported event or config types you use.
  • Option function changes (e.g., WithXxx/EnableXxx) and their defaults.
  • Telemetry attribute or semantic conventions alignment changes (e.g., HTTP/gRPC attributes).

Suggested verification:

• Rebuild and run tests for any code handling OBI events.
• Validate span/metric attribute expectations in tests (especially if you assert on attribute presence/values).

Code changes likely required:

• None typically for a patch release; make defensive reads of optional/added fields if you unmarshal events.

Example defensive parsing (if consuming JSON events from OBI):

- type HTTPEvent struct {
-   Method string `json:"method"`
-   // ...
- }

+ type HTTPEvent struct {
+   Method string  `json:"method"`
+   // Tolerate newly added fields without failing strict decoders
+   // json.Decoder with DisallowUnknownFields() should be avoided or gated:
+ }

References:

• Releases/Changelog: https://github.com/grafana/opentelemetry-ebpf-instrumentation/releases (review 1.3.11–1.3.13)

Notes

• No new direct dependencies were introduced; only version bumps and a replace update were changed.
• Because both updates are patch-level, compile-time API breaks are unlikely, but behavior-level changes (telemetry attributes, defaults) can still affect your downstream processing. Run integration tests that validate emitted telemetry shape.