In Cook's flow, we used two print statements in order to see how the Cook was doing. It's OK for our example but we would be better off with proper logging. Let's improve on that.

Akka provides a log method which takes a logger name as a parameter and can be called on any processing stage in the flow. Let's use it instead of our print statements:

def formFlow: Flow[Dough, RawCookies, NotUsed] =
  Flow[Dough]
    .log("Cook[Before Map]")
    .map { dough =>
      RawCookies(makeCookies(dough.weight))
    }
    .log("Cook[After Map]")
    .withAttributes(
      Attributes.logLevels(
        onElement = Logging.InfoLevel,
        onFinish = Logging.DebugLevel,
        onFailure = Logging.WarningLevel
      )
    )

Here, we're writing into the log elements of the flow before and after transformation and also providing an optional logging configuration in order to specify log levels for different types of events.

To see the effect of these changes we need to extend the application.conf:

akka {
  loggers = ["akka.event.Logging$DefaultLogger"]
  # Options: OFF, ERROR, WARNING, INFO, DEBUG
  loglevel = "INFO"
}

Now, after starting our example, we'll see the following entries in the log:

[INFO] [Bakery-akka.actor.default-dispatcher-14] [akka.stream.Log(akka://Bakery/system/StreamSupervisor-0)] [Cook[Before Map]] Element: Dough(575)
 ...
 [INFO] [Bakery-akka.actor.default-dispatcher-14] [akka.stream.Log(akka://Bakery/system/StreamSupervisor-0)] [Cook[After Map]] Element: RawCookies(11)
 ...
 [INFO] [Bakery-akka.actor.default-dispatcher-14] [akka.stream.Log(akka://Bakery/system/StreamSupervisor-0)] [Cook[Before Map]] Element: Dough(1380)
 [INFO] [Bakery-akka.actor.default-dispatcher-14] [akka.stream.Log(akka://Bakery/system/StreamSupervisor-0)] [Cook[After Map]] Element: RawCookies(27)

With logging in place, we have finished defining all of the parts of our flow and can try to bring them together.