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

Support the http.request.method_original attribute #8779

Conversation

mateuszrzeszutek
Copy link
Member

@mateuszrzeszutek mateuszrzeszutek requested a review from a team as a code owner June 21, 2023 14:20
Comment on lines 84 to 90
this(
httpAttributesGetter,
netAttributesGetter,
capturedRequestHeaders,
capturedResponseHeaders,
knownMethods,
HttpRouteHolder::getRoute);
Copy link
Member Author

Choose a reason for hiding this comment

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

The complexity of these constructors is kinda starting to get out of hand; I'm planning to implement Jason's dependency injection comment once I merge all the in-flight PRs.

Copy link
Contributor

Choose a reason for hiding this comment

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

Because this constructor is called all over the place with the default set, you might (in the short term) also consider doing a constructor overload that defaults the set. I think that applies to the client attr extractor as well.

@@ -24,6 +26,7 @@ public final class OkHttpTelemetryBuilder {
new ArrayList<>();
private List<String> capturedRequestHeaders = emptyList();
private List<String> capturedResponseHeaders = emptyList();
@Nullable private Set<String> knownMethods = null;
Copy link
Member Author

Choose a reason for hiding this comment

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

I really dislike these nulls here; but this was the least invasive way of implementing an optionally unset set of methods. I've an idea on how to refactor these, but I'll tackle that in a separate PR.

Copy link
Contributor

@breedx-splk breedx-splk left a comment

Choose a reason for hiding this comment

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

Looking good to me, just had a few small ideas. Thanks!

if (knownMethods.contains(method)) {
internalSet(attributes, HttpAttributes.HTTP_REQUEST_METHOD, method);
} else {
internalSet(attributes, HttpAttributes.HTTP_REQUEST_METHOD, _OTHER);
Copy link
Contributor

Choose a reason for hiding this comment

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

static import the names to improve readability?

Copy link
Member Author

Choose a reason for hiding this comment

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

The HttpAttributes values? I'm in favor of that actually -- but if we're doing that, we should implement it for all attribute keys across the whole package. I think I'd prefer to make it a separate PR, if you don't mind

Comment on lines 84 to 90
this(
httpAttributesGetter,
netAttributesGetter,
capturedRequestHeaders,
capturedResponseHeaders,
knownMethods,
HttpRouteHolder::getRoute);
Copy link
Contributor

Choose a reason for hiding this comment

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

Because this constructor is called all over the place with the default set, you might (in the short term) also consider doing a constructor overload that defaults the set. I think that applies to the client attr extractor as well.

* @param knownMethods A set of recognized HTTP request methods.
*/
@CanIgnoreReturnValue
public OkHttpTelemetryBuilder setKnownMethods(Set<String> knownMethods) {
Copy link
Contributor

Choose a reason for hiding this comment

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

@Nullable on the param?

Copy link
Member Author

Choose a reason for hiding this comment

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

Collections should never be nullable in the API (see the comment above)

@mateuszrzeszutek
Copy link
Member Author

@open-telemetry/java-instrumentation-approvers please review this PR 🙏

asList(
"CONNECT", "DELETE", "GET", "HEAD", "OPTIONS", "PATCH", "POST", "PUT", "TRACE")));

public static final String _OTHER = "_OTHER";
Copy link
Contributor

Choose a reason for hiding this comment

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

why the _?

Copy link
Member Author

Choose a reason for hiding this comment

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

It was chosen because it makes the "other" default value look like it's a kinda special thing (which it is)

If the HTTP request method is not known to instrumentation, it MUST set the http.request.method attribute to _OTHER and, except if reporting a metric, MUST set the exact method received in the request line as value of the http.request.method_original attribute.

Copy link
Contributor

@laurit laurit Jul 14, 2023

Choose a reason for hiding this comment

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

If it comes from the spec then so it must be. In my opinion using _OTHER is a mistake, there is no way that this is not going to confuse users. Everybody who sees it will assume that this is a bug/typo.

Copy link
Member Author

Choose a reason for hiding this comment

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

🤷
I don't really have a strong opinion on the value itself; I do agree that you need to have some sort of indication that it's some other unrecognized value though.

Copy link
Member

Choose a reason for hiding this comment

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

this is probably the most relevant comment why _OTHER was chosen: open-telemetry/semantic-conventions#17 (comment)

I could see backends potentially displaying this metric value with a special tooltip to help ease user confusion

public NettyServerTelemetryBuilder setKnownMethods(Set<String> knownMethods) {
this.knownMethods = knownMethods;
return this;
}
Copy link
Member

Choose a reason for hiding this comment

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

does it make any sense to have HttpClientTelemetryBuilder interface to help enforce that these implementations are consistent (and maybe we can inherit javadoc)?

Copy link
Member Author

Choose a reason for hiding this comment

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

(and maybe we can inherit javadoc)?

Hmm, we can put a @see tag I think. I don't think we can actually enforce that though.

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'll open an issue to add common http client/server tests which exercise the non-standard methods (I don't think it's a high priority since it's an edge case anyways)

@mateuszrzeszutek mateuszrzeszutek enabled auto-merge (squash) July 17, 2023 08:53
@mateuszrzeszutek mateuszrzeszutek merged commit cc8160c into open-telemetry:main Jul 17, 2023
45 checks passed
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.

None yet

4 participants