-
Notifications
You must be signed in to change notification settings - Fork 888
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
Require the SDK to provide custom ID generation #1006
Require the SDK to provide custom ID generation #1006
Conversation
Actually, on second thaught, we should be more specific here.
@@ -196,6 +196,12 @@ Note: Implementation-wise, this could mean that `Tracer` instances have a | |||
reference to their `TracerProvider` and access configuration only via this | |||
reference. | |||
|
|||
The SDK MUST provide a mechanism for customizing the way IDs are generated for |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"provide a mechanism" is a bit too vague IMHO. We should maybe say that some generator functions must be set separately for trace and span id, and whether they should receive any input arguments (such as the same input as the sampler minus trace ID for trace ID generation, the same input as the sampler plus decision for span ID generation).
Maybe ID generation (especially trace ID generation) should also be integrated with the sampler, this could be a nice performance gain. See #864.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For reference, here's the approach we're taking with .NET
It listens for new Spans (Activities) and overrides the ID for local roots. This is basically the best we can do without a change to the .NET runtime itself.
Not sure how to phrase it to handle both the case where we define an interface of generator functions, or for this sort of runtime callback. The important part is the IDs can be customized somehow.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changing an already set ID seems like a waste, as the generation is not free. Also, what if other components already got that ID and assume the span will keep it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The callback happens right when the activity is created so it (as far as we understand) is safe as far as visibility goes. It better be ;)
It is wasteful to regenerate the ID, but I guess this is what .NET wants to expose. If we required a customization point before that, it's a .NET runtime change, not an OTel change. As much as I'd like that option, I'm not optimistic it's possible to drive through.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I also agree that it's hard to commit all the SDKs to following a similar pattern if we don't know how difficult it will be to get all the languages compliant. For Python it was really easy, for .NET it sounds like it wasn't...
All we know is that we do want this functionality, so that although vague, it encourages the SDKs to push towards a good thing? Regardless, any suggestions on the wording that gives us the best of both worlds is very welcome as well!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that it may be hard to specify this, as we don't have this implemented (or prototyped) in a few languages. We can work on trying to be more formal about the requirements as an After-GA goal.
from the issue triage mtg today, labelling this as |
@andrewhsu @Oberon00 Just curious, does that mean we can't merge in this change until a later point? This is already a reality for the Java & JavaScript OTel SDKs, and is being worked on for the Python & .NET SDks. The goal of getting this description in now rather than later would be to make for an easier argument when proposing these changes for the rest of the SDKs. (Although it could be worked on after GA too). |
@NathanielRN issues marked |
@tigrannajaryan Can you clarify this?
You say they can be merged but they are no longer being worked on, which would imply not being merged? Want to make sure I understand :) For this issue, since it affects compatibility with backends, I think if this is not merged for GA, at least there has to be a check to make sure all languages can add the customizability without breaking changes. If that's not possible, then that language would be incompatible with the backend until a major version upgrade which might take years. I guess that could be against the goals of OTel. |
Just want to point out that there is some difficulty in getting X-Ray compatibility in language SDKs because we haven't gotten this spec'd yet - if it was there, we reference the spec and everyone spends a lot less time / cognitive load and can be more productive. Is there some way we could prioritize this? 🙏 |
I wrote that they can be merged after the release. So they cannot be merged from the moment when freeze is announced and until the release is made. |
Thanks I misread that for some reason. A bit worried on this one since I suspect the issue / PR was labeled after-ga mostly automatically since I don't see much evidence of checking to confirm this won't be a breaking change in any of the languages. TBH I didn't prioritize sending a PR mainly because I didn't know when the real freeze date is, which I guess was last Friday. It definitely doesn't seem to have been as well publicized as #792 with the pinned issue. It's ok but wondering if there's anything we can do here to be confident that OTel can support X-Ray in all the languages. @bogdandrutu you happen to be assigned here but feel like championing this or any workaround? |
This PR was marked stale due to lack of activity. It will be closed in 7 days. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is an important point with a chance of breaking compatibility with certain backends in the long term if not addressed. It's a fairly lightweight change, ensuring there is a mechanism but not overdefining it, so seems safe. Going to leave my check and hope others agree :D
7ac0da9
to
87c7c45
Compare
@NathanielRN Please add an entry in CHANGELOG.md and spec-compliance-matrix.md and update the PR title to match the content. |
87c7c45
to
704efba
Compare
704efba
to
4e9c012
Compare
@arminru Done! ✅ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! Please add an entry here as well for tracking implementations adopting that requirement:
https://github.com/open-telemetry/opentelemetry-specification/blob/master/spec-compliance-matrix.md#traces
I think the Traces::Span section would be appropriate.
CHANGELOG.md
Outdated
@@ -55,6 +55,8 @@ New: | |||
([#1074](https://github.com/open-telemetry/opentelemetry-specification/pull/1074)) | |||
- Add semantic conventions for system metrics | |||
([#937](https://github.com/open-telemetry/opentelemetry-specification/pull/937)) | |||
- Add requirement that the SDK provide custom generation of Trace IDs and Span IDs |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Add requirement that the SDK provide custom generation of Trace IDs and Span IDs | |
- Add requirement that the SDK provides custom generation of Trace IDs and Span IDs |
Or actually "allows for customizing", since the SDK doesn't do so itself.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"Allows" sounds like a good idea! I think it's correct to not include the -s just based on gut feeling. In a google search I found this on the subject but I might be wrong and I can change it if needed!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a small point, thanks!
specification/trace/sdk.md
Outdated
The SDK SHOULD by default randomly generate the bytes for both the `TraceId` and | ||
the `SpanId`. | ||
|
||
The SDK SHOULD provide this functionality by allowing custom implementations of |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would use MAY - the interface is an example to help language authors understand the concept, but I don't think we have to recommend a particular interface which may not be idiomatic in a particular language.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good, changed!
f6050f1
to
ccd5f52
Compare
specification/trace/sdk.md
Outdated
The SDK MUST provide a mechanism for customizing the way IDs are generated for | ||
both the `TraceId` and the `SpanId`. | ||
|
||
The SDK SHOULD by default randomly generate the bytes for both the `TraceId` and |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah one small point, can you move this to be above the paragraph about customization? Right now we have this non-customization point sandwiched between the two.
And I guess this is a MUST not SHOULD (though not sure)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Moved it up!
Also changed it to MUST
:)
Closed as inactive. Feel free to reopen if this PR is still being worked on. |
a94e15d
to
c946d3c
Compare
Closed as inactive. Feel free to reopen if this PR is still being worked on. |
@NathanielRN Can you rebase? Thanks! @jmacd Looks like there are a lot of approvals, hopefully this can get merged after the rebase |
c946d3c
to
a8a9253
Compare
Rebase is done 👍 |
This PR was marked stale due to lack of activity. It will be closed in 7 days. |
7b60caa
to
2581331
Compare
@jmacd @open-telemetry/specs-trace-approvers This is becoming a weekly rebase now - can we merge it? |
2581331
to
43652ff
Compare
@jmacd @open-telemetry/specs-trace-approvers one of the concerns of merging this was brought up by @tigrannajaryan regarding this moving the target for languages trying to be spec-compliant for GA, I went through some of the languages and updated the compliance matrix for this PR to note that JavaScript and Go have both added this functionality. Hopefully, that can motivate merging this in sooner because languages have been adopting this change quickly! |
Co-authored-by: Yuri Shkuro <yurishkuro@users.noreply.github.com>
Fixes #896
Changes
Make the SDKs commit to providing a way for IDs to be customizable by including it in the specifications.
How they do so is up to the SDKs individually.
Providing this will solve the problem of having traces incompatible with some backends as discussed in the linked issue.