Skip to content
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

Support for Future? #210

Closed
marylin13 opened this issue May 11, 2023 · 4 comments
Closed

Support for Future? #210

marylin13 opened this issue May 11, 2023 · 4 comments

Comments

@marylin13
Copy link

Does this project have any plan to support trace for Future? Or is it a good idea to extend it to support Future?
I believe for projects that use akka ecosystem is really useful.

Thanks

@rossabaker
Copy link
Member

Short answer

No.

Pedantic answer

The interfaces are in a "tagless final" style, and can work with anything of kind F[_], that is, any type that takes one parameter. Like Future!

The existing implementations use type class constraints. One, Tracer.noop[F], requires an instance of cats.Applicative[F]. That exists for Future, so you can do Tracer.noop[Future] and get a tracer that returns Futures. The problem is, as the name implies, noop doesn't do anything.

Another implementation comes via OtelJava.local[F], which requires an Async[F]. In Cats Effect, we take our side effects -- like recording traces -- and suspend them by wrapping them up. There is no Async[Future], because Future runs eagerly and can't suspend side effects. The forthcoming all-Scala implementation will have the same problem with Future.

So, it's already supported ... as long as you don't actually want the traces.

Side effects, schmide effects. I just want to trace my Akka!

You could implement the Otel4s interface for Future. And you could reuse every piece of Otel4s that uses nothing stronger than MonadError[F, Throwable] to build it. But Otel4s uses Cats Effect and provides implementations such that are "referentially transparent", or more easily composable, refactorable, reasonable, and optimizable. An Tracer[Future] would be the same shape as other Tracer[F], but with a mostly different implementation and substantially different axioms. It would work fine within those axioms, but it wouldn't really be Otel4s.

Bummer. Is there anything else I can do?

If you have IO on the outside and can treat Akka as a single span, you can call IO.fromFuture`.

Alternatively, you can use the Java SDK. There is some instrumentation for akka-http already. And there is an ongoing discussion to improve Java SDK interop in Otel4s. This is probably your best bet, but I can't speak to the depth of the existing Akka instruementation.

@IvannKurchenko
Copy link

@mary-element I assume what you are looking for is Kamon or Akka OTEL instrumentation.

@marylin13
Copy link
Author

marylin13 commented May 12, 2023

@IvannKurchenko not really.
We choose to not use Kamon for some reason.
Do mean the Otel java auto instrument for "Akka OTEL instrumentation"? I actually also need to do manual instrument for both methods return Future and IO.

@iRevive
Copy link
Contributor

iRevive commented Jan 29, 2024

Do mean the Otel java auto instrument for "Akka OTEL instrumentation"? I actually also need to do manual instrument for both methods return Future and IO.

There is a way to enable Akka instrumentation, but you need to use the agent:
https://opentelemetry.io/docs/languages/java/automatic/agent-config/

As mentioned above, we don't have plans to support Future.

@iRevive iRevive closed this as completed Jan 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants