Adding logging environmental effect about zio-logging HOT 16 CLOSED

I'd prefer not to make the effect type polymorphic. At that point we're just trying to be a better log4cats, but it's far easier to own new markets than compete with existing ones.

from zio-logging.

I'd propose a slight modification on the above proposal:

trait AbstractLogging[Message] {
  def logging: AbstractLogging.Service[Message]
}
object AbstractLogging {
  trait Service[-R, -Message] {
    def info(message: Message): ZIO[R, Nothing, Unit]
    ...
  }
}
trait Logging extends AbstractLogging[String]
object Logging { type Service[-R] = AbstractLogging.Service[R, String] }

// In log-stage module:
trait StructuredLogging extends Logging[Message]
object StructuredLogging { type Service[-R] = AbstractLogging.Service[R, Message] }

Possibly we should add something like MDC:

  trait Service[-R, Message] {
    def context: FiberRef[Map[String, Message]]
    def info(message: Message): ZIO[R, Nothing, Unit]
    ...
  }

Then the context can be adjusted, although mapping that to MDC is obviously a lot of work and the subject of a pending PR.

Then the last point is whether or not to support the creation of loggers based on classes, etc., or whether "global loggers" are sufficient.

from zio-logging.

Oh, I know... I meant to point out that you are welcome to take whatever I have in that repo.
It would come down to implementations of Logger.Service on how each framework handles the actual logging, of course.

from zio-logging.

In our case we create a logger with custom context containing requestid and passing it further explicitly. Though I'm not trying to say that it's the best option possible, just easiest.

from zio-logging.

I don't think it hurts to have context, since we can always "compile that away" for logging implementations that don't support it (that is, embed context, if present, into the strings / messages passed to underlying implementation). Context, however, strikes me as an 80% solution: simple, good enough for the common case, and easily understandable.

from zio-logging.

@thiloplanz As mentioned by @jdegoes, there is a pending PR that allows FiberRefs to be read unsafely from side effecting code - basically allowing the "mapping magic" you mentioned above. A proof of concept implementation of fiber aware MDC logging for log4j2 based on a slightly outdated version of the aforementioned PR can be found here.

from zio-logging.

This is a good idea. Are we trying to get this done in time for release 1.0?

from zio-logging.

This wouldn't work for our structured logging solution. I would propose this as a starting point:

trait Logging[F[_], Message] {
 def info(message: Message): F[Unit] 
  //... 
}

trait UnstructuredLogging[F[_]] extends Logging[F, String] 


// `Message` is a data structure with an implicit materializer from LogStage

trait StructuredLogging[F[_]] extends Logging[F, Message] {

}

Also we may wish to add withCustomContext method - logstage users found it a very useful feature.

Some references to the code which we may wish to reuse:

1. The structure extraction macro
2. The structured logger message
3. Context API usage example

from zio-logging.

Looks remarkably similar to https://github.com/NeQuissimus/zio-slf4j/blob/master/src/main/scala/logger.scala ?

I use https://github.com/NeQuissimus/zio-slf4j/blob/master/src/main/scala/package.scala#L8 to turn any A into something log-able...

from zio-logging.

@NeQuissimus yes it is very similar. we would like to have very simple interface that can be back up with slf4j and other implementations. Moreover we would like to avoid dependencies to scalaz if possible.

from zio-logging.

@pshirshov why we need F[_] ? I was thinking that ZIO would be enough in this case. We try to keep this interface very simple.

from zio-logging.

It's not neccessary to make it polymorphic, though it may be very useful at least for those who wish to reuse the same logger for any code outside of ZIO so they may put identity there. We have our own typeclass wrapping ZIO for basic usecases and in general it's very useful. Though I don't insist (but I still think it may be a very good idea to build a hierarchy of typeclasses)

from zio-logging.

Then the last point is whether or not to support the creation of loggers based on classes, etc., or whether "global loggers" are sufficient.

A macro can do it. Also we may provide a classic way to define location specifically for Logging

Then the context can be adjusted, although mapping that to MDC is obviously a lot of work and the subject of a pending PR.

I don't think that MDC-like approach is a good thing. Just custom-provided contexts are very efficient (and very easy to handle and debug). def apply(userContext: (String, String)*): AbstractLogging should be just fine for 95% of the usecases (IMO) - user can always pass a logger bound to custom context while spawning a fork.

from zio-logging.

@pshirshov how would you handle things like request-id/correlation-id without MDC-like approach?

from zio-logging.

Having the Logging service explicitly support context instead of passing it around separately seems much better to me, not only for reduced boilerplate, but also (and probably more importantly) because a Logging implementation could then also integrate that context with the MDC capabilities of the underlying logging backend, so that not only our own ZIO-aware application code benefits from it, but all that low-level code that we call into and that in turn logs via SLF4J directly would also pick up our "correlation id" and include it in their logging output.

That FiberRef <-> MDC <-> ThreadLocal mapping magic would be the most important feature for me.

from zio-logging.

I have a logging library https://github.com/leigh-perry/log4zio that might be a useful starting point for zio-logging. Its main selling point is contravariant-functor-style composition of loggers. It is ZIO-based without dependencies on Cats or Scalaz.

It is in line with @jdegoes initial sketch at the top of this issue.

from zio-logging.