Replies: 1 comment 1 reply
-
You're right, I also could not find an easy way to solve this. One way of doing it would probably to create a custom transport (or maybe use a transport from otel?) that can inject the appropriate HTTP header. Then, you can customize the http client with:
I think that should do the trick. |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Preflight checklist
Describe your problem
The tracing support in Hydra works great; we have it wired up so that Datadog collects traces (we're on 1.11.10). It's great.
However we noticed that although our delegate service (which handles the actual authentication bits) makes calls to Hydra, it does not appear in Hyda's traces. This is because we currently have no way to inject the trace ID into requests we make to Hydra. For example, here's how to inject the trace ID into a standard Go
http.Request
using opentracing.Inject:This is do-able because we have direct access to the headers submitted in the request. Alas, the Hydra Go client does not provide an interface to allow access to request headers. If there was an interface to allow for adding custom headers for every request, then just about any tracing library would be able to inject the necessary trace ID to ensure that all services show up in the traces.
Describe your ideal solution
This is a request for that interface, but also, if something needs to be done in Hydra itself to make sure that such IDs in requests it handles are propagated to the traces it emits, that would be the necessary other half. I suspect the most tracers enable this through middleware.
Workarounds or alternatives
No known alternatives; I poked around the Hydra Go client source but could not find any public access to the http.Request;
func (c *APIClient) prepareRequest
is obviously private.Version
1.11.10
Additional Context
Slack post and thread.
Beta Was this translation helpful? Give feedback.
All reactions