[meta] Log to the logging service

What needs to be done to get this working? I'm currently struggling to accomplish even the most basic of tasks from d7 in the d8 version of Rules. The total lack of feedback from Rules only makes it more difficult.

+1 for this one

(If I were a developer, I would help out...)

@dendreten and everyone else who wants to see this feature implemented:

We would very much like to have someone help out and submit a patch to implement logging in D8. The Rules maintainers are all volunteering our own time to work on Rules, so we naturally work on the things that are important to us first, or on the thing where we think we can make the most progress. But everyone in the community has different priorities. If you are not a developer, then perhaps you can hire a developer to implement this feature. Or perhaps you can organize a group to pitch in, and all of you can contribute to hiring someone to develop this feature. Or perhaps you can contribute to this issue queue in other ways by evaluating patches, or working on the design of the UI, or sponsoring Drupalcon attendance, or writing documentation, etc. We all have things we are good at - if you use your abilities to contribute to Rules, then that is one less thing the Rules developers need to do - then we can spend more time working on the code.

I can see the following logging options which is similar to D7 version.

Let me know if anything additional need to implemented.

Yes, the configuration settings are there, but they don't actually do anything. This is a pretty self-explanatory task - turn on logging in D7 and see what it does, then reproduce that in D8.

@Sharique: Are you going to work on this?

yes, I'm going to work on this.

Great! Let me know if you have any questions.

@TR there 2 logger classes RulesLog and RulesChannelLogger, I think we need only one.
There are so many actions, events, so I'm a bit confused. RulesActions seems the correct place to add start with.

These were introduced in #2404089: Convert RulesLog to a logging service

I suggest reading that to see the reasoning. I'm away from my computer until next week so I can't really research this right now.

I researched the issue, and while it's fresh in my memory here's a summary of how logging works in Rules/Drupal.

The short answer is we definitely need both RulesLoggerChannel and RulesLog.

D7 Watchdog/Dblog

In D7 we logged messages by calling the watchdog() function:

watchdog($type, $message, $variables = array(), $severity = WATCHDOG_NOTICE, $link = NULL)

where $type is used to identify the category of the message - usually the name of the module logging the message.

The watchdog() function simply assembles its arguments (plus a few other global variables) into an array then passes that array on to all available hook_watchdog() implementations. It doesn't do anything by itself to display or save any of these log messages.

The core dblog module provides the default logging mechanism through its hook_watchdog() implementation named dblog_watchdog(). This default logging mechanism stores all messages in the system {watchdog} table.

Rules in D7 implements hook_watchdog() for the sole purpose of generating an Event when a log entry is made - the log entry is still written to the database because dblog_watchdog() is also executed, but Rules adds the Event functionality on top of that.

D8 LoggerChannnel/Logger

In D8, we still have all these concepts, but they are implemented differently.

In D8 what used to be the $type (or log message category) argument to watchdog() is now called a channel. So now we don't have just one watchdog() function which is used to log everything, we have many individual channels and they can all be used separately. Instead of calling watchdog($type, ...) to log a message we now first get the logger channel $channel = \Drupal::logger($type) then call the log() method on that channel $channel->log($level, $message, array $context = []).

(Note, in D8 we would normally inject the logger channel into any OO code instead of using the static \Drupal::logger() function, but that's a different topic. Likewise, in D8 we have many convenience functions to log messages of different severity, so instead of just log() we can use notice(), warning(), error(), etc. But all those functions end up calling log(), just with different arguments. For simplicity we're only going to talk about the static \Drupal::logger() function and the log() method here.)

Modules may define their own logger channels, but that is not necessary - using \Drupal::logger($type) will automatically generate a new channel for us if the $type channel doesn't exist. The advantage of defining your own channel is that you can customize the channel behavior. Rules does define its own logger channel, using the RulesLoggerChannel class, and uses that channel for all Rules log message. In the case of RulesLoggerChannel, our custom logger channel uses configuration variables (provided at /admin/config/workflow/rules/settings) to decide which messages to log, if any, then delegates the logging to the parent LoggerChannel class.

As in D7, we have a way to send messages to somewhere other than the system dblog. But instead of doing this with hook_watchdog() we do this by defining a logger. Where in D7 watchdog() only invoked all the hook_watchdog() functions and did nothing to actually save the log messages, in D8 log() doesn't actually save any log messages, it just calls the log() method of all registered loggers.

And just as with D7, the core dblog module provides a default logger - the \Drupal\dblog\Logger\DbLog class - that saves log messages in a database table.

In D8 we can provide our own logger implementation to do our own thing. While D7 used hooks to customize what watchdog() does, D8 uses tagged services. A logger is a class that implements LoggerChannelInterface and is used as a service with the 'logger' service tag (see below). All registered loggers are used for every channel.

This is where RulesLog comes in - RulesLog is a logger (not a logger channel) which, like it's D7 equivalent, does nothing but generate an Event when a message is logged by any logger channel.

Summary

Both RulesLoggerChannel and RulesLog are needed. The first provides a dedicated Rules logger channel that makes use of the configuration variables set by the site administrator to decide which Rules messages to log. The second provides the logger implementation that generates an event when any message is logged to any channel.

References

watchdog()

hook_watchdog()

\Drupal\Core\Logger\LoggerChannelInterface

\Drupal\Core\Logger\LoggerChannel

\Drupal\dblog\Logger\DbLog

RulesLoggerChannel

RulesLog

The Rules logger is defined by the 'logger.ruleslog' service. The implementation is in the RulesLog class. The service has the 'logger' tag which registers it with Drupal as a logger to be used whenever a log is sent to a logger channel. From rules.services.yml:

  logger.ruleslog:
    class: Drupal\rules\Logger\RulesLog
    tags:
      - { name: logger }

D7 RulesLog

In D7, RulesLog is a transient singleton object which stores log entries in an array in memory. As such, at most one RulesLog object is created for each page request and is subsequently destroyed after the request is fulfilled.

The RulesLog object is used to collect debug messages that are generated by execution of a Rules component. These messages may optionally be sent to the core Drupal dblog or displayed on the page. RulesLog is intended for only for debugging purposes, and not for use on a production site.

RulesLog is used by calling rules_log(), which is a Rules-specific function with the same arguments as watchdog(). rules_log() controls which messages are sent to dblog for logging, and which messages are sent to the RulesLog.

The missing piece in D8 is the functionality was in rules_log() and the (D7) class RulesLog - namely storing debug messages in memory and displaying them in the UI. Perhaps it can be included in the (D8) class RulesLog, or in the RulesLoggerChannel, or perhaps it needs to be a separate class.

@Sharique: Have you made any progress? You can post what you have so far if you're stuck.

@TR, sorry no progress on my side, stuck in other priority work. Feel free to take it.

Changing this to a meta issue, because there are a number of non-trivial discrete tasks that need to be accomplished to finish this. I updated the issue summary accordingly.

Added related issue.

Switching this to "Needs review"

The only step left is in #3104109: Implement rendering of debug logs to screen and database. Please review that issue.

#3104109: Implement rendering of debug logs to screen and database has been committed, so that completes step 4 #3101198: [meta] Implement conditional logging and on-screen rendering in RulesDebugLoggingChannel.

If you find any problems with this functionality please open a new issue as a follow-up.