haskell-servant / haskell-servant/servant

Discussion: instrumenting `servant-client` for OpenTelemetry

Open
#1,617 7 comments 0 reactions 0 assignees View on GitHub
Dominant language
Haskell
Stars
2k
Forks
427
Avg merge
2d 23h
Merged PRs (30d)
5

Description

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, but `servant-client` is currently not obvious how to instrument.

There are two main things that I would like in a client implementation:
* Propagation of the trace state via headers (so that the recipient server's part of the handling will land in the same trace)
* Instrumentation of how long the request took and what URL it was for

The reason this is hard without something in `servant-client` is that the current way that `hs-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 into `servant-client` without applying changes to it, since it directly calls `http-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](https://github.com/iand675/hs-opentelemetry/issues/8#issuecomment-1265855889).

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 using `hs-opentelemetry-api`. I'm not super convinced about that idea since there is no canonical OpenTelemetry library for Haskell since [`opentelemetry` also exists](https://github.com/ethercrow/opentelemetry-haskell) (for context, as I understand it, `hs-opentelemetry` is built more strongly around the OTel library API spec compared to `opentelemetry`).

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.