-
Notifications
You must be signed in to change notification settings - Fork 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
Default span propagation for tracing in builders #156
Comments
I'm also getting |
@xd009642 you can also look at the the |
slightly, though I kinda thought it would be possible to do this with just tracing and what tonic already has? I'm currently reading up some docs to try and figure it all out in my mind before asking a bunch of stupid questions 😄 |
Oh I see the grpc-trace-bin format is defined by different tracing services like opencensus etc. So I suppose I could take a And of course whether the span name is actually standardised in any way between the different tracing things... |
This was done in #175 |
Sorry for the necrobump, but I'm trying to wrap my head around #175. I get that PR adds a And similarly, how do I get a tonic client to (always?) inject its current trace ID as a trace ID into the metadata? Is this something for tonic to provide? Or are there other crates that do this, and I'm just missing the link? |
Hmmh, #1184 is probably the better place to discuss this. Sorry for the noise! |
Following on from jtescher/opentelemetry-rust#17
It would be useful if the server and client builders provided a default implementing for propagating parent spans via the
grpc-trace-bin
header. Currently I have something similar to this for a service I'm working on using https://github.com/census-instrumentation/opencensus-go/blob/17d7955af9d42886455ce010dd46878208041a58/plugin/ocgrpc/trace_common.go as a reference for how it's typically done in other languages:The ugly match is because the span name needs a static lifetime so if there was also a static string representing the
package.service.name
identifier in the generated grpc code that would be useful as well.The text was updated successfully, but these errors were encountered: