-
Notifications
You must be signed in to change notification settings - Fork 37
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
Implement tracing API #37
Conversation
# Conflicts: # core/src/main/scala/org/typelevel/otel4s/trace/Span.scala
# Conflicts: # core/src/main/scala/org/typelevel/otel4s/trace/SpanFinalizer.scala
# Conflicts: # build.sbt
# Conflicts: # build.sbt
# Conflicts: # build.sbt # core/src/main/scala/org/typelevel/otel4s/trace/Span.scala
# Conflicts: # build.sbt
# Conflicts: # .github/workflows/ci.yml # build.sbt # core/tracing/src/main/scala/org/typelevel/otel4s/trace/SamplingDecision.scala # core/tracing/src/main/scala/org/typelevel/otel4s/trace/Span.scala # core/tracing/src/main/scala/org/typelevel/otel4s/trace/SpanBuilder.scala # core/tracing/src/main/scala/org/typelevel/otel4s/trace/SpanContext.scala # core/tracing/src/main/scala/org/typelevel/otel4s/trace/SpanFinalizer.scala # core/tracing/src/main/scala/org/typelevel/otel4s/trace/Tracer.scala
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems to me that most of the implementation could be private[java]
, which would give us a lot more flexibility to refactor once bincompat constraints become a thing.
java/tracing/src/main/scala/org/typelevel/otel4s/java/trace/SpanBackendImpl.scala
Outdated
Show resolved
Hide resolved
java/tracing/src/main/scala/org/typelevel/otel4s/java/trace/SpanBackendImpl.scala
Outdated
Show resolved
Hide resolved
java/tracing/src/main/scala/org/typelevel/otel4s/java/trace/SpanBuilderImpl.scala
Outdated
Show resolved
Hide resolved
java/tracing/src/main/scala/org/typelevel/otel4s/java/trace/SpanBuilderImpl.scala
Outdated
Show resolved
Hide resolved
java/tracing/src/test/scala/org/typelevel/otel4s/java/trace/SpanNode.scala
Outdated
Show resolved
Hide resolved
): SpanBuilder[F] = | ||
copy(finalizationStrategy = strategy) | ||
|
||
def createManual: F[Span[F]] = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this naming make sense since we do not have Span.Auto
and Span.Manual
anymore?
Since it's a builder, the create
part somewhat makes sense. On the other hand, the side effect of a starting span is happening under the hood.
From my point of view, we should advertise the fully managed lifecycle of a span Resource[F, Span[F]]
as a preferred option.
Some options:
start: Resource[F, Span[F]]
andstartUnmanaged: F[Span[F]]
create: Resource[F, Span[F]]
andcreateUnmanaged: F[Span[F]]
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I like start
and startUnmanaged
, for the verbal symmetry with end
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the feedback. I renamed the methods.
# Conflicts: # .github/workflows/ci.yml # build.sbt
…teManual` -> `SpanBuilder.startUnmanaged`
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is wonderful!
I'm making Otel a top priority at $WORK. I would love to do a preview release this week so more people can start instrumenting and see what feels good and what still needs work.
The module name is |
Good catch. I renamed sbt modules. |
* Define tracing API * Add `spanBuilder` to `Tracer`. Better naming of `SpanContext` members * Rename `SamplingStrategy` -> `SamplingDecision` * Update scaladoc. Add `SpanFinalizer` * Fix scaladoc * Implement tracing API * Improve Scaladoc * Improve Scaladoc * Better phrasing * Docs cleanup * Properly handle 'noop' scope * Hide implementation of `SpanFinalizer` * Docs update * Replace `asChildOf` with `childScope` and `withParent` * Add `withParent` to `SpanBuilder` * Replace `childOf` with `childScope` in `Tracer` * Make `Span` always return `SpanContext` * Test propagation of trace info over stream scopes * Make `Span` always have a `SpanContext` * Add `setAttribute` method to `Span` * Use `IO.to` syntax * Update layout * Run `sbt githubWorkflowGenerate` * Update layout * Revert redundant changes * Cleanup * Run `sbt githubWorkflowGenerate` * Update layout * run `scalafixAll` * Implement `Span#setAttribute` via macro * Fix method name * Update implementation * Minor cleanup of `build.sbt` * Remove duplicated `munit` dependency * Discard statement instead of calling `void` * Hide implementation details behind `package[java]` * Rename `withAttribute` -> `addAttribute` * Merge upstream * Rename `SpanBuilder.create` -> `SpanBuilder.start`, `SpanBuilder.createManual` -> `SpanBuilder.startUnmanaged` * Rename sbt modules `tracing` -> `trace` Co-authored-by: Ross A. Baker <ross@rossabaker.com>
The implementation of the tracing API using the OpenTelemetry java library.
Notable changes:
Span
trait moved to the Scala-specificSpanMacro
IOLocal
Currently, the scope is stored in
IOLocal
. This approach has several drawbacks:interruptScope
andIOLocal
s fs2#2842