-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Tracing: Migrate Google Cloud (Stackdriver) client to OpenTelemetry #4838
Tracing: Migrate Google Cloud (Stackdriver) client to OpenTelemetry #4838
Conversation
- Add method to create bridge tracer - Implement a sampler which enables us to force tracing Signed-off-by: Matej Gera <matejgera@gmail.com>
- Rename to Google Cloud, keep it backwards compatible - Refactor and move to OTEL exporter - Adjust factory to use bridge tracer for this provider Signed-off-by: Matej Gera <matejgera@gmail.com>
- to ensure force tracing / populate trace ID header works for the bridge tracer as well Signed-off-by: Matej Gera <matejgera@gmail.com>
Signed-off-by: Matej Gera <matejgera@gmail.com>
Signed-off-by: Matej Gera <matejgera@gmail.com>
Signed-off-by: Matej Gera <matejgera@gmail.com>
} | ||
|
||
if len(os.Args) > 1 { | ||
attr = append(attr, attribute.String("binary_cmd", os.Args[1])) |
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.
Why do we need to have binary Infos to attributes? Maybe remove this or at least make this configurable?
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.
Opentelemetry specification says lots of semantic_conventions , we should use it as possible. like process.executable.name
. https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/resource/semantic_conventions/process.md#process
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.
Honestly, this was purely to keep the behavior, attribute name etc. the same as it is now, as we wanted to make the change as 'backwards compatible' as possible. But yes, OTEL has more detailed guidance on semantic conventions and I'm definitely planning to follow them as we move the rest of the instrumentation to OTEL. However, if the feeling is that this can be changed already here, I'm happy to follow through.
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
💪 LGTM |
ping @yeya24 |
|
||
resource, err := resource.New(ctx, resource.WithAttributes(collectAttributes(serviceName)...)) | ||
if err != nil { | ||
level.Warn(logger).Log("msg", "detecting resources for tracing provider failed", "err", err) |
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.
If there is an error, should we return it or do we need to deal with it in line 67 as well?
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.
If there's an error, we should still receive valid (although possibly empty) resource
. I think best we can do is log warning and move on (or we can possibly change level to error
). I'll add a comment as well.
Would like to move this forward 😄 |
Signed-off-by: Matej Gera <matejgera@gmail.com>
Hey @yeya24 thanks for the ping. I updated the PR and also now updated OTEL to version However, after further testing, I'm noticing the traces get 'broken' between components 😞. For example when executing query -> receiver, it shows up as two distinct traces for each component - it gets 'split' on the store gRPC operation between client and server; I'm not sure exactly why, whether some changes are required to the middleware as well. I'll need more time to sort it out. |
@matej-g are you do inject span context to header in grpc/http client? like this https://github.com/open-telemetry/opentelemetry-go-contrib/blob/main/instrumentation/google.golang.org/grpc/otelgrpc/interceptor.go#L94 |
- Currently, bridge tracer supports only HTTP headers as a carrier.However, our instrumentation e.g. for gRPC uses metatada.MD as a carrier instead, breaking the propagatin. This fix works around it by 'converting' the carrier to HTTP header. See code docs for details. Signed-off-by: Matej Gera <matejgera@gmail.com>
Signed-off-by: Matej Gera <matejgera@gmail.com>
Apologies for the long delay on this one, but I needed to find a bit of time to pin this down. @hanjm I could not at first understand why the data was not being propagated, as you point out, but in the end I discovered that the OpenTelemetry's cc @yeya24 |
Overall LGTM, Thanks you. |
} | ||
|
||
if len(os.Args) > 1 { | ||
attr = append(attr, attribute.String("binary_cmd", os.Args[1])) |
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
go.mod
Outdated
go.opentelemetry.io/otel v1.3.0 | ||
go.opentelemetry.io/otel/bridge/opentracing v1.3.0 | ||
go.opentelemetry.io/otel/sdk v1.3.0 | ||
go.opentelemetry.io/otel/trace v1.3.0 |
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.
1.3.1 has released.
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.
Thanks, I'll update to latest version!
We should be good to go after fixing @hanjm 's comments 👍 |
Signed-off-by: Matej Gera <matejgera@gmail.com>
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
Changes
This is first in the series of PRs to start migrating our tracing from the OpenTracing packages to OpenTelemetry. This PR in particular moves Google Cloud provider to OpenTelemetry. In details:
Partially addresses #1972.
Verification
Tests have been updated; the change has been also verified manually by sending traces to Google Cloud.