-
Notifications
You must be signed in to change notification settings - Fork 867
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
Set custom gRPC client/server span name extractor #5244
Set custom gRPC client/server span name extractor #5244
Conversation
/** Sets the {@code peer.service} attribute for http client spans. */ | ||
public void setPeerService(String peerService) { | ||
public GrpcTracingBuilder setPeerService(String peerService) { |
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.
Fixing existing builder method
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.
would like @mateuszrzeszutek or @anuraaga's review
* Sets custom client {@link SpanNameExtractor} | ||
*/ | ||
public GrpcTracingBuilder setClientSpanNameExtractor( | ||
SpanNameExtractor<? super GrpcRequest> clientSpanNameExtractor) { |
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.
Instead of just passing the SpanNameExtractor
, WDYT about passing a Function<SpanNameExtractor<GrpcRequest>, ? extends SpanNameExtractor<? super GrpcRequest>>
? (similar to how the Armeria instrumentation allows modifying the SpanStatusExtractor
)
With a transformer function you can still make use of the original span name extractors - or reject them altogether and return your own, if you wish to do so.
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 interesting
Chaining status code transformations makes more sense imo than extracting span name (which is a string, doubt you'd like to have pattern matching on it)
Or what's the use case you have in mind? One could be if length is more that X use shorter version of method name; since default impl is pretty straight forward I'd stick to the current version, + it gives api consistency with other methods
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.
Or what's the use case you have in mind? One could be if length is more that X use shorter version of method name;
That's one option. I was thinking of a case where you might decide to fall back on the default naming scheme based on the request, e.g. (request) -> shouldRename(request) ? customName(request) : originalSpanNameExtractor.extract(request)
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.
@trask what do you think? current way as api consistency vs suggested flexibility?
I'm ok with both
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.
let's go with @mateuszrzeszutek's proposal, thx!
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.
* Set custom gRPC client/server span name extractor * Fix imports * Fix compilation * Fix style rule * Update to use Functions instead * Fix formatting
Typical use case - set short operation name instead of full description name