grpc-java: Unable to activate real-time metrics to OpenCensus

#5099 implemented a way to record real-time metrics. Cool! Now I’d like to activate it, as it’s disabled by default. I’m not successful in enabling this, however.

Tried with a NettyServerBuilder for example, but the setStatsRecordRealTimeMetrics method is protected.

I don’t see any other way to set the private attribute recordRealTimeMetrics in the AbstractServerImplBuilder class from the sources.

The work-around I’m using now is ugly in bypassing the protected attribute (Kotlin, but you get my point).

val serverBuilder = NettyServerBuilder.forPort(1234)
val setStatsRecordRealTimeMetricsMethod = NettyServerBuilder::class.java
    .getDeclaredMethod("setStatsRecordRealTimeMetrics", Boolean::class.java)
setStatsRecordRealTimeMetricsMethod.setAccessible(true)
setStatsRecordRealTimeMetricsMethod.invoke(serverBuilder, true)

after which it starts to work, except from the method name not being exported (but that’s #5593).

What version of gRPC are you using?

1.20.0

What did you expect to see?

A public function on the Builder to call setStatsRecordRealTimeMetrics(true).

About this issue

Original URL
State: open
Created 5 years ago
Comments: 15 (11 by maintainers)

Most upvoted comments

We discussed it further, and this is the approach we’re entertaining most strongly:

Add a CensusInterceptor in io.grpc.census. This can have whatever configuration is necessary when being created
Add a disableImplicitCensus() somewhere in io.grpc.census. If you don’t call this, then the two census interceptors would both be used. It must not be used from library code. We’d probably want a getter for code using CensusInterceptor directly to react
(Maybe) Have a setting on the Channel and Server to disable the implicit census interceptor

@gertvdijk, @mattnworb, would that work for you?

ejona86 on May 14, 2020

with the issue linked above complete (there is now a grpc-census), is there any way to enable recordRealTimeMetrics in a ServerBuilder?

mattnworb on May 5, 2020

Is this referring to library code (for example, something to set up a ChannelBuilder) should not disable the implicit interceptors since it will not know if the application adds or does not add the non-implicit ones?

Essentially, yes.

Since it is a global, it is really only “safe” for an application (e.g., the thing implementing main()) to change, since only the application has a full view of the expected configuration. Let’s say acme-super-fake-db is a library and used disableImplicitCensus(); a user that had a working Census setup would be quite peeved if adding a dependency on acme-super-fake-db disabled their Census stats.

ejona86 on May 15, 2020

Yeah, this was the thing that we were trying to discuss when #6577 was done.

I am thinking we could expose these knobs in grpc-census through global configurations (e.g., CensusStats.recordServerRealTimeMetrics) and these would be public APIs in grpc-census. Then we remove existing hidden methods in channel/server builders.

Normal Census users (with grpc-census in runtime classpath) would not be impacted as we set default values to what we are currently using. Advanced Census users would include grpc-census in compile classpath and use APIs to configure Census knobs.

The drawback is we are not able to configure each channel/server individually as the configurations are global. Making existing methods in grpc-core public also looks OK, but the API usage depending on runtime dependencies is a concern.

/cc @ejona86

voidzcy on May 7, 2020