OpenTelemetry eBPF Instrumentation v0.15.2 - BPF loading and Collector upgrades
OpenTelemetry eBPF Instrumentation v0.15.2, published on October 16, 2026, restores BPF program loading after verifier failures blocked v0.15.0. It also fixes artifact version selection after the v0.15.1 build failed. Collector users and embedders should review the module and configuration changes alongside those fixes.
The full release notes and downloads are on the GitHub release page.
BPF loading and release artifacts
The BPF loading correction addresses verifier loop widening. It preserves socket copy bounds, bounds packet hex writes, and separates HTTP/1 traceparent scanning from decoding. Capture limits and trace context propagation behavior stay the same.
The separate artifact correction makes release packaging consistently use the selected core tag. Previously, git describe could select a Collector tag when both tags shared a commit. That broke the v0.15.1 artifact build. Binary archives, generated source archives, Java SBOMs, and checksums now use the intended core version. This explains why v0.15.2 supersedes two unpublished releases.
Collector receiver gets a separate module
The receiver now ships in go.opentelemetry.io/obi/collector, tagged collector/v0.15.2. Its import path stays the same, but the root module no longer contains the receiver package. The nested module requires root v0.15.2 and has an independent v0 release line.
For custom Collector builds, check module dependencies even if source imports need no edits. The release notes call for both v0.15.2 and collector/v0.15.2; release candidate tags alone do not support discovery through plain go get -u. The release also updates the receiver dependency, OATS module references, and Collector Builder example to match.
Upgrade notes
Config v2 now applies a protocol’s enabled.metrics: false setting to both its span metrics and service graphs in both exporters. If that setting is already present, check whether dashboards depend on data it now suppresses. The migration CLI reports coverage it cannot preserve, while Config v1 behavior stays unchanged.
Embedders also need to account for the removal of PrometheusConfig.Registry. Code that supplied a registry must configure a Prometheus HTTP port instead. For a custom Collector build that also supplies this field, the module split and registry removal belong in the same upgrade review. Both affect the integration even though the receiver import path stays the same.