-
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
Capture net.host.name for netty #6892
Conversation
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.
WDYT about introducing a separate, custom AttributesExtractor
implementation that extracts that just for netty?
I actually planned to fix this issue, and implement the HTTP net.host.*
/net.peer.*
attributes correctly as one of the next steps - I imagined that we'd change the HttpServerAttributesExtractor
so that it requires both HttpServerAttributesGetter
and a NetServerAttributesGetter
. This way you wouldn't be using the NetServerAttributesExtractor
in HTTP instrumentations, but just the HttpServerAttributesExtractor
- and it'd set all the net attributes, with all that additional HTTP logic applied (e.g. parsing the Host header, not setting 80/443 ports, etc)
@CanIgnoreReturnValue | ||
public HttpServerTestOptions setHasNetAttributes(boolean hasNetAttributes) { | ||
this.hasNetAttributes = hasNetAttributes; | ||
return this; | ||
} |
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.
Can we leave a TODO refactor to use httpAttributes
here? I think it's fine to do it like this for now, but long term we'll probably want to use the same mechanism for all http/net attributes
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.
Looks great! 🚀
This may be a regression in 1.19.0 because you can no longer reconstruct the original url for netty server spans (previously `http.host` was captured which could be used).
Clean cherry-pick of #6892 to the `release/v1.19.x` branch. Co-authored-by: Trask Stalnaker <[email protected]>
This may be a regression in 1.19.0 because you can no longer reconstruct the original url for netty server spans (previously `http.host` was captured which could be used).
This may be a regression in 1.19.0 because you can no longer reconstruct the original url for netty server spans (previously `http.host` was captured which could be used).
This may be a regression in 1.19.0 because you can no longer reconstruct the original url for netty server spans (previously `http.host` was captured which could be used).
Methods were removed in #6892, which was backported to the 1.19.x branch and included in the 1.19.1 release.
Methods were removed in #6892, which was backported to the 1.19.x branch and included in the 1.19.1 release.
) Continuation (and refactoring) of #6892
This may be a regression in 1.19.0 because you can no longer reconstruct the original url for netty server spans (previously `http.host` was captured which could be used).
This may be a regression in 1.19.0 because you can no longer reconstruct the original url for netty server spans (previously
http.host
was captured which could be used).