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

Consistent reservoir sampling span processor #352

Merged

Conversation

oertl
Copy link
Contributor

@oertl oertl commented May 27, 2022

Description:

Implementation of a consistent reservoir sampling span processor

@oertl oertl requested a review from a team May 27, 2022 15:12
OtelTraceState otelTraceState = OtelTraceState.parse(otelTraceStateString);
int pval;
int rval;
long priority = randomGenerator.nextLong();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I understand that among spans with the same r-value, the priority decides which spans will be removed from the reservoir. Giving each span a new random value may break trace completeness to a larger degree than it is necessary.
To alleviate this problem, the priority might be made dependent on trace-id, for example by combining a hash of trace-id and a (less significant) random number. Since there are no guarantees about quality of trace-id in general, I do not advocate to do it by default, but it would be nice to refactor the code so it would be easy to do for the users who really want it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, this improvement could be added in a later PR without breaking anything. As it would require choosing a hash function, which is a difficult decision by itself, much more discussion would be needed. (Ideally, it should be a fast, high-quality function for which there are compatible implementations in all relevant programming languages.) I think as a first step, this PR should be merged without this improvement.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What I meant by refactoring was something like calculating the priority using an overridable method with trace-id as a parameter. It would remain unused in the default implementation.
But I agree with you that it can be done later.

@trask
Copy link
Member

trask commented Jun 13, 2022

@PeterF778 thanks for reviewing! would you be interested in being a "component owner" for the consistent sampling component? (see #174) this is a tricky component and we only have a single component owner currently which slows down reviews and merges for it.

@PeterF778
Copy link
Contributor

PeterF778 commented Jun 13, 2022 via email

@trask
Copy link
Member

trask commented Jun 13, 2022

great! I'll send a PR to add you

@trask
Copy link
Member

trask commented Jun 15, 2022

Closing and re-opening to see if reviewers get updated

@trask trask closed this Jun 15, 2022
@trask trask reopened this Jun 15, 2022
@trask
Copy link
Member

trask commented Jun 15, 2022

Closing and re-opening to see if reviewers get updated

It didn't work, I think because the branch is not up-to-date with main (which has the new component owners updates).

This is not a problem though.

@PeterF778 if you can finish reviewing and/or approve then I will do a quick check and merge. thx!

Copy link
Member

@trask trask left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thx @oertl!

@trask trask merged commit a26d441 into open-telemetry:main Jun 15, 2022
Copy link
Contributor

@jmacd jmacd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, sorry for the late review. I believe I understand what is being done.
LGTM

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

Successfully merging this pull request may close these issues.

4 participants