-
-
Notifications
You must be signed in to change notification settings - Fork 414
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
Discussion: instrumenting servant-client
for OpenTelemetry
#1617
Comments
Looking into this further, it looks like we could build a |
In Golang world
|
That's been what we've been thinking after some further thoughts on this in the other thread on http-client as well: add some new hooks to Manager to do better instrumentation on that side. It seems like there's support for such a change to http-client so it mostly needs implementing. Those existing hooks are not enough to do it because they are not tied to the request lifecycle in the right way iirc. |
@lf- Do you know if there were any progress on this in |
Not to my knowledge. I don't personally have the resources to do it and I don't work in haskell full time anymore. |
It seems like I did a bad job of remembering to link the issue on that side. It's this one: snoyberg/http-client#494 |
Thank you. |
Hi! I'm a contributor to @iand675's hs-opentelemetry project, which does OpenTelemetry for Haskell.
If you're not familiar, OpenTelemetry lets people trace requests through distributed systems, with any number of services in them, which is very well aligned with use cases that Servant enables. It allows making spans for things that are happening at some point in time, as well as attaching metadata to them. I've used this technology at work to figure out why things are slow, for extracting database statements, and more.
For the
servant-server
side, OTel instrumentation is easy enough since you can instrument a Servant app at the WAI level, butservant-client
is currently not obvious how to instrument.There are two main things that I would like in a client implementation:
The reason this is hard without something in
servant-client
is that the current way thaths-opentelemetry-instrumentation-http-client
works is that it provides instrumentation-wrapped versions of http-client functions. From what I can tell, there's not a simple way to integrate that intoservant-client
without applying changes to it, since it directly callshttp-client
functions.It's possible that a Servant user could instrument requests by hacking up the HTTP manager by abusing the wrap exception functionality, but that would not account for the time for the server to send the response body.
Thus I'm asking here for ideas and feedback on how to best achieve this.
It would be possible to directly instrument
servant-client
at the source at very little cost to non-OpenTelemetry users usinghs-opentelemetry-api
. I'm not super convinced about that idea since there is no canonical OpenTelemetry library for Haskell sinceopentelemetry
also exists (for context, as I understand it,hs-opentelemetry
is built more strongly around the OTel library API spec compared toopentelemetry
).The text was updated successfully, but these errors were encountered: