community/feature-request#12 - Allow named logging channels

[totten]

Overview

Make it easier to route log messages based on their topic (e.g. CiviContribute-related logs vs CiviMail-related logs).

This is a variation+extraction of @eileenmcnaughton's #20068.

Before

Civi::log() always returns the same instance of LoggerInterface, with no clear way to differentiate logs of different business subsystems.

After

Civi::log(...) allows you to optionally request a LoggerInterface for a specific theme, e.g.

Civi::log('mail')->error('Failed to connect to SMTP server');
Civi::log('ipn')->warning('Transaction rejected by payment processor');

Technical Details

A few things going on here:

• Extensions may start using their own logs (Civi::log('myext')) without any special effort.
• It is possible to replace or customize specific logs by defining a service log.CHANNEL_NAME.
• The psr_log_manager is a service. An extension like https://lab.civicrm.org/extensions/monolog/ can replace the
  psr_log_manager and use the channel-name in its own way.

There is a consideration here in that the list of channels is open-ended. It will be impossible to (eg) detect that a log-user has made a typo in the channel-name. However, this seems like the better trade-off if the alternative is that extensions face races during installation/uninstallation.

[civibot]

(Standard links)

• If this is your first pull-request for CiviCRM, please browse CONTRIBUTING.md for information about the development and testing processes.
• If you are reviewing this pull-request, you may wish to consult the test sites and the Review Standards (long template, short template).

[eileenmcnaughton]

@totten this is great in terms of allowing extensions more options & I think is mergeable once I've done some testing.

On to shooting the breeze.....

• in terms of imagining a core use case

'I want all ipn debug to go to a different file'

we can build on this (if we so choose, as a follow up) by

1. switching calls in the ipn files in core to Civi::log('ipn')->debug('blah') - this would be no change unless an extension registers a logging service against that prefix

2. if we wanted to log (by default in core) to a separate file we could do that by
   a) registering the logging service in core (which would still be overridable)
   b) configuring CRM_Core_Error_Log to accept a prefix & then making that part of the definition - such that it gets as far as this line

   civicrm-core/CRM/Core/Error/Log.php

   Line 57 in 160aed8

   CRM_Core_Error::debug_log_message($message, FALSE, '', $this->map[$level]);

   (the 3rd param is 'prefix' and determines what file it goes to)

[totten]

1. Yup, just sprinkle in the Civi:log('ipn') bit
2. Passing through the channel-name for the debug_log_message(...$prefix...) would make it go to another file. At a minimum, one should do a little validation for well-formedness (ie a channel-name with /../ is bad).

[eileenmcnaughton]

test fail seems unrelated but will re-run

[eileenmcnaughton]

test this please

[eileenmcnaughton]

OK - I tested this locally - if I do

• Civi::log()->alert('blah') then it outputs to ConfigAndLog/default.log - this appears unchanged
• Civi::log('my_log')->alert('blah') then it borks before & logs to default.lot after (improvement)
• ^^ but in a hook I do

function my_log_civicrm_container($container) {
  $container->setDefinition('log.my_log', new Definition('\Civi\MonoLog\MonoLog', []))->setPublic(TRUE);
}

then it does nothing before but after it logs as configured in the extension

MOP

[artfulrobot]

This is great, thanks @totten and eileen (no @ as I read you're taking a break)!