otel: add tcp metrics by AgraVator · Pull Request #12652 · grpc/grpc-java

AgraVator · 2026-02-11T07:25:38Z

Implements A80

core/src/main/java/io/grpc/internal/ClientTransportFactory.java

netty/src/main/java/io/grpc/netty/NettyServer.java

netty/src/main/java/io/grpc/netty/TcpMetrics.java

sauravzg · 2026-02-17T10:20:18Z

netty/src/main/java/io/grpc/netty/TcpMetrics.java

+      java.util.List<String> labelValues = getLabelValues(channel);
+      try {
+        if (channel.getClass().getName().equals(epollSocketChannelClassName)) {
+          Class<?> tcpInfoClass = Class.forName(epollTcpInfoClassName);


This is quite a lot of reflection in hot exporting path. So, a couple of questions.

Why do we choose reflectin over typecasting and calling actual methods? Reducing dependency surface?

Is there a way to optimise this like caching value on per channel level? Something like a creating a runnable per channel. Not sure how it'd be possible to share this data for the final collection on channel inactive.

sauravzg · 2026-02-17T10:20:21Z

netty/src/main/java/io/grpc/netty/TcpMetrics.java

+          Method rttMethod = tcpInfoClass.getMethod("rtt");
+
+          long totalRetrans = (Long) totalRetransMethod.invoke(info);
+          int retransmits = (Integer) retransmitsMethod.invoke(info);


Are these cumulative metrics or are these total retransmits since the connection start? If latter, the current logic is incorrect.

AAh I see, then I think we should not be using a counter for this... Will clarify in the gRFC

ejona86

"otel" is a very surprising prefix to use for the PR/commit, as opentelemetry isn't actually changed at all.

netty/src/main/java/io/grpc/netty/NettyServerBuilder.java

core/src/main/java/io/grpc/internal/ClientTransportFactory.java

core/src/main/java/io/grpc/internal/InternalServer.java

netty/src/main/java/io/grpc/netty/TcpMetrics.java

…ddress PR comments)

The backoff timer is only used when serializeRetries=true, and that exists to match the old/current pick_first's behavior as closely as possible. InternalSubchannel.updateAddresses() would take no action when in TRANSIENT_FAILURE; it would update the addresses and just wait for the backoff timer to expire. Note that this only impacts serializeRetries=true; in the other cases we do want to start trying to the new addresses immediately, because the backoff timers are in the subchannels. Note that this change was also important because requestConnection() can be directly triggered by the user with channel.getState(true), and that shouldn't defeat the backoff timer.

Since we're only supporting API levels 23+, all the supported Android versions handle multidex natively, and without any bugs to workaround. Also bump some minSdkVersion that didn't get updated in fa7b52b so that multiDex is actually enabled by default. See also b/476359563

… and 'core: Wait for backoff timer on address update in pick_first'

ejona86

The PR description's "Implements A80" doesn't link to the gRFC; it just links to this PR.

ejona86 · 2026-03-09T15:21:12Z

okhttp/src/test/java/io/grpc/okhttp/OkHttpTransportTest.java

-        .setTransportTracerFactory(fakeClockTransportTracer)
-        .buildTransportServers(streamTracerFactories);
+        .setTransportTracerFactory(fakeClockTransportTracer);
+    return InternalOkHttpServerBuilder


You don't need to use InternalOkHttpServerBuilder; buildTransportServers() is package-private... the code was already calling it directly.

netty/src/main/java/io/grpc/netty/NettyServerBuilder.java

api/src/main/java/io/grpc/ServerBuilder.java

api/src/main/java/io/grpc/InternalTcpMetrics.java

api/src/main/java/io/grpc/ServerBuilder.java

netty/src/test/java/io/grpc/netty/NettyClientTransportTest.java

netty/src/main/java/io/grpc/netty/TcpMetrics.java

ejona86 · 2026-03-12T14:03:46Z

netty/src/main/java/io/grpc/netty/TcpMetrics.java

+        totalRetransMethod = epollTcpInfoClass.getMethod("totalRetrans");
+        retransMethod = epollTcpInfoClass.getMethod("retrans");
+        rttMethod = epollTcpInfoClass.getMethod("rtt");
+      } catch (Exception | Error t) {


Please use precise error handling. What specific exceptions are expected here?

Why are we catching Error and RuntimeException? Are they expected for some reason?

ejona86 · 2026-03-24T23:34:45Z

netty/src/main/java/io/grpc/netty/TcpMetrics.java

+        totalRetransMethod = epollTcpInfoClass.getMethod("totalRetrans");
+        retransMethod = epollTcpInfoClass.getMethod("retrans");
+        rttMethod = epollTcpInfoClass.getMethod("rtt");
+      } catch (Exception | Error t) {


Why are we catching Error and RuntimeException? Are they expected for some reason?

netty/src/main/java/io/grpc/netty/TcpMetrics.java

api/src/main/java/io/grpc/NameResolver.java

core/src/test/java/io/grpc/internal/ServerImplBuilderTest.java

netty/src/main/java/io/grpc/netty/NettyServerHandler.java

netty/src/test/java/io/grpc/netty/NettyServerHandlerTest.java

ejona86 · 2026-03-25T00:04:38Z

netty/src/test/java/io/grpc/netty/TcpMetricsTest.java

+
+    FakeEpollTcpInfo infoSource = new FakeEpollTcpInfo();
+    infoSource.setValues(123, 4, 5000);
+    ConfigurableFakeWithTcpInfo channel = org.mockito.Mockito.spy(


Don't use spy. Ever. It is implemented in a horribly evil way that invalidates any potential use-case for it. (It blindly copies fields from a constructed instance to a new instance that it creates.) Generally you can use a normal mock with delegatesTo(realObj) instead. If that isn't applicable, you get to rethink things.

ejona86 · 2026-03-25T00:10:18Z

netty/src/test/java/io/grpc/netty/TcpMetricsTest.java

+
+    FakeEpollTcpInfo infoSource = new FakeEpollTcpInfo();
+    infoSource.setValues(123, 4, 5000);
+    ConfigurableFakeWithTcpInfo channel = org.mockito.Mockito.spy(


Did you try actually using EmbeddedChannel instead of mocking? It looks like you're mocking this so you can fake time. I think you can do that directly with EmbeddedChannel.

ejona86 · 2026-03-25T00:12:46Z

netty/src/test/java/io/grpc/netty/TcpMetricsTest.java

+  @Mock
+  private MetricRecorder metricRecorder;
+  @Mock
+  private Channel channel;


Do we really need a mock/spy here? It is really bad practice to mock out classes that aren't your own, as mocks lie and don't follow normal API guarantees when changes are made.

It looks like you're using this to override local addresses and such. Can you try using EmbeddedChannel for that?

(Note: For "real" tests, EmbeddedChannel doesn't act like a real channel well enough to be trusted too much. So we tend to prefer LocalChannel. But in this case, you want specific address types, and don't actually care about a lot of the lifecycle things that EmbeddedChannel gets wrong, so it is a fair choice.)

servlet/src/jettyTest/java/io/grpc/servlet/JettyTransportTest.java

AgraVator closed this Feb 11, 2026

AgraVator reopened this Feb 11, 2026

AgraVator marked this pull request as ready for review February 16, 2026 16:14

sauravzg reviewed Feb 17, 2026

View reviewed changes

core/src/main/java/io/grpc/internal/ClientTransportFactory.java Show resolved Hide resolved

sauravzg reviewed Feb 17, 2026

View reviewed changes

netty/src/main/java/io/grpc/netty/NettyServer.java Show resolved Hide resolved

sauravzg reviewed Feb 17, 2026

View reviewed changes

netty/src/main/java/io/grpc/netty/TcpMetrics.java Show resolved Hide resolved

sauravzg reviewed Feb 17, 2026

View reviewed changes

netty/src/main/java/io/grpc/netty/TcpMetrics.java Outdated Show resolved Hide resolved

sauravzg reviewed Feb 17, 2026

View reviewed changes

netty/src/main/java/io/grpc/netty/TcpMetrics.java Outdated Show resolved Hide resolved

sauravzg reviewed Feb 17, 2026

View reviewed changes

AgraVator requested a review from ejona86 February 26, 2026 09:54

ejona86 reviewed Feb 27, 2026

View reviewed changes

AgraVator force-pushed the tcp-metrics branch from 2990c28 to 05fc150 Compare March 6, 2026 18:58

feat: Implement TCP metrics collection and pipeline MetricRecorder (A…

4082b2d

…ddress PR comments)

AgraVator force-pushed the tcp-metrics branch from 05fc150 to 716eb36 Compare March 6, 2026 19:03

suggested changes

a8b66f4

AgraVator force-pushed the tcp-metrics branch from 716eb36 to a8b66f4 Compare March 6, 2026 19:11

AgraVator and others added 6 commits March 9, 2026 14:21

fix: format and BinderServerBuilder

1ee21f3

fix: logs and plumb metric sink

20c614f

fix: otel test

9dfa829

Revert 'android-interop-testing: Remove usage of MultiDexApplication'…

2fda6fa

… and 'core: Wait for backoff timer on address update in pick_first'

AgraVator requested a review from ejona86 March 11, 2026 09:52

AgraVator added 2 commits March 11, 2026 15:32

fix: make metric recorder non null and register metrics unconditionally

b12a433

fix: revert non-nullable metric recorder in orca

d8180d6

ejona86 reviewed Mar 12, 2026

View reviewed changes

AgraVator mentioned this pull request Mar 13, 2026

ServerBuilder.addMetricSink() is experimental #12693

Open

fix: suggested changes

20f1d73

AgraVator requested a review from ejona86 March 18, 2026 08:52

ejona86 reviewed Mar 25, 2026

View reviewed changes

Conversation

AgraVator commented Feb 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ejona86 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

ejona86 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

AgraVator commented Feb 11, 2026 •

edited

Loading