The Drupal 8 logging theory

Before going ahead with our example, let's cover some theoretical notions regarding the logging framework in Drupal 8. In doing so, we'll try to understand the key players we will need to interact with.

First, we have LoggerChannel, which represents a category of logged messages. They resemble the former $type argument to the Drupal 7 watchdog() function. A key difference, however, is that they are objects through which we do the actual logging via the logger plugins themselves. In this respect, they are used by our second main player, LoggerChannelFactory, a service that is normally our main contact with the logging framework as a client code.

To understand these things better, let's consider the following example of a simple usage:

\Drupal::logger('hello_world')->error('This is my error message'); 

That's it. We just used the available registered loggers to log an error message through the hello_world channel. This is our own custom channel that we just came up with on the fly and that simply categorizes this message as belonging to the hello_world category (the module we started in the preceding chapter). Moreover, you'll see that I used the static call. Under the hood, the logger factory service is loaded, a channel is requested from it, and the error() method is called on that channel:

\Drupal::service('logger.factory')->get('hello_world')->error('This is my error message');

When you request a channel from LoggerChannelFactory, you give it a name, and based on that name, it creates a new instance of LoggerChannel, which is the default channel class. It will then pass to that channel all the available loggers so that when we call any of the RfcLoggerTrait logging methods on it, it will delegate to them.

We also have the option of creating our own channel. An advantage of doing this is that we can inject it directly into our classes instead of the entire factory from where we can request the channel. Also, we can do it in a way in which we don't even require the creation of a new class, but will inherit from the default one. We'll see how to do that in the next section.

The third main player is the LoggerInterface implementation, which follows the PSR-3 standard. If we look at the DbLog class, which is the database logging implementation we mentioned earlier, we note that it also uses the RfcLoggerTrait which takes care of all the necessary methods so that the actual LoggerInterface implementation only has to handle the main log() method. This class is then registered as a service with the logger tag, which in turn registers it with LoggerChannelFactory (which also acts as a service collector).

As we saw in Chapter 2, Creating Your First Module, tags can be used to categorize service definitions and we can have them collected by another service for a specific purpose. In this case, all services tagged with logger have a purpose, and they are gathered and used by LoggerChannelFactory.

I know it's been quite a lot of theory, but these are some important concepts to understand. However, don't worry; as usual, we will go through some examples.