go-grpc-middleware
go-grpc-middleware copied to clipboard
grpc-ecosystem
Exemplars support: Add ability to include trace ID
Hello 👋
Is there any way currently (I haven't been able to find it yet) to include the Trace ID as part of the interceptor to be able to make use of Prometheus Exemplars? If not, are there plans to add this?
Thank you and sorry if I missed something obvious! @bwplotka @brancz
Totally! However, it's mainly for Prometheus part that is now developed here https://github.com/grpc-ecosystem/go-grpc-middleware/tree/v2, I will migrate your issue there if that's fine (:
There is no request yet, but thanks for raising it, definitely help wanted on that.
We are planning to add exemplars to HTTP middleware too: https://github.com/prometheus/client_golang/issues/854 so Ideally we can follow similar pattern. One point is that Go tracing client lib for OpenTelemetry is not yet stable, so we might want to wait on that, unless we want to abstract that away (probably good idea)
Thank you! Is there a need to tie the OpenTel client lib to this repo, or can we make the ID generic somehow like you suggested with abstracting it away?
I would definitely keep it generic, but would be interesting to mix tracing and metrics libs together (:
Can we just add tracing to client_prometheus? 🙈 cc @kakkoyun
I would definitely keep it generic, but would be interesting to mix tracing and metrics libs together (:
I fear that would cause go.mod dep issues, so if possible to keep those separate would be ideal.
What are the actual things we need to do, I was under the impression we would "just" need to add a trace ID as label key/value, and that is not specific to OpenTel? But again I can be very wrong, didn't get a chance to deep dive into it.
Well, the main question is where you get this trace ID from. Then the question is do you want to put trace that is sampled? How do we know that etc.
We can of course just allow user to specify this but again, some example implementation using Otel, Opentracing would be helpful (see v2, we have multiple modules for this)
The way I understand it is that this library should just use the w3c trace context, which opentelemetry happens to support, but is ultimately independent of any specific tracing implementation, which seems like the right fit for a library like this I would say.
