-
Notifications
You must be signed in to change notification settings - Fork 36
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
Responsibilities of Tracer #89
Comments
I think |
From my experience of this lib so far, I do wonder if we should be able to use the tracer to extract the context on the client side for propagation. Something doesn't feel quite right about using the tracer to set the context with What I've ended up doing at $work is creating my own propagator capability which has an implementation that uses |
I tend to agree. The current propagation API is slightly cumbersome. I have at least two cases at $work, when I need to carry Carrying import org.typelevel.otel4s.java.instances.localForIoLocal
def middleware[F[_]: Tracer: Ask[*[_], Vault]](propagators: TextMapPropagators[F])(route: HttpRoutes[F]): HttpRoutes[F] = ???
IOLocal(Vault.empty).flatMap { implicit ioLocal: IOLocal[Vault] =>
IO.delay(GlobalOpenTelemetry.get).flatMap { global =>
val otel4s = OtelJava.local(global)
otel4s.tracerProvider.get("my.app").flatMap { implicit tracer: Tracer[IO] =>
val routes: HttpRoutes[IO] = middleware[IO](otel4s.propagators)(httpRoutes)
}
}
} Instead, we can define trait Tracer[F[_]] {
def propagate[A: TextMapUpdater](carrier: A): F[A]
} and the implementation is: def propagate[A: TextMapUpdater](carrier: A): F[A] =
for {
vault <- Ask[F, Vault].ask[Vault]
} yield propagators.textMapPropagator.injected(vault, carrier) Then, the example above can be simplified to: def middleware[F[_]: Trace](route: HttpRoutes[F]): HttpRoutes[F] = ???
OtelJava.global.flatMap { otel4s =>
otel4s.tracerProvider.get("my.app").flatMap { implicit tracer: Tracer[IO] =>
val routes: HttpRoutes[IO] = middleware[IO](otel4s.)(httpRoutes)
}
} |
Currently, we rely on OpenTelemetry Java implementation. You can use a builder to modify the autoconfigured SDK: import io.opentelemetry.context.propagation.{TextMapPropagator => JTextMapPropagator}
import io.opentelemetry.sdk.autoconfigure.AutoConfiguredOpenTelemetrySdk
private def createOpenTelemetry[F[_]: Sync]: F[OpenTelemetry] = Sync[F].delay {
AutoConfiguredOpenTelemetrySdk
.builder()
.addPropagatorCustomizer { (autoConfigured, _) =>
val customHeaderPropagator: JTextMapPropagator = ???
JTextMapPropagator.composite(
autoConfigured,
customHeaderPropagator
)
}
.setResultAsGlobal
.build()
.getOpenTelemetrySdk
} |
@iRevive that's interesting, I was wondering if I could just do it with OpenTelemetry, I'll give that a go. Thanks! |
where is the default (Java-based) implementation getting an instance of |
@NthPortal the |
@iRevive thanks! I'll look into wiring it through for a PoC implementation of |
PR is up for |
The |
The only thing the Otel specification requires of
Tracer
is that it has the span builder. We are also using it as the handle for the tracing context. We should explicitly decide whether to combine or separate these concerns.The text was updated successfully, but these errors were encountered: