Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow for Custom Trace and Span IDs Generation - IdsGenerator for TracerProvider #1152

Closed
NathanielRN opened this issue Sep 24, 2020 · 2 comments · Fixed by #1153
Closed

Comments

@NathanielRN
Copy link
Contributor

NathanielRN commented Sep 24, 2020

Custom IDs would allow for users to set IDs that they need right at the beginning of a span. This is important if the downstream services or eventual backend that receives these spans need them to be in a certain format. The opentelemtry-java SDK and opentelemetry-js SDK do this as well.

Is your feature request related to a problem?
Yes, some backends depend on the trace being in a certain format. Failure to be in the correct format can mean the trace is rejected and unusable with some backends.

For example, the AWS X-Ray service depends on the the trace id format being in a certain format.

If the trace-id is not valid (because the backend parses the id and decides the trace was sent more than 30 min ago) the trace is rejected.

Describe the solution you'd like
Like the SDKs mentioned above, it would be helpful to define a IdsGenerator interface from which all Id Generators Classes will conform to and provide the generate_trace_id() and generate_span_id() functions.

This will replace the same functions in the root of the opentelemetry.sdk.trace directory at opentelemetry-sdk/src/opentelemetry/sdk/trace/__init__.py

This way users can specify the IdsGenerator they want in the TracerProvider config (e.g. TracerProvider(ids_generator=AWSXRayIdsGenerator()). Otherwise by default, the RandomIdsGenerator() will be used.

Describe alternatives you've considered

  • Backend Services like XRay could just replace the ID and create a new one later in the chain (at the collector?) but this would possibly be too late because the trace can be propagated to other services...

Additional context
The main ideas behind this change are:

  • Define a IdsGenerator interface
  • Define a default RandomIdsGenerator() class which implements IdsGenerator and is used by TracerProvider
  • Allow users to provide their own IdsGenerator in the config of TracerProvider
  • Updates tests which use the exposed generate_trace_id() and generate_span_id() functions.

I started a DRAFT PR here

@owais
Copy link
Contributor

owais commented Sep 29, 2020

How does Java implement this? Have you considered configuring generator globally like propagators or the provider is registered?

@NathanielRN
Copy link
Contributor Author

OTel Java has an IdsGenerator interface defined which must be implemented to customize the generation of IDs. Then, to create the TracerSdkProvider class you must provide the ID Generator you want to use otherwise the default Random one will be used. The TracerSdkProvider class has a sharedstate which is what the TracerSdk class uses to create new IDs for new Spans.

I briefly considered it but I decided against it based on this blurb in the specifications:

Notwithstanding any global TracerProvider, some applications may want to or have to use multiple TracerProvider instances, e.g. to have different configuration (like SpanProcessors) for each (and consequently for the Tracers obtained from them), or because its easier with dependency injection frameworks. Thus, implementations of TracerProvider SHOULD allow creating an arbitrary number of TracerProvider instances.

I thought that if we have a global solution then it would make it difficult to create additional TracerProvider instances that use different ID generators, which seems to make sense if you want to send traces to both AWS X-Ray and Jaeger for example. Even still, if you want to have a global TracerProvider you can, and all you have to do is set it up with the IdsGenerator you choose.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants