add tracing support with Natchez#44
Conversation
| context: Context, | ||
| routes: HttpRoutes[IO]): IO[Some[ApiGatewayProxyStructuredResultV2]] = | ||
| routes: HttpRoutes[IO])( | ||
| implicit T: Trace[IO]): IO[Some[ApiGatewayProxyStructuredResultV2]] = |
There was a problem hiding this comment.
How does this Trace propagate to userland code? Apologies if I'm missing something.
There was a problem hiding this comment.
No, good catch. I've only made changes to IOLambda and the IOLambdaPlatforms to make sure it worked at that level. We'd need to add the implicit Trace to the other abstract methods if we want to do this consistently.
There was a problem hiding this comment.
Aha, I thought it might be using some IOLocal magic :)
There was a problem hiding this comment.
I need to think a little more on how the ApiGatewayProxyHttp4sLambda fits in here. (Open to suggestions if you see a way to do it with the current structure.)
We may need to change routes to be def routes: Resource[IO, HttpRoutes[Kleisli[IO, Span[IO], *]]]? But even that doesn't fit perfectly if all we have here is the implicit Trace[IO]. Not sure yet.
There was a problem hiding this comment.
There's this https://github.com/tpolecat/natchez-http4s
There was a problem hiding this comment.
I kind of punted and added the Natchez server middleware to ApiGatewayProxyHttp4sLambda. The main problem I see is that doesn't make the Trace[IO] capability available to anything defined in def routes: Resource[IO, HttpRoutes[IO]], meaning I'm not sure how application code could open its own spans or propagate the trace onwards if it makes calls to other services.
@armanbilge it looked like you started a new branch that (from the commit messages) might be reworking the structure a little bit to help with this. I'm going to pause here to see what you come up with. 🙂
armanbilge
left a comment
armanbilge
left a comment
There was a problem hiding this comment.
This is cool! Still gotta wrap my head around all the pieces 😅
| } | ||
|
|
||
| override protected def traceRootSpan(name: String): Resource[IO, Span[IO]] = | ||
| Resource.eval(XRayEnvironment[IO].kernelFromEnvironment).flatMap { kernel => |
There was a problem hiding this comment.
This strategy for extracting the kernel might only apply to normal AWS Lambdas—e.g. for ApiGatewayProxyHttp4sLambda the kernel should probably be extracted from the incoming HTTP request headers, not the Lambda's environment. 🤔
|
I'm going to close this PR in favor of one of the other open tracing PRs—it has served its purpose 🙂 |
2 participants
I've been using this with a locally published version of christiankjaer/natchez#1 and typelevel/natchez#427 and it seems to work.
My thought is that we can bake in no-op tracing, and then the user can mix in a trait that implements tracing for their preferred backend. It doesn't compile here yet (because of the missing artifacts) but the
XRayTracingtrait is an example of how that could work. WDYT?