OpenTelemetry Propagators should run independently of Tracer Exporters

[ruiengana]

trafficstars

Currently if you initiate the SDK with only Propagators and not Tracer Exporters the propagators are never called. This is because it's assumed the only behaviour for Propagators are dependent of Tracing. Well this is not fully accurate, there are propagators that are related to Tracing and others that are related to Logging (for correlation purposes).

Found this definition of OpenTelemetry.

OpenTelemetry provides a single, open source standard and a set of technologies to capture and export metrics, traces, and logs from your cloud-native applications and infrastructure.

From above definition and knowing that the current state of the project still doesn't include Logs Exporters, I don't understand why limit the usage of Propagators only for Tracing purposes when this instrumentation is required for also Logging purposes, even when Log Exporters are done elsewhere.

• [ ] This only affects the JavaScript OpenTelemetry library
• [X] This may affect other libraries, but I would like to get opinions here first

[pichlermarc]

Is this a feature request for the @opentelemetry/sdk-node package? There is a propagator API that let's you set propagators independently of whether you're using trace or logs.

[ruiengana]

Is this a feature request for the @opentelemetry/sdk-node package?

There is a propagator API that let's you set propagators independently of whether you're using trace or logs.

Yes, potentially.

How would you instrument Propagation without the SDK?

[pichlermarc]

That depends on what you mean by it "instrument Propagation" :thinking:

Instrumentations use the Propagator API and the Context API to propagate W3C trace context for example. For that to work you need to register a context manager to the context API from @opentelemetry/api, and a propagator via the propagator API from @opentelemetry/api. Which one that is will depend on what you want to propagate (W3C trace context or something else). Then you also need to enable an instrumentation (for example @opentelemetry/instrumentation-http or @opentelemetry/instrumentation-grpc, depending on where you need your context propagated to and that will inject it into your requests and responses). The instrumentation will also try to create Spans, but if there's no Trace SDK registered with the API it'll just be a no-op.

If there's no instrumentation for the package that you're using, however, you'll have to inject it manually (using propagation and context APIs).

I believe you're trying to ask for the following feature: When using NodeSDK and only setting up Logging, it should automatically register a context manager and propagator so that these two features would work just like when configuring NodeSDK with only Tracing.

Is that correct? :slightly_smiling_face:

[ruiengana]

That depends on what you mean by it "instrument Propagation" 🤔

Instrumentations use the Propagator API and the Context API to propagate W3C trace context for example. For that to work you need to register a context manager to the context API from @opentelemetry/api, and a propagator via the propagator API from @opentelemetry/api. Which one that is will depend on what you want to propagate (W3C trace context or something else). Then you also need to enable an instrumentation (for example @opentelemetry/instrumentation-http or @opentelemetry/instrumentation-grpc, depending on where you need your context propagated to and that will inject it into your requests and responses). The instrumentation will also try to create Spans, but if there's no Trace SDK registered with the API it'll just be a no-op.

If there's no instrumentation for the package that you're using, however, you'll have to inject it manually (using propagation and context APIs).

I believe you're trying to ask for the following feature: When using NodeSDK and only setting up Logging, it should automatically register a context manager and propagator so that these two features would work just like when configuring NodeSDK with only Tracing.

Is that correct? 🙂

Yes, that's exactly it! Just to confirm, by "using NodeSDK only for Logging" you mean NodeSDK without tracing exporters defined in the constructor.

In essence the Logging features of NodeSDK (which Propagators are part of) should not have any dependency of the Tracing features of NodeSDK. They should be able to configure and use independently of each other.

Hope this makes sense 🙂

[github-actions[bot]]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 14 days.

[github-actions[bot]]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 14 days.

[ilmari]

This also breaks when the trace exporter is configured via the environment, rather than using arguments to the NodeSDK constructor, because the propagator option to the traceProvider.register() call comes from this._traceProviderConfig which is only set when traceExporter, spanProcessor, or spanProcessors is passed to the constructor.