Clarify documentation about excluding otel-instrumented services

[pilhuhn]

See https://opentelemetry.io/docs/zero-code/obi/configure/service-discovery/#exclude-otel-instrumented-services

It says :

The exclude_otel_instrumented_services option disables OBI instrumentation of services already instrumented with OpenTelemetry

Now I have this config:

discovery:
  instrument:
    #- open_ports: 8000
    - exe_path: "*python3.14*"
  exclude_otel_instrumented_services: true

and I do see duplicate instrumentation in my Python code

python3.4 and payment are the same code.

Perhaps I am using the flag wrong. Or the obi-instrumentation does not catch all cases.

Server code is at https://github.com/pilhuhn/observability-talk/blob/main/python-pay/server5.py

[marctc]

Hey thanks for reporting! I dont think it's a problem of documentation, it's a bug. We are just checking env vars of instrumente services and I think you are using args to config the collector

[grcevski]

Hey thanks for reporting! I dont think it's a problem of documentation, it's a bug. We are just checking env vars of instrumente services and I think you are using args to config the collector

We don't do the detection based on environment variables, env variables are good. If OBI is instrumenting a SDK instrumented service we monitor for the service to use OTLP (HTTP or gRPC) to export telemetry in OpenTelemetry format. The detection is based on the paths that the OTLP standard defines. We need to see a successful export of telemetry and then we deem the application as exporting OTEL and leave it alone.

[grcevski]

Recently there was an issue with unknown paths for gRPC, so we added detection based on the port 4317. I'm wondering if that's not working. Thanks for providing the testcase, we can look into this.

[pilhuhn]

Do you mean, that the 1st export of telemetry will happen and then, then OBI would see it and disable sending from there on?

…

-- ***@***.*** m:0179/207 4919 b:https://pilhuhn.homeip.net

On 6 Feb 2026, at 14:53, Nikola Grcevski wrote: grcevski left a comment (open-telemetry/opentelemetry-ebpf-instrumentation#1248) > Hey thanks for reporting! I dont think it's a problem of > documentation, it's a bug. We are just checking env vars of > instrumente services and I think you are using args to config the > collector We don't do the detection based on environment variables, env variables are good. If OBI is instrumenting a SDK instrumented service we monitor for the service to use OTLP (HTTP or gRPC) to export telemetry in OpenTelemetry format. The detection is based on the paths that the OTLP standard defines. We need to see a successful export of telemetry and then we deem the application as exporting OTEL and leave it alone. -- Reply to this email directly or view it on GitHub: #1248 (comment) You are receiving this because you authored the thread. Message ID: ***@***.***>

[grcevski]

Yes, we need to see the export and then we'll disable the service internally. Essentially, for some languages (like Go) we support OBI + manual SDK spans, so detecting OTEL as a component in the code is not the way to go, we'd like to support mixing automatic and manual instrumentation more in the future. So that leaves us with detecting that the application is actually sending telemetry on it's own. And we need to detect the successful export, badly configured application should still be instrumented with OBI :).

So if this is just a few spans and then it stopped, then it's working as designed.

[grcevski]

Perhaps that should be better documented :)

[pilhuhn]

support mixing automatic and manual instrumentation more in the future

That sounds great.