Logging is too noisy by default

Just following up here that a temporary fix for this is to add this to services.yml:

services:
  logger.channel.search_api_opensearch_client:
    class: Psr\Log\NullLogger

This prevents any logging from the client at all, but ideally it would be possible to limit it by severity somehow so errors are still logged, but not all the debug noise.

I think we should create a new logger channel that we pass to the backend library. At least that way we can log the module code, and configure the backend library code separately.

Here's a LoggerChannel subclass that I wrote a couple weeks ago to for this. It drops all INFO and DEBUG logs.

namespace Drupal\opensearch_log_silencer;

use Drupal\Core\Logger\LoggerChannel;
use Drupal\Core\Logger\RfcLogLevel;

/**
 * Logger to drop all INFO and DEBUG entries.
 */
class NoDebugLogger extends LoggerChannel {

  /**
   * {@inheritdoc}
   */
  public function log($level, $message, array $context = []) {
    if (is_string($level)) {
      // Convert to integer equivalent for consistency with RFC 5424.
      $level = $this->levelTranslation[$level];
    }
    // Drop all levels less severe than NOTICE. This currently means no INFO or
    // DEBUG log entries.
    if ($level > RfcLogLevel::NOTICE) {
      return;
    }
    parent::log($level, $message, $context);
  }

}

It would be nice if something like this were integrated into the module.

Here's a MR that adds a separate logger channel for the library Client. You can configure that to be a NULL logger if you want via Symfony service overloading, or monolog if you use that.

@kim.pepper you already have logger.channel.search_api_opensearch for module logging and logger.channel.search_api_opensearch_client for client logging - the latter is only used in the same place this MR touches.

#4 is a nice idea as I think I would like to see errors from the client, but multiple lines of debug for every query run are not necessary.

kim.pepper → closed merge request !34

Ah yes! Apologies.

I think filtering log messages based on level is outside the scope of this module. As mentioned before, Monolog can do this for you. If you want to stick to core dependencies and PSR Logger, you only have the NullLogger to help you.

@kim.pepper: If you are willing to reconsider, this patch allows configuring the logging threshold for the OpenSearch client.

This patch also solves one additional problem. Drupal's logger instances expect the keys of the $context array to be prefixed placeholders which are also present in the $message. PSR-3 makes no such requirements, and therefore the OpenSearch client places vital pieces of debug information in the $context without adding placeholders for them. This custom LoggerChannel implementation prefixes the context keys with '@' and adds them to the $message to be logged.

Without this last detail, the debug messages generated by the OpenSearch client are almost entirely useless.

The last submitted patch, 10: search_api_opensearch-3371048-10-configurable-loglevel.patch, failed testing. View results →
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

Bah, the last patch had a careless bug in it.

As I've said already, managing logs, filtering by level etc, is outside the responsibilities of this module. You are free to change out the logger to what ever contrib or custom code you want, but it's not something I will add to the module.

In case anyone comes here and tries to implement a fix to reduce log noise (especially on a busy site that still uses db logging), I had a lot of trouble trying to override the service in a way that held.

You can adapt the code from comment #4 in a custom module, noting that there has been a change to the log method definition:

  public function log($level, string|\Stringable $message, array $context = []): void {

Then in your custom module's services file:

services:
  logger.channel.search_api_opensearch_no_debug:
    decorates: logger.channel.search_api_opensearch_client
    class: Drupal\my_module\OpenSearchNoDebugLogger
    arguments: [ 'search_api_opensearch_client', '@request_stack', '@current_user' ]

I've never had to use Symfony's decorates parameter before but it is really cool. (I struggled to find any Drupal-specific documentation on overriding services that really pointed me in the right direction.)