googleapis
all: Support OpenTelemetry for traces exported from client methods
Right now Cloud client libraries for Go have direct integration with OpenCensus, which is an amazing feature.
However, the Google recommendation is to use OpenTelemetry at this point:
Cloud Trace recommends using OpenTelemetry. OpenTelemetry is an open-source product from the merger between OpenCensus and OpenTracing. OpenTelemetry is an open-source product from the merger between OpenCensus and OpenTracing.
(I do not agree with this and I listed why at http://doc/1R82XXlE8dVt1C-kLYRH2gFLVCzSgKiRna0yroZTsjhs which is an internal friction log for reasons.)
Right now, if you use cloud.google.com/go packages but you have instrumented your app using OpenTelemetry, you can get traces using the opencensus-bridge which largely works (you just pay attention to not get yourself in an infinite loop).
So this is not very urgent, however we should probably do this in the long term since OT will be way to Go and it's better to come up with a migration plan (that is graceful to OpenCensus users) sooner than later.
Thanks for the request @ahmetb. I am going to close this issue in favor of #4234 which was opened just earlier today. If you want to add extra details in that issue feel free 😄
They don't look like the same thing though? That's about instrumenting streaming RPCs, this is about using a different instrumentation framework. @codyoss
Yes they are different but I guess I see them as getting, most likely, solved at the same time with a wholistic approach. I will reopen this issue for now though.
The fact that Spanner is still integrating with OpenCensus is the reason why we haven't moved to OpenTelemetry yet.
Hello, just wondering what the current status is of this work? If it is tracked somewhere publicly would it be possible to add a link here so we can see how far this issue has progressed since it was opened more than 2 years ago?
@dustinmoris Are you currently using the Go client libraries in an application that you wish to migrate to OpenTelemetry? If so, have you tried using the OpenTelemetry-Go - OpenCensus Bridge?
I will try that, thanks for making me aware of the bridge. Still wondering when all the Go GCP libraries will natively integrate with OpenTelemetry since OpenCensus has been superseded by OpenTelemetry. If the bridge works it's obviously not a super pressing issue, but nevertheless would be nice to know a rough plan of when you think this will be delivered?
Hopefully we will be able to announce a timeline soon for OpenTelemetry tracing support, but we can't promise any specific timeline yet.
If you get the chance to try out the bridge with a production application, please post a short summary of your experience here. I recently tried it myself in a demo app with Cloud Trace as the backend. I did not have any problems, but I would love to get wider confirmation from users of the Google Cloud Go client libraries.
Here are some resources:
- Sunsetting OpenCensus
- OpenTelemetry-Go - OpenCensus Bridge
- What is OpenTelemetry?
- Cloud Trace - Go and OpenTelemetry
- On GCE, use Ops Agent and OpenTelemetry
I've added the OpenCencus Bridge last night and so far it's looking good. 👍
FWIW The OpenCensus Bridge is working well in our GKE workloads at Khan Academy.
Please see timeline and instructions for transition to OpenTelemetry tracing here:
https://github.com/googleapis/google-cloud-go/blob/main/debug.md#opencensus
@quartzmo Hi! Are you saying that the OpenCensus Bridge is no longer needed, and by just setting GOOGLE_API_GO_EXPERIMENTAL_TELEMETRY_PLATFORM_TRACING=opentelemetry, one can record traces for Spanner and Storage? Or even with GOOGLE_API_GO_EXPERIMENTAL_TELEMETRY_PLATFORM_TRACING=opentelemetry specified, is the OpenCensus Bridge still required?
@sonatard OpenCensus Bridge is only needed to support components in your application other than these client libraries that use OpenCensus. The Go client libraries now use OpenTelemetry by default. See https://github.com/googleapis/google-cloud-go/blob/main/debug.md#opencensus for more details.