Manual instrumentation support - Phase 1

[RonFed]

This PR addresses some of the functionality described in #352 .
The following change adds the ability to integrate with manually created spans via the OpenTelemetry APIs.
Currently the eBPF collects the start and end time, span name and attributes passed by the user via SetAttributes.
This functionality is disabled by default and can be enabled via an env var or passing an Instrumentation option WithGlobal()
Added e2e tests.
This is only a partial implementation, the following are known gaps that will be added in future PRs:

• Slice attributes.
• Events
• Span errors

Next steps until full implementation are described in #352 (comment)

[MikeGoldsmith]

Is the intention here that you configure your application with the OTel SDK and out it into non-recording (eg no export) mode then the auto-instrumentation process watches for the tracer starting spans and duplicate them so they can be exported? It kinda feels wasteful as we'll be creating every span twice.

[RonFed]

Is the intention here that you configure your application with the OTel SDK and out it into non-recording (eg no export) mode then the auto-instrumentation process watches for the tracer starting spans and duplicate them so they can be exported? It kinda feels wasteful as we'll be creating every span twice.

Initially, I thought of attaching the uprobes to the Otel SDK functions however, this PR attaches them to the API functions. This means that this feature is only relevant for applications that don't have an active SDK set-up (you can see an example in the roll-dice application). These API calls are basically no-ops but the eBPF is using them to collect the user attributes. so if this feature is opted in there shouldn't be a span duplication.

[MrAlias]

This doesn't seem to be inline with the proposed solutions: #352 (comment)

Provide a TracerProvider implementation from auto-instrumentation that manual instrumentation can explicitly use to say they want their data to go to the same pipeline. This means the auto-instrumentation will control the type that manual instrumentation uses to create, edit, and end spans if they want the data to be sent to the auto-instrumentation pipeline

The proposal was to provide a TracerProvider implementation here that we would detect being used by other processes. The changes proposed in this PR are instrumenting the global implementation from go.opentelemetry.io/otel.

There are going to be serious limitations to this approach given the global from otel provides delegation support (i.e. the nonRecordingSpan or Tracer there will not be called when the user sets a TracerProvider).

I'm not sure this is a viable solution.

[MrAlias]

This doesn't seem to be inline with the proposed solutions: #352 (comment)

Provide a TracerProvider implementation from auto-instrumentation that manual instrumentation can explicitly use to say they want their data to go to the same pipeline. This means the auto-instrumentation will control the type that manual instrumentation uses to create, edit, and end spans if they want the data to be sent to the auto-instrumentation pipeline

The proposal was to provide a TracerProvider implementation here that we would detect being used by other processes. The changes proposed in this PR are instrumenting the global implementation from go.opentelemetry.io/otel.

There are going to be serious limitations to this approach given the global from otel provides delegation support (i.e. the nonRecordingSpan or Tracer there will not be called when the user sets a TracerProvider).

I'm not sure this is a viable solution.

This is not addressing point (1) from the linked solutions, it is addressing point (2).

[MrAlias]

Talked with @edeNFed in SIG meeting:

This is only meant to address the situation where a user has not registered an SDK with the global and they opt-in with the auto-instrumentation to record this telemetry. This is not intended to capture the telemetry from a default OTel SDK.

[RonFed]

@MrAlias Can you please take another look?