-
Notifications
You must be signed in to change notification settings - Fork 40
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
sdk-trace: add SimpleSpanProcessor
#388
sdk-trace: add SimpleSpanProcessor
#388
Conversation
459c456
to
9595a0f
Compare
|
||
private def doExport(span: SpanData): F[Unit] = | ||
exporter.exportSpans(List(span)).onError { | ||
case e if NonFatal(e) => |
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.
You never need non-fatal checks within the effect, if a non-fatal error has been countered the JVM has already terminated 😁
Also onError
just-side-channels, so the error continues being raised. Wouldn't this possibly lead to duplicate error reporting?
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.
Good point. Let's not propagate errors, at least for now. We can reconsider the choice once we have the fully working SDK in place.
_ <- Console[F].errorln("SimpleSpanExporter: the export has failed") | ||
_ <- Console[F].printStackTrace(e) |
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.
One unfortunate thing about logging in two steps it that it may be come separated if there are other interleaving logs. It might be better to make a new exception that is caused by e
and log that, or assemble the string + stacktrace first and then log it atomically.
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.
By the way, does it make sense to introduce a separate interface for logging? For example:
trait Log[F[_]] {
def info(message: => String): F[Unit]
def error(message: => String): F[Unit]
def error(message: => String, error: => Throwable): F[Unit]
}
We will use the cats.effect.std.Console
by default. But a user can plug in any other logging backend: log4cats, odin, scribe, etc.
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 all starts to feel rather circular 😅
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 tend to agree. Console
should be more than enough for our use cases (at least now 😏 ).
2201366
to
cb534e6
Compare
I also moved
SpanProcessor
to theorg.typelevel.otel4s.sdk.trace.processor
package.