Stats: Map deprecated RPC tags when record against new tags. #1854
Stats: Map deprecated RPC tags when record against new tags. #1854
Conversation
// TODO(songy23): remove the mapping once we completely remove the deprecated RPC constants. | ||
private static TagValue getTagValueForDeprecatedRpcTag( | ||
Map<? extends TagKey, TagValueWithMetadata> tags, TagKey oldKey) { | ||
for (TagKey newKey : RPC_TAG_MAPPINGS.get(oldKey)) { |
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.
@carl-mastrangelo, I think the for-each construct will create an Iterator, which you may not want to see. Maybe RPC_TAG_MAPPINGS
should be defined as a Map<TagKey, TagKey[]>
because for-each on an array presumably doesn't create an Iterator?
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.
SGTM, updated.
Map<TagKey, TagValueWithMetadata> tags = | ||
ImmutableMap.of( | ||
RecordUtils.GRPC_CLIENT_METHOD, METHOD_V_WITH_MD, | ||
RecordUtils.GRPC_CLIENT_STATUS, STATUS_V_WITH_MD); |
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.
What happens when we have both a client method and a server 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.
Depending on what tag keys we have in the view:
- If we have the new "client_method" or "server_method" key (or even both), everything works fine;
- If we have the old "method" key,
a random value will be picked. While without this mapping the value will always be null.
IMO this should be less an issue because eventually users should migrate to use the new keys. WDYT?
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.
By looking at getTagValueForDeprecatedRpcTag()
, it seems the underlying data (columns?) is still in the old format, thus getTagValueForDeprecatedRpcTag()
tries to get the values from the new tags in case the old tags are not set. If both "client_method" or "server_method" are set, "client_method" will be used. Is it going to be the case even after the old tags are removed?
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.
So, iiuc, if we have a view with and old key (e.g. "rpc_method") and tags
- contains tag rpc_method:v1 then v1 is used
- otherwise, contains tag grpc_client_method:v2 then v2 is used
- otherwise contains tag grpc_server_method:v3 then v3 is used
- otherwise UNKNOWN_TAG_VALUE is used
Is that correct? If so, it may be worth enumerating in the unit tests. Also, when we have both grpc_client_method and grpc_server_method, which one matches closer to the original notion of rpc_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.
If both "client_method" or "server_method" are set, "client_method" will be used.
Apologies for the confusion, what Kun said is correct. If both are present and a view is using the old column, client method value will be picked.
if we have a view with and old key (e.g. "rpc_method") and tags
Yes the order is correct. I added a few tests on 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.
If both "client_method" or "server_method" are set, "client_method" will be used. Is it going to be the case even after the old tags are removed?
No, the new "client_method" and "server_method" tags will be matched properly regardless of the old tag. This change is only trying to get the values from the new tags for old tag column if it's still in use. Added one more test in 6867966 to verify.
// replace not found key values by null. | ||
tagValues.add(UNKNOWN_TAG_VALUE); | ||
@javax.annotation.Nullable TagValue tagValue = UNKNOWN_TAG_VALUE; | ||
if (RPC_TAG_MAPPINGS.containsKey(tagKey)) { |
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.
nit: this is a double lookup of the key. It would be better to just get() it, and check for Null
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.
Done, good catch.
} | ||
for (TagKey newKey : newKeys) { | ||
if (tags.containsKey(newKey)) { | ||
return tags.get(newKey).getTagValue(); |
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.
nit: this is also a double lookup.
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.
Fixed.
Map<TagKey, TagValueWithMetadata> tags = | ||
ImmutableMap.of( | ||
RecordUtils.GRPC_CLIENT_METHOD, METHOD_V_WITH_MD, | ||
RecordUtils.GRPC_CLIENT_STATUS, STATUS_V_WITH_MD); |
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.
By looking at getTagValueForDeprecatedRpcTag()
, it seems the underlying data (columns?) is still in the old format, thus getTagValueForDeprecatedRpcTag()
tries to get the values from the new tags in case the old tags are not set. If both "client_method" or "server_method" are set, "client_method" will be used. Is it going to be the case even after the old tags are removed?
72957b7
to
cec1f5a
Compare
RecordUtils.GRPC_SERVER_METHOD, METHOD_V_WITH_MD, | ||
RecordUtils.GRPC_SERVER_STATUS, STATUS_V_WITH_MD, | ||
RecordUtils.GRPC_CLIENT_METHOD, METHOD_V_2_WITH_MD, | ||
RecordUtils.GRPC_CLIENT_STATUS, STATUS_V_2_WITH_MD); |
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.
Yes - these tests clarify what's going on, thanks@ - you may want to add a test that contains GRPC_SERVER_METHOD, GRPC_CLIENT_METHOD, and RPC_METHOD to verify that the RPC_METHOD tag value does not unexpectedly get overridden by the other tags but I'll leave that up to you.
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.
Good idea, added one in 9e371ba.
f859b05
to
9e371ba
Compare
Thanks for the review! |
Fixes grpc#5593 and supersedes grpc#5601 Now that census-instrumentation/opencensus-java#1854 has been merged & released as 0.21.0. We can start using the method & status tags. Background: Opencensus introduced new tags for status and method (census-instrumentation/opencensus-java#1115). The old views that used those tags were deprecated and new views were created that used the new tags. However grpc-java wasn't updated to use the new tags due to concern of breaking existing metrics. This resulted in the old views being deprecated while the new views were broken (goomics grpc#50). census-instrumentation/opencensus-java#1854 added a compatibility layer to opencensus that would remap new tags to old tags for old views. This should unblock grpc to switching to the new tags while allowing old views to still be populated. That commit was released as part of opencensus 0.21, which grpc currently uses
Fixes #5593 and supersedes #5601 Now that census-instrumentation/opencensus-java#1854 has been merged & released as 0.21.0. We can start using the method & status tags. Background: Opencensus introduced new tags for status and method (census-instrumentation/opencensus-java#1115). The old views that used those tags were deprecated and new views were created that used the new tags. However grpc-java wasn't updated to use the new tags due to concern of breaking existing metrics. This resulted in the old views being deprecated while the new views were broken (goomics #50). census-instrumentation/opencensus-java#1854 added a compatibility layer to opencensus that would remap new tags to old tags for old views. This should unblock grpc to switching to the new tags while allowing old views to still be populated. That commit was released as part of opencensus 0.21, which grpc currently uses
gRPC may migrate to use the new RPC tags (e.g "grpc_client_method") in grpc/grpc-java#5601 and stop recording against the deprecated tags (e.g "method"). However probably there're users who still use the deprecated RPC constants. To avoid breaking their metrics, we need to do some mappings when recording stats against the new tags.
Note the deprecated RPC measures are already mapped to the new ones in #1738.
Updates #1764.