Disable logging per module

[mzeis]

Some extensions log useless stuff that pollutes the logs.

The problem could be avoided if Magento as well as the extension vendors would pay more attention to the log levels already provided and use them accordingly (e.g. differentiate between debug output and real information / notices / warnings / errors).

As it may not be possible to force using the correct log levels it would be nice to have an option in the System Configuration to disable logging. One of many possible ways to solve this in the UI would be to have a multi-select listing all modules in the installation.

[antonkril]

Calls to log don't provide module for which this call happens, so we will not be able to distinguish from which module the log entry comes

[mzeis]

That's true.

@schmengler suggested that debug_backtrace() could be investigated. See firegento/firegento-logger#62. I admit that this may not be reliable. However if the log entity was to be redesigned this could be taken into account (e.g. if the log functionality was refactored to be implemented via traits, a different service contract / DI implementation, ...).

[antonkril]

Theoretically it's possible to inject different log instances to classed of different modules, but that would impact performance of ObjectManager (module checks would become required on each instance creation) and might become overkill. Filtering log results seems much cheaper solution.

[alankent]

Is the logger global? Or could each module have a separate logger instance initialized with the module name (via DI.xml file)? That is, it is not "magic" in object manager - it's just a different constructor argument if a class wants to log something.

Alternative approach is to have "switches" where "good" code should check if a switch is set before calling the log function. This avoids creating strings that are not actually written, but tends to make the code ugly.

if (switch.isOn("catalog")) warn("blah blah ".$x." Blah blah blah");

The concatenation is only done if the flag is on, rather than computing the string only to have it discarded later.

[mzeis]

For reference: @jayelkaake built an M1 extension analysing debug_backtrace: https://github.com/jayelkaake/logmanager

My personal preference would be to have a more enhanced logging functionality like https://github.com/firegento/firegento-logger.

The key features for me:

• let me decide where the log should go (File, Database, syslog, ...)
• let me decide what should be logged where (e.g. we have a log for all messages in the DB, one for warnings/errors only in the file)
• let met black/whitelist the messages to be logged

I do understand the performance implication mentioned by @antonkril.

I thought about it again and it might be enough to:

• have the key features mentioned above in the core
• giving direction in the documentation when and how to use the different log levels
• make it mandatory to define a log level when writing to the log.

Could you consider the last point? If people had to define the log level themselves (i.e. you are not defaulting to a certain log level) that may help.

Making it possible to disable logging on a module level could then be left to the community if still necessary, either by providing an extension like Jay did or by encouraging the extension developer to improve the logging in their respective extensions.

[orlangur]

Starting from 0.42.0-beta2 M2 uses PSR-3 compatible Monolog library, de-facto logging standard in PHP world, instead of old logger inherited from M1. In order to achieve logging parity, like system.log, exception.log and debug.log separation, only a tiny configuration of Monolog was needed: https://github.com/magento/magento2/tree/develop/lib/internal/Magento/Framework/Logger/Handler

So, currently logging in M2 is used in most recognizable and standardized way. Among three options to change logging behavior:

• add features to core
• configure Monolog
• replace logger implementation via DI

I personally would prefer second one and consider third as acceptable for rare cases.

At the first glance it looks like key features you described are supported by Monolog out of the box:

Every Logger instance has a channel (name) and a stack of handlers. Whenever you add a record to the logger, it traverses the handler stack. Each handler decides whether it fully handled the record, and if so, the propagation of the record ends there.

This allows for flexible logging setups, for example having a StreamHandler at the bottom of the stack that will log anything to disk, and on top of that add a MailHandler that will send emails only when an error message is logged. Handlers also have a $bubble property which defines whether they block the record or not if they handled it. In this example, setting the MailHandler's $bubble argument to false means that records handled by the MailHandler will not propagate to the StreamHandler anymore.

You can create many Loggers, each defining a channel (e.g.: db, request, router, ..) and each of them combining various handlers, which can be shared or not. The channel is reflected in the logs and allows you to easily see or filter records.

Custom logging logic, like debug_backtrace analysis for extensions which do not follow PSR-3, could be easily implemented but does not seem to be suitable for core.

• giving direction in the documentation when and how to use the different log levels
• make it mandatory to define a log level when writing to the log.

It's exactly what PSR-3 is intended for. Log level is already mandatory.

[mzeis]

Thank you for the explanation - that's very helpful. I'll close the issue then and wait how things work out in practice.

[birchestx]

Hi, know this is closed but just wanted to add that we ship our own logger with every extension. This is open source, and will support any extension - https://github.com/webshopapps/wsalogger

We wrote this a number of years back, and are planning to update for Magento2 to key into the features there. The advantage of this logger is that you can set it to display not just in the system log but also in the admin panel. We did think about having a separate log per extension but decided against this approach as its better sometimes to run them in one log so you can see the sequence of events as they interact with each other.

We showed this logger to Yoav and the architects back in 2010 but there was a total lack of understanding of the value of the tool in my mind.

I'm sure what we are doing could be extended (the open source one isn't our latest codebase btw) but it supports various log levels, emailing logs, and this in admin view, all of which I think are important features. I'm very much a fan of log4j and hope to see something similar in Magento. We also have support for showing logs in the cart.

The frustration we find is that because other providers aren't also logging we can't see their interactions, if we could get everyone to use a common format my feeling is this would empower not just extn providers, but the merchant and web design agencies themselves.

There are other loggers out there, I know the Mage Hackathon team did one which I think some people have adopted. We did this before that, if there was a common one we would use it because we would rather concentrate on shipping than sysadmin tools.

The ability to give merchants tools to be able to self-diagnose should not be underestimated, and at present this is severely lacking.

[piotrekkaminski]

Hey @wsakaren . Given the integration with Monolog that can send out logs to things like Loggly I would assume we will recommend all extensions providers to use common logger. Can you tell me from customer experience would asking customer to add another handler for monolog would be possible? I would assume no. How about having customer send you the log file? Do you think only web interface in admin is a solution? I would rather use a 3rd party centralized service like Loggly instead but need more input.

[piotrekkaminski]

@mzeis your question is very relevant. It would be great to be able to filter out logs by module. @orlangur is it possible to automatically add current module name to all logs or this would have to be explicitly added to all log messages? This is actually pretty important to be able to analyze logs