Migrate to new OpenCensus APIs for OpenTelemetry migration #7732
Comments
I didn't touch Protobuf and Netty; we upgrade those individually. Below are issues I encountered that caused me to not upgrade (further). Guava 30.1-android fails to build with Android without enabling desugaring. google/guava#5358 Robolectric 4.4 breaks AndroidChannelBuilderTest. grpc#7731 Opencensus 0.28.1+ is incompatible with gRPC. census-instrumentation/opencensus-java#2069 grpc#7732 Truth now defines the asm dependency as "compile" although it is still optional. But asm appears to have accidentally included incorrect gradle module metadata in their release (I see they've disabled the metadata on master) which make gradle think it requires Java 8. We could asm everywhere, but that's is annoying. It seems likely this will resolve itself. Mockito can be upgraded to 3.4.0, but it deprecates initMocks, which causes more code churn than I wanted in this commit. I still synchronized the example versions on 3.4.0, though, as it was already being used in some examples and the examples don't use initMocks.
I didn't touch Protobuf and Netty; we upgrade those individually. Below are issues I encountered that caused me to not upgrade (further). Guava 30.1-android fails to build with Android without enabling desugaring. google/guava#5358 Robolectric 4.4 breaks AndroidChannelBuilderTest. #7731 Opencensus 0.28.1+ is incompatible with gRPC. census-instrumentation/opencensus-java#2069 #7732 Truth now defines the asm dependency as "compile" although it is still optional. But asm appears to have accidentally included incorrect gradle module metadata in their release (I see they've disabled the metadata on master) which make gradle think it requires Java 8. We could asm everywhere, but that's is annoying. It seems likely this will resolve itself. Mockito can be upgraded to 3.4.0, but it deprecates initMocks, which causes more code churn than I wanted in this commit. I still synchronized the example versions on 3.4.0, though, as it was already being used in some examples and the examples don't use initMocks.
I didn't touch Protobuf and Netty; we upgrade those individually. Below are issues I encountered that caused me to not upgrade (further). Guava 30.1-android fails to build with Android without enabling desugaring. google/guava#5358 Robolectric 4.4 breaks AndroidChannelBuilderTest. grpc#7731 Opencensus 0.28.1+ is incompatible with gRPC. census-instrumentation/opencensus-java#2069 grpc#7732 Truth now defines the asm dependency as "compile" although it is still optional. But asm appears to have accidentally included incorrect gradle module metadata in their release (I see they've disabled the metadata on master) which make gradle think it requires Java 8. We could asm everywhere, but that's is annoying. It seems likely this will resolve itself. Mockito can be upgraded to 3.4.0, but it deprecates initMocks, which causes more code churn than I wanted in this commit. I still synchronized the example versions on 3.4.0, though, as it was already being used in some examples and the examples don't use initMocks.
|
I can't find any example how to instrument java grpc with OpenTelemetry api The only example I found is autoinstrumentation via aspects in opentelemetry-java-instrumentation, but that's works via java agent |
|
We just started migrating from opencensus to opentelemetry but grpc tracing does not work correctly. My understanding is that the opentelemetry maintainers have provided a shim that allows libraries such as gRPC to continue to use opencensus APIs (the shim converts these to OT under the hood). This means you don't need to change the gRPC code and users of gRPC just need to add the shim as a dependency. However, one problem is the usage of the gRPC context to store the current span etc. This is referenced in the following TODO (there may be others): The issue we see is that when using the shim, the root server side span (called "Recv.something") is not correctly recognized as the parent of other spans added in user code in the server. I suppose that happens because gRPC directly stores the span in a grpc context, but OT wants to use its own context management. Is there any chance that someone can look at this or give a little guidance on the minimal change to get things working? |
census-instrumentation/opencensus-java#2059 added some new APIs to be able to use the gRPC context or the OpenTelemetry context. That change breaks gRPC (census-instrumentation/opencensus-java#2069). Ignoring the breakage, we still want to figure out what changes we should make on our side and whether we can adopt the new API. We should also investigate what their migration looks like in the context of gRPC and its users.
Gribkoff, assigning to you for initial investigation, since this may influence your work. But I assume that before any larger changes we'd coordinate and determine who is appropriate.
The text was updated successfully, but these errors were encountered: