-
Notifications
You must be signed in to change notification settings - Fork 869
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
add metrics rpc conventions implement #4838
Conversation
hi @trask,the EasyCLA check have passed,thank 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.
LGTM 👍
Thanks! I've left a couple of comments here, but they're all fairly minor things.
...pi/src/main/java/io/opentelemetry/instrumentation/api/instrumenter/rpc/RpcClientMetrics.java
Outdated
Show resolved
Hide resolved
...pi/src/main/java/io/opentelemetry/instrumentation/api/instrumenter/rpc/RpcClientMetrics.java
Outdated
Show resolved
Hide resolved
...pi/src/main/java/io/opentelemetry/instrumentation/api/instrumenter/rpc/RpcClientMetrics.java
Outdated
Show resolved
Hide resolved
...pi/src/main/java/io/opentelemetry/instrumentation/api/instrumenter/rpc/RpcClientMetrics.java
Outdated
Show resolved
Hide resolved
...pi/src/main/java/io/opentelemetry/instrumentation/api/instrumenter/rpc/RpcClientMetrics.java
Outdated
Show resolved
Hide resolved
...pi/src/main/java/io/opentelemetry/instrumentation/api/instrumenter/rpc/RpcServerMetrics.java
Outdated
Show resolved
Hide resolved
...pi/src/main/java/io/opentelemetry/instrumentation/api/instrumenter/rpc/RpcServerMetrics.java
Outdated
Show resolved
Hide resolved
...pi/src/main/java/io/opentelemetry/instrumentation/api/instrumenter/rpc/RpcServerMetrics.java
Outdated
Show resolved
Hide resolved
...pi/src/main/java/io/opentelemetry/instrumentation/api/instrumenter/rpc/RpcServerMetrics.java
Outdated
Show resolved
Hide resolved
...pi/src/main/java/io/opentelemetry/instrumentation/api/instrumenter/rpc/RpcServerMetrics.java
Outdated
Show resolved
Hide resolved
Thanks for @mateuszrzeszutek suggestions,and I have resolve them. |
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.
thx @yangtaoran!
can you add tests similar to HttpClientMetricsTest
and HttpServerMetricsTest
?
// the list of optional metrics attributes is from | ||
// https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/semantic_conventions/rpc.md#attributes | ||
Set<AttributeKey> view = new HashSet<>(); | ||
view.add(SemanticAttributes.NET_PEER_IP); | ||
view.add(SemanticAttributes.NET_PEER_NAME); | ||
view.add(SemanticAttributes.NET_PEER_PORT); | ||
view.add(SemanticAttributes.NET_TRANSPORT); | ||
return view; |
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.
cc @jsuereth: this follows the spec, but I'm worried about the cardinality issue you raised previously, 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.
According to the linked doc:
To avoid high cardinality, implementations should prefer the most stable of net.peer.name or net.peer.ip, depending on expected deployment profile. For many cloud applications, this is likely net.peer.name as names can be recycled even across re-instantiation of a server with a different ip.
I.e. you can fallback to net.peer.ip if it's you're only option, but you should JUST use net.peer.name if you can.
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.
@jsuereth so we should go ahead and capture these same attributes on server metrics (unlike on http server metrics)? I guess the situation is not as bad in RPC-land as in browser-land (except for maybe android/grpc?)
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.
We may want to re-evaluate server side using a notion of endpoint vs. net.peer.ip for similar reasons to http. However the specification is based on what gRPC does. I'll do some homework here to see if this is still how that's instrumented.
Key thing though, we should be using hostname over IP because hostname should be more stable, especially in the presence of a load balancer.
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.
I understanding is usering net.peer.name instead of net.peer.ip if the attribute net.peer.name exist.
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.
Yeah, the other issue here is around whether we should be using net.peer.*
on RPC server-metrics.
We translated the specification on instrumentation from OpenCensus gRPC that lead to this as a basis. HOWEVER, there's a few caveats:
- In OpenCensus instrumentation + Views were separately specified. Instrumentation was thorough, views were more conservative. When this was originally written for OTEL the View spec wasn't known, so that part is unspecified. In OpenCensus, views are where the high cardinality issues were dealt with by use case, and where you could select styles of latency metrics to export (e.g. if you wanted SLO monitoring). I think the balance we struck 13 months ago is likely now wrong given the evolution of our APIs/SDKs unless we provide out-of-the-box VIew configuration for these metrics in addition to the rich instrumentation attributes.
- RPC semantic conventions now diverge from HTTP semantic conventions. Effectively.... "client" metrics use
net.peer.name
and "host" metrics should usehost.name
in HTTP, but RPC both usenet.peer
.
For both of these reasons, we may want to re-evaluate RPC metrics. Specifically RPC server metrics.
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.
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 I can modify the RPC conventions implement like this:
Client metrics use net.peer.name (or if unavailable net.peer.ip),net.peer.port,net.transport.
Server metrics use net.host.name (or if unavailable nethost.ip),net.transport,exclude net.host.port.
Do you think this is ok?
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.
That's effectively what I'd do.
For the purpose of this PR, I think if you just don't fill out any net.*
attributes on the server side you're fine (because of Resource attributes). As we discussed in the Java-SiG yesterday, it'd be good to mark this instrumentation as "experimental" in some fashion so you can try a few options out and we can see how they work in practice.
...pi/src/main/java/io/opentelemetry/instrumentation/api/instrumenter/rpc/RpcClientMetrics.java
Outdated
Show resolved
Hide resolved
...pi/src/main/java/io/opentelemetry/instrumentation/api/instrumenter/rpc/RpcClientMetrics.java
Outdated
Show resolved
Hide resolved
...pi/src/main/java/io/opentelemetry/instrumentation/api/instrumenter/rpc/RpcServerMetrics.java
Outdated
Show resolved
Hide resolved
...pi/src/main/java/io/opentelemetry/instrumentation/api/instrumenter/rpc/RpcServerMetrics.java
Outdated
Show resolved
Hide resolved
hi @trask I have added RpcClientMetricsTest and RpcServerMetricsTest similar to HttpClientMetricsTest and HttpServerMetricsTest |
// TODO(anuraaga): Remove await from this file after 1.8.0 hopefully fixes | ||
// https://github.com/open-telemetry/opentelemetry-java/issues/3725 |
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.
@anuraaga I tried removing awaits from HttpClientMetricsTest
/HttpServerMetricsTest
and it failed for me; looks like this issue is still not solved.
.put(SemanticAttributes.NET_TRANSPORT, "ip_tcp") | ||
.build(); | ||
|
||
Attributes responseAttributes2 = |
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 splitting this into 2 test cases? One for host name, one for IP.
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.
Yeah,according to @jsuereth suggestion,we should pefer to net.peer.name, we can fallback to net.peer.ip if net.peer.name is unavailable.
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.
this looks great, thx!
...pi/src/main/java/io/opentelemetry/instrumentation/api/instrumenter/rpc/RpcClientMetrics.java
Outdated
Show resolved
Hide resolved
...pi/src/main/java/io/opentelemetry/instrumentation/api/instrumenter/rpc/RpcServerMetrics.java
Outdated
Show resolved
Hide resolved
…tion/api/instrumenter/rpc/RpcServerMetrics.java
…tion/api/instrumenter/rpc/RpcClientMetrics.java
Thanks again @yangtaoran! |
* add metrics rpc conventions * handle format violations * handle format violations * resolve the comments suggestion * update RpcClientMetrics format * update RpcServerMetrics format * resolve time precision and cardinality issue * invoke buildServerFallbackView method * add RpcServerMetricsTest and RpcClientMetricsTest * server metrics attibutes remove net.perr* and add net.host * Update instrumentation-api/src/main/java/io/opentelemetry/instrumentation/api/instrumenter/rpc/RpcServerMetrics.java * Update instrumentation-api/src/main/java/io/opentelemetry/instrumentation/api/instrumenter/rpc/RpcClientMetrics.java Co-authored-by: Trask Stalnaker <trask.stalnaker@gmail.com>
No description provided.