Custom logging overview

Logs provide visibility into system processes; for example, debugging information that assists you with understanding when an error occurred or what lead to the error.

This topic focuses on file-based logging, although Commerce provides the flexibility to store logs in the database as well.

Adobe recommends using centralized application logging for the following reasons:

  • It allows storage of logs on a server other than the application server and decreases disk I/O operations, simplifying support of the application server.

  • It makes processing of logs data more effective by using special tools—such as Logstash, Logplex, or fluentd—without impact to a production server.

    note info
    Adobe does not recommend or endorse any particular logging solution.

PSR-3 compliance

The PSR-3 standard defines a common PHP interface for logging libraries. The main goal of PSR-3 is to allow libraries to receive a Psr\Log\LoggerInterface object and write logs to it in a simple and universal way.

This provides the ability for the implementation to be replaced easily without worry that such replacement may break the application code. It also guarantees a custom component will work even when the log implementation is changed in a future version of the system.


Commerce 2 complies with the PSR-3 standard. By default, Commerce uses Monolog. Monolog implemented as a preference for Psr\Log\LoggerInterface in the Commerce application di.xml.

Monolog is a popular PHP logging solution with a wide range of handlers that enable you to build advanced logging strategies. Following is a summary of how Monolog works.

A Monolog logger is a channel that has its own set of handlers. Monolog has many handlers, including:

  • Log to files and syslog
  • Send alerts and e-mails
  • Log specific servers and networked logging
  • Logging in development (integration with FireBug and Chrome Logger, among others)
  • Log to the database

Each handler can either process the input message and stop propagation or pass the control to the next handler in a chain.

Log messages can be processed in many different ways. For example, you can store all debug information into a file on disk, put the messages with higher log levels into a database, and finally send messages with log level “critical” by e-mail.

Other channels can have a different set of handlers and logic.