search

MrAlias / otel-schema

Playground to prototype and investigate configuration schema proposals for OpenTelemetry
Apache License 2.0
2 stars 7 forks source link

Document known limitations in otep #30

Open codeboten opened 1 year ago

codeboten commented 1 year ago

Important to call out some of the limitations for configuration, a couple of limitations we may want to call out:

  1. multiple tracer/meter/logger providers are not supported (it would be really difficult to specify the correct provider in the config and in the code)
  2. custom context propagators are not supported (there's no way to provide custom context extraction code via configuration)
jack-berg commented 1 year ago

multiple tracer/meter/logger providers are not supported (it would be really difficult to specify the correct provider in the config and in the code)

I think language SDKs should eventually have a component responsible for parsing a config file and returning a fully configured SDK instance (or throwing if the config is invalid). Most applications will want to invoke the code to parse a config file once, but it seems reasonable to also allow invoking the code multiple times. If used multiple times, the caller must be responsible for passing each configured SDK to the appropriate part of the application.

So you can parse multiple config files, but each contains the config for one SDK (i.e. one tracer/meter/logger provider).

custom context propagators are not supported (there's no way to provide custom context extraction code via configuration)

Java has a mechanism for this today. You can implement the ConfigurablePropagatorProvider interface, and reference the name in the OTEL_PROPAGATORS environment variable. We have similar mechanisms available for providing other custom extension components like exporters.