Why autosdk.TracerProvider do not have Shutdown method

[sedyh]

Problem Statement

It seems counter-intuitive to me that auto/sdk.TracerProvider does not have a Shutdown() method, while it can be used alongside custom traces just like with *sdktrace.TracerProvider which requires Shutdown() for proper resource cleanup.

Can someone clarify the design reasoning behind this? Is there a recommended approach for handling shutdown in applications that combine autosdk with manual traces?

Proposed Solution

Use Shutdown everywhere or clarify the reason why do I don't needed even with custom metrics.

Note

I do not want to keep the global tracer provider cause I want to be able to turn it on and off with the config variable.

[MrAlias]

The auto/sdk.TracerProvider is a shim for eBPF programs to hook into with their implementations of the SDK. Shutdowns are handled in the eBPF program (i.e. go.opentelemetry.io/obi or go.opentelemetry.io/auto). Shutdown is not a concern for an API user (i.e. instrumentation author).

[MrAlias]

Shutdown is not a concern for an API user (i.e. instrumentation author).

https://github.com/open-telemetry/opentelemetry-specification/blob/5239912e97a4df50b206f5fa8241dd6cd8d2dbf8/specification/trace/api.md#tracerprovider

[sedyh]

https://github.com/open-telemetry/opentelemetry-specification/blob/5239912e97a4df50b206f5fa8241dd6cd8d2dbf8/specification/trace/api.md#tracerprovider

Sorry, I can't find this quote or anything related to shutdown method in the api doc under your link.

--

Also I don't understand why "it's not" if the first getting started guide have this lines:

// Create a new tracer provider with a batch span processor and the given exporter.
tp := newTracerProvider(exp)

// Handle shutdown properly so nothing leaks.
defer func() { _ = tp.Shutdown(ctx) }()

https://opentelemetry.io/docs/languages/go/instrumentation/#getting-a-tracer

How I understand this now:

1. Regular Tracer Provider needs to be closed. Probably because the connection in otlptrace/otlptracegrpc and otlptrace/otlptracehttp and you have custom metrics.
2. AutoSDK Tracer Provider don't need to be closed... even if it have the same connection and custom metrics?

[MrAlias]

https://github.com/open-telemetry/opentelemetry-specification/blob/5239912e97a4df50b206f5fa8241dd6cd8d2dbf8/specification/trace/api.md#tracerprovider

Sorry, I can't find this quote or anything related to shutdown method in the api doc under your link.

That is the point of the comment, the API is not concerned with the shutdown functionality only the SDK cares about this.

[MrAlias]

Also I don't understand why "it's not" if the first getting started guide have this lines:

// Create a new tracer provider with a batch span processor and the given exporter.
tp := newTracerProvider(exp)

// Handle shutdown properly so nothing leaks.
defer func() { _ = tp.Shutdown(ctx) }()

https://opentelemetry.io/docs/languages/go/instrumentation/#getting-a-tracer

You are liking to the documentation for the default SDK provided here, not from the go.opentelemetry/auto/sdk package like you mention in this issue title and and description.

Those are two different things and shouldn't be confused.

[MrAlias]

What are you doing with the go.opentelemetry.io/auto/sdk package?

You likely do not need to use that package. If you are trying to integration manual spans with some eBPF instrumentation all you need to do is use the OTel API provided by go.opentelemetry.io/otel.

[sedyh]

Those are two different things and shouldn't be confused.

I mean. If tracer provider can be closed automaticaly, is there a reason why it is kept exposed in the regular api? Maybe limited exporter configuration?

If you are trying to integration manual spans with some eBPF instrumentation all you need to do is use the OTel API provided by go.opentelemetry.io/otel .

Yeah. I just need tracer provider for my custom traces with ebpf part before and after to see stdlib latencies. Also I would like to not have any globals.

[MrAlias]

Yeah. I just need tracer provider for my custom traces with ebpf part before and after to see stdlib latencies. Also I would like to not have any globals.

The supported integration of auto-instrumentation is only with the global providers (while nothing is registered directly in the code base).

To start a trace the auto instrumentation will pickup do something like this:

https://github.com/open-telemetry/opentelemetry-go-instrumentation/blob/681f8916a65fbc3a7416fd2aaf6eda1f1bc9c5fa/examples/rolldice/user/server/server.go#L42-L52

Then when you run the auto-instrumentation (with elevated permissions), that span will be captured there and sent though its tracing pipeline.

[MrAlias]

Those are two different things and shouldn't be confused.

I mean. If tracer provider can be closed automaticaly, is there a reason why it is kept exposed in the regular api?

It is not. auto/sdk is an SDK implementation of the API. go.opentelemetry.io/otel/sdk/trace is also an SDK implementation of the API. The API is defined in go.opentelemetry.io/otel/trace, which does not define a Shutdown method.