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

gRPC support request/response size #11833

Open
wants to merge 28 commits into
base: main
Choose a base branch
from

Conversation

crossoverJie
Copy link
Contributor

@crossoverJie crossoverJie requested a review from a team July 16, 2024 09:46
@crossoverJie crossoverJie marked this pull request as draft July 18, 2024 01:41
@crossoverJie crossoverJie marked this pull request as ready for review July 20, 2024 14:44
@crossoverJie
Copy link
Contributor Author

@trask @laurit PTAL, thanks.

Comment on lines 28 to 42
default int getClientRequestSize(REQUEST request) {
return 0;
}

default int getClientResponseSize(REQUEST request) {
return 0;
}

default int getServerRequestSize(REQUEST request) {
return 0;
}

default int getServerResponseSize(REQUEST request) {
return 0;
}
Copy link
Contributor

Choose a reason for hiding this comment

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

the type for these should be Long, and these should return null by default. We need to consider whether this should be split into separate client/server getters similarly to what we do for http client/server. Would it make sense to introduce a response parameter too? Or perhaps just have getRequestSize and getResponseSize in the getter, we already have separate extractors for client/server these could be used to set the correct attribute.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thank for your suggestion, Done.


Long rpcServerRequestBodySize =
RpcMessageBodySizeUtil.getRpcServerRequestBodySize(endAttributes, state.startAttributes());
if (rpcServerRequestBodySize != null && rpcServerRequestBodySize > 0) {
Copy link
Contributor

Choose a reason for hiding this comment

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

> 0 condition is weird. I think you can get rid of it by changing the type in getter from int -> Long so you can distinguish when getter does not implement this.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done.

ServerAttributes.SERVER_PORT));
}

static void applyClientRequestSizeAdvice(LongHistogramBuilder builder) {
Copy link
Contributor

@laurit laurit Jul 23, 2024

Choose a reason for hiding this comment

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

as you are always going to use the same set of attributes you could make all these delegate to a common method or extract the attributes list to a variable

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done.

Comment on lines 33 to 40
private static final AttributeKey<Long> RPC_CLIENT_REQUEST_BODY_SIZE =
AttributeKey.longKey("rpc.client.request.body.size");
private static final AttributeKey<Long> RPC_CLIENT_RESPONSE_BODY_SIZE =
AttributeKey.longKey("rpc.client.response.body.size");
private static final AttributeKey<Long> RPC_SERVER_REQUEST_BODY_SIZE =
AttributeKey.longKey("rpc.server.request.body.size");
private static final AttributeKey<Long> RPC_SERVER_RESPONSE_BODY_SIZE =
AttributeKey.longKey("rpc.server.response.body.size");
Copy link
Contributor

Choose a reason for hiding this comment

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

in tests you should use RpcIncubatingAttributes

Copy link
Contributor Author

Choose a reason for hiding this comment

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

These attributes do not currently exist in RpcIncubatingAttributes, Maybe we should define them in semantic-conventions

Copy link
Contributor

Choose a reason for hiding this comment

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

yes, you should try getting these included in the semantic attributes

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.

Response/Request Size GRPC Metrics Instrumentation
3 participants