Skip to content
This repository has been archived by the owner on Dec 23, 2023. It is now read-only.

Stats: Map deprecated RPC tags when record against new tags. #1854

Merged
merged 6 commits into from Apr 20, 2019

Conversation

songy23
Copy link
Contributor

@songy23 songy23 commented Apr 19, 2019

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.

// 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)) {
Copy link
Contributor

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?

Copy link
Contributor Author

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);
Copy link
Contributor

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?

Copy link
Contributor Author

@songy23 songy23 Apr 19, 2019

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:

  1. If we have the new "client_method" or "server_method" key (or even both), everything works fine;
  2. 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?

Copy link
Contributor

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?

Copy link
Contributor

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

  1. contains tag rpc_method:v1 then v1 is used
  2. otherwise, contains tag grpc_client_method:v2 then v2 is used
  3. otherwise contains tag grpc_server_method:v3 then v3 is used
  4. 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?

Copy link
Contributor Author

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.

Copy link
Contributor Author

@songy23 songy23 Apr 20, 2019

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)) {

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

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, good catch.

}
for (TagKey newKey : newKeys) {
if (tags.containsKey(newKey)) {
return tags.get(newKey).getTagValue();
Copy link
Contributor

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.

Copy link
Contributor Author

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);
Copy link
Contributor

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?

@songy23 songy23 force-pushed the map-grpc-method-tag branch 2 times, most recently from 72957b7 to cec1f5a Compare April 20, 2019 00:43
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);
Copy link
Contributor

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.

Copy link
Contributor Author

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.

@songy23
Copy link
Contributor Author

songy23 commented Apr 20, 2019

Thanks for the review!

@songy23 songy23 merged commit c35bc41 into census-instrumentation:master Apr 20, 2019
@songy23 songy23 deleted the map-grpc-method-tag branch April 20, 2019 01:46
igorbernstein2 added a commit to igorbernstein2/grpc-java that referenced this pull request Jul 21, 2019
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
zhangkun83 pushed a commit to grpc/grpc-java that referenced this pull request Aug 1, 2019
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
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants