Logging with akka. app design - multithreading

Question

Suppose I have scala app that is based on Futures, on scala.concurrent to handle the asyn / concurency (no actors were used so far).
In many places I use log4j for loggining stuff into log file.
Since it is I/O I suppose I may improve performance by sending the log message to LoggingActor
something like this:
def stuffTodo(arg:String)(implicit ex:ExecutionContext) : Future[Result] = {
// important performant work
// ..
logAcrot ! LogMessage("message-1")
// ...
}
where msg: case class LogMessage(msg:String, implicit ex:ExecutionContext)
then in ActorLog
def receive = {
case LogMessage(msg:String, ex:ExecutionContext) ⇒ {log.info(msg + ex)}
}
I've seen other approaches that basically wrap scala.concurent.ExecutionContext (with current thread) and use Mapped Diagnostic Context-magic (log4j) and do logging by attaching the thread-id to the log-message. But ultimately it blocks/slows down the thread/execution (as far as I understand) and makes the app slower.
In this case with this Actor, the logging stays independent / async and sequential at the same time.
Is it a good idea to go this way? Sharing experience story? pros/cons/concerns? Asking before trying on heavy load..

Answer 1

Akka already had good support for logging, which is documentated on the page Logging - Akka Documentation. I don't think it's necessary or desirable to create a logger actor in your system particularly when this mechanism already exists.
You may already use the LoggingAdaptor class that performs logging asynchronously, it does this by posting it onto an event-bus. You should be able to use this same mechanism in an actor or outside.
Take a look at Logging.scala
Logging Mixin
Scala has a mixin for actors, that creates the logger for the actor and allows the MDC to be set. From documentation:
import Logging.MDC
final case class Req(work: String, visitorId: Int)
class MdcActorMixin extends Actor with akka.actor.DiagnosticActorLogging {
var reqId = 0
override def mdc(currentMessage: Any): MDC = {
reqId += 1
val always = Map("requestId" -> reqId)
val perMessage = currentMessage match {
case r: Req => Map("visitorId" -> r.visitorId)
case _ => Map()
}
always ++ perMessage
}
def receive: Receive = {
case r: Req => {
log.info(s"Starting new request: ${r.work}")
}
}
}
Logging outside an actor
There are two examples in the Logging.scala file of createing a LoggingSource outside of an actor:
trait MyType { // as an example
def name: String
}
implicit val myLogSourceType: LogSource[MyType] = new LogSource[MyType] {
def genString(a: MyType) = a.name
}
class MyClass extends MyType {
val log = Logging(eventStream, this) // will use "hallo" as logSource
def name = "hallo"
}
The second variant is used for including the actor system’s address:
trait MyType { // as an example
def name: String
}
implicit val myLogSourceType: LogSource[MyType] = new LogSource[MyType] {
def genString(a: MyType) = a.name
def genString(a: MyType, s: ActorSystem) = a.name + "," + s
}
class MyClass extends MyType {
val sys = ActorSystem("sys")
val log = Logging(sys, this) // will use "hallo,akka://sys" as logSource
def name = "hallo"
}
The MDC can be set on the logging adaptor if you need it.
Logging Thread and MDC
The documentation also covers your point on the logging thread, when the logging is asynchronously performed by another thread.
Since the logging is done asynchronously the thread in which the
logging was performed is captured in Mapped Diagnostic Context (MDC)
with attribute name sourceThread. With Logback the thread name is
available with %X{sourceThread} specifier within the pattern layout
configuration.

Answer 2

It looks like over engineering.
I would go with logback, and implement custom asynchonous Appender, if I would do something like this, so I would not have to change my code, if I decide not to discontinue.
Otherwise logging libraries are pretty good bet, I would try maybe tuning it to get better performance, and rely on others experience in implementing this feature.