OTEP: Autoinstrumentation system packages for DEB- and RPM-based Linux distributions by mmanciop · Pull Request #4793 · open-telemetry/opentelemetry-specification

mmanciop · 2025-12-10T05:49:22Z

Changes

Add OTEP for system packages that deliver autoinstrumentations and the OTel Injector on Debian- and RedHat-based Linux distros.

CHANGELOG.md file updated for non-trivial changes
Spec compliance matrix updated if necessary

…ategory

atoulme

LGTM

mtwo

@mmanciop thanks for writing this! One thing that I'd like to see is a plan that combines or rationalizes the injector's automatic discovery capabilities with the eBPF work going on in OBI. Have we put much thought into this yet?

@atoulme FYI

mtwo · 2025-12-15T21:03:50Z

+
+## Prior art and alternatives
+
+The [Dash0 Operator](https://github.com/dash0hq/dash0-operator) has been using very similar mechanics (delivering an injector and autoinstrumentation files for various SDKs) on Kubernetes in production for more than year. The [OpenTelemetry Operator](https://github.com/open-telemetry/opentelemetry-operator/) also has injection mechanics processed runtime inside pods' containers, but the injection requires opt-in at the pod level via labels.


@atoulme might be worth adding the Splunk automatic configuration + discovery work here

svrnm · 2025-12-16T11:31:42Z

Since this is a spec proposal, I am wondering if it would be possible to extend the "system packages for DEB- and RPM-based linux distributions" to APIs and SDKs, that would profit from that, as well. Mainly C++, but others maybe as well? And for those who this is not relevant/applicable because they have an eco-system for their SDK/API installation (nuget, npmjs, ...) this could be called out as "out of scope"

Co-authored-by: jackshirazi <[email protected]>

mmanciop · 2025-12-17T06:00:16Z

Since this is a spec proposal, I am wondering if it would be possible to extend the "system packages for DEB- and RPM-based linux distributions" to APIs and SDKs, that would profit from that, as well. Mainly C++, but others maybe as well? And for those who this is not relevant/applicable because they have an eco-system for their SDK/API installation (nuget, npmjs, ...) this could be called out as "out of scope"

I do not think that packaging SDKs and APIs as system packages for the languages listed in this proposal helps adoption. The language-specific packages do that work well. Distros may end up packaging OTel SDKs in the (IMO very unlikely) possibility that they become shared dependencies of other packages in main repositories (this is how Ubuntu ended up with a few DEB for Java and Node.js libraries).

C++ is a completely different beast entirely. C++ build systems are a fair bit outside my zone of comfort, but what I see is that, to this day, there's surprisingly little commonality among build setups for C++ projects, and several competing standards for C++ dependency package formats.

mmanciop · 2025-12-17T06:08:21Z

@mmanciop thanks for writing this! One thing that I'd like to see is a plan that combines or rationalizes the injector's automatic discovery capabilities with the eBPF work going on in OBI. Have we put much thought into this yet?

@atoulme FYI

I have not put much thought into this. However, I could imagine OBI being added as a package in the proposed package system to:

Cover the programming languages that cannot be autoinjected (C, C++, Go, Rust)
Provide alternative packages to the language-specific autoinstrumentation packages (e.g., Java auto instrumentation) to reflect the fact that the end user wishes to use OBI instead of the respective language-native SDK and autoinstrumentation.

I'd gladly talk it over with OBI folks, if they are interested :-)

atoulme · 2025-12-19T08:17:55Z

@mmanciop thanks for writing this! One thing that I'd like to see is a plan that combines or rationalizes the injector's automatic discovery capabilities with the eBPF work going on in OBI. Have we put much thought into this yet?
@atoulme FYI

I have not put much thought into this. However, I could imagine OBI being added as a package in the proposed package system to:

Cover the programming languages that cannot be autoinjected (C, C++, Go, Rust)

Provide alternative packages to the language-specific autoinstrumentation packages (e.g., Java auto instrumentation) to reflect the fact that the end user wishes to use OBI instead of the respective language-native SDK and autoinstrumentation.

I'd gladly talk it over with OBI folks, if they are interested :-)

I agree with that approach. From a discussion at the injector SIG meeting with @rafaelroquetto I think there is interest. Rafael explained that OBI would not conflict with the injector because it detects if an OTLP exporter is loaded in the code, and deactivates in that case. I also work with @MrAlias who works on OBI and might have a take here.

mmanciop · 2026-01-15T08:40:07Z

Since this is a spec proposal, I am wondering if it would be possible to extend the "system packages for DEB- and RPM-based linux distributions" to APIs and SDKs, that would profit from that, as well. Mainly C++, but others maybe as well? And for those who this is not relevant/applicable because they have an eco-system for their SDK/API installation (nuget, npmjs, ...) this could be called out as "out of scope"

Very out of scope IMO.

jack-berg · 2026-01-23T22:27:25Z

+The OpenTelemetry system packages respect all the usual mechanics in terms of delivering updates via package managers:
+
+* Easy to add a trusted package repository to the Linux system
+* Dependencies are resolved transparently by the package management system: for, when you have already installed the `opentelemetry` package and later add a runtime to your Linux system, e.g., a Java Virtual Machine, that can be automatically injected, you will be recommended (opt-in) to also install the OpenTelemetry autoinstrumentation package for Java.


How would this recommendation work?

Suggest metadata in DEB. RPM unfortunately does not have an equivalent, and using Recommends instead myst install unwanted runtimes.

jack-berg · 2026-01-23T22:32:15Z

+Autoinstrumentation packages delivering SDKs that support the [declarative configuration format](https://github.com/open-telemetry/opentelemetry-configuration) should integrate file-based configurations in their system package.
+
+Injection of autoinstrumentations into applications is configurable by end users.
+The OpenTelemetry Injector package offers, upon installation, a choice whether injecting applications is opt-in (default) or opt-out. In both cases, opting specific applications in or out is done via that application's process environment using a dedicated `OTEL_`-prefixed environment variable.


Are you imagining piggy-backing off of an existing env var like OTEL_SDK_ENABLED? Or introducing a new one, something like OTEL_INSTRUMENTATION_ENABLED?

Also, how do you see this interacting with the injector's include / exclude mechanism?

jack-berg · 2026-01-23T22:35:33Z

+
+These system packages are designed to work together: the OpenTelemetry Injector knows where to look for SDKs and autoinstrumentations available on the system via their respective system packages, and injects only the applications running on matching runtimes.
+
+Autoinstrumentation packages are modelled in terms of metadata and file-system content so that vendor-specific distribution can be used as opposed to the community autoinstrumentation packages provided by the OpenTelemetry SDKs ("upstream" packages). This requires the existence of runtime-specific metapackages, like `opentelemetry-java-autoinstrumentation`, which are `provided` (using the `.deb` terminology) by both the upstream packages and vendor packages; additionally, vendor packages `replace` (using the `.deb` terminology) the upstream packages.


To do this type of thing we'd need to introduce rails to standardize the publishing / organization of these autoinstrumentation packages. Probably a repo like opentelemetry-sdk-packages or something to that effect.

Yes. There's a PROJECT file being written up ;-)

mmanciop · 2026-02-03T08:10:57Z

As agreed at OTel Unplugged '26, this OTEP is closed in favour of chartering the Packaging SIG :-)

mmanciop added 2 commits December 10, 2025 06:40

Start OTEP for autoinstrumentation system packages

204aa67

modify template.yaml to add the Autoinstrumentation System Packages c…

64e9984

…ategory

mmanciop requested review from a team as code owners December 10, 2025 05:49

mmanciop changed the title ~~Start OTEP for autoinstrumentation system packages~~ OTEP: Autoinstrumentation system packages for DEB- and RPM-based Linux distributions Dec 10, 2025

mmanciop force-pushed the otep-linux-system-packages branch from 3a2adf6 to c9508b5 Compare December 10, 2025 05:54

update OTEP number

5d19ae3

mmanciop force-pushed the otep-linux-system-packages branch from c9508b5 to 5d19ae3 Compare December 10, 2025 05:56

Merge branch 'main' into otep-linux-system-packages

831e24f

basti1302 approved these changes Dec 10, 2025

View reviewed changes

atoulme approved these changes Dec 10, 2025

View reviewed changes

mtwo reviewed Dec 15, 2025

View reviewed changes

jackshirazi reviewed Dec 16, 2025

View reviewed changes

Comment thread oteps/4793-linux-system-packages.md Outdated

Update 4793-linux-system-packages.md

9eca17b

Co-authored-by: jackshirazi <[email protected]>

mmanciop mentioned this pull request Jan 21, 2026

Ability to set OTEL_SERVICE_NAME open-telemetry/opentelemetry-injector#146

Open

jack-berg reviewed Jan 23, 2026

View reviewed changes

mmanciop mentioned this pull request Feb 3, 2026

Packaging OTEP 4793 open-telemetry/opentelemetry-injector#239

Closed

mmanciop closed this Feb 3, 2026


		## Prior art and alternatives

		The [Dash0 Operator](https://github.com/dash0hq/dash0-operator) has been using very similar mechanics (delivering an injector and autoinstrumentation files for various SDKs) on Kubernetes in production for more than year. The [OpenTelemetry Operator](https://github.com/open-telemetry/opentelemetry-operator/) also has injection mechanics processed runtime inside pods' containers, but the injection requires opt-in at the pod level via labels.


		These system packages are designed to work together: the OpenTelemetry Injector knows where to look for SDKs and autoinstrumentations available on the system via their respective system packages, and injects only the applications running on matching runtimes.

		Autoinstrumentation packages are modelled in terms of metadata and file-system content so that vendor-specific distribution can be used as opposed to the community autoinstrumentation packages provided by the OpenTelemetry SDKs ("upstream" packages). This requires the existence of runtime-specific metapackages, like `opentelemetry-java-autoinstrumentation`, which are `provided` (using the `.deb` terminology) by both the upstream packages and vendor packages; additionally, vendor packages `replace` (using the `.deb` terminology) the upstream packages.

Uh oh!

Conversation

mmanciop commented Dec 10, 2025

Changes

Uh oh!

atoulme left a comment

Choose a reason for hiding this comment

Uh oh!

mtwo left a comment

Choose a reason for hiding this comment

Uh oh!

mtwo Dec 15, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

svrnm commented Dec 16, 2025

Uh oh!

mmanciop commented Dec 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mmanciop commented Dec 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

atoulme commented Dec 19, 2025

Uh oh!

mmanciop commented Jan 15, 2026

Uh oh!

jack-berg Jan 23, 2026

Choose a reason for hiding this comment

Uh oh!

mmanciop Feb 3, 2026

Choose a reason for hiding this comment

Uh oh!

jack-berg Jan 23, 2026

Choose a reason for hiding this comment

Uh oh!

jack-berg Jan 23, 2026

Choose a reason for hiding this comment

Uh oh!

mmanciop Feb 3, 2026

Choose a reason for hiding this comment

Uh oh!

mmanciop commented Feb 3, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

mmanciop commented Dec 17, 2025 •

edited

Loading

mmanciop commented Dec 17, 2025 •

edited

Loading