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

Split out RpcAttributesGetter #5548

Merged

Conversation

mateuszrzeszutek
Copy link
Member

@mateuszrzeszutek mateuszrzeszutek commented Mar 11, 2022

Part of #5291

I thought it would be useful to split the extractors into RpcClientAttributesExtractor and RpcServerAttributesExtractor because they will have different SpanKeys associated to them; there's only one getter interface though, cause both extractors use it to retrieve the same set of attributes.

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.

I thought it would be useful to split the extractors into RpcClientAttributesExtractor and RpcServerAttributesExtractor because they will have different SpanKeys associated to them; there's only one getter interface though, cause both extractors use it to retrieve the same set of attributes.

Do you think it makes sense to proactively split the getter as well (similar to http client/server getter) in case rpc client/server attributes diverge in the future?

@mateuszrzeszutek
Copy link
Member Author

Do you think it makes sense to proactively split the getter as well (similar to http client/server getter) in case rpc client/server attributes diverge in the future?

I thought about it too and in the end I couldn't decide whether to do it or not -- I'll try it out and push the change here, let's see if it looks manageable.

@trask
Copy link
Member

trask commented Mar 14, 2022

Do you think it makes sense to proactively split the getter as well (similar to http client/server getter) in case rpc client/server attributes diverge in the future?

I thought about it too and in the end I couldn't decide whether to do it or not -- I'll try it out and push the change here, let's see if it looks manageable.

@anuraaga thoughts?

@anuraaga
Copy link
Contributor

I think unlike HTTP RPC has a stronger tendency to have the same data in server / client so we could probably avoid splitting now.

@trask
Copy link
Member

trask commented Mar 15, 2022

I think unlike HTTP RPC has a stronger tendency to have the same data in server / client so we could probably avoid splitting now.

sounds good, IIRC our current thinking is to not stabilize a semantic attributes extractor until that semantic convention is declared stable, so that gives us some time to see if anything new emerges for rpc

@trask
Copy link
Member

trask commented Mar 15, 2022

@mateuszrzeszutek heads up conflicts

@mateuszrzeszutek mateuszrzeszutek merged commit 1ee60aa into open-telemetry:main Mar 17, 2022
@mateuszrzeszutek mateuszrzeszutek deleted the extract-rpc-getter branch March 17, 2022 10:14
RashmiRam pushed a commit to RashmiRam/opentelemetry-auto-instr-java that referenced this pull request May 23, 2022
* Split out RpcAttributesGetter

* code review comments

* go back to RpcAttributesGetter
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.

3 participants