Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

PSR-3 makes PHP logging code more reusable by letting libraries depend on the PsrLogLoggerInterface rather than a specific logging product. The application supplies and configures the concrete logger, so the same library can write to different logging systems without being rewritten for each one. PSR-3 defines the shared interface and conventions; it does not provide a logging destination or a complete logging system.

How PSR-3 makes logging reusable

A library that creates or requires a vendor-specific logger is tied to that implementation. Instead, it can accept LoggerInterface and use the common methods in PSR-3. The application can then choose a compatible implementation and decide where records go. PHP-FIG describes the standard’s goal as allowing libraries to receive a PsrLogLoggerInterface and write logs in a simple, universal way: PSR-3: Logger Interface.

This separation is useful when an application changes logging backends, when different applications reuse the same library, or when a framework provides its own PSR-3-compatible logger. It does not guarantee that every backend behaves identically in operational details such as formatting, filtering, storage, or delivery; those are implementation and configuration choices.

Install the interface and choose an implementation

The psr/log Composer package supplies the interfaces and related classes, not a logger that writes records to a file or service. See the php-fig/log README for its installation and usage information. Monolog is one implementation of PSR-3; its handlers can send records to destinations including files, sockets, databases, and services. See the Monolog documentation.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Keep the decision at the application boundary: reusable code names the interface it needs, while the application composition or configuration creates the chosen backend and passes it in. Compare implementations by their PHP and psr/log compatibility, destination handlers and operational configuration, framework integration, and maintenance status—not by assuming PSR-3 itself selects or configures them.

Inject the logger into reusable code

Constructor injection makes the dependency visible and keeps the library independent of a particular backend:

<?php
use PsrLogLoggerInterface;

final class Importer
{
    public function __construct(private LoggerInterface $logger)
    {
    }

    public function run(string $file): void
    {
        $this->logger->info('Import started for {file}', ['file' => $file]);

        try {
            // Import work goes here.
        } catch (Throwable $exception) {
            $this->logger->error('Import failed for {file}', [
                'file' => $file,
                'exception' => $exception,
            ]);
            throw $exception;
        }
    }
}

The application must still construct an actual logger and pass it to Importer. The example shows the interface pattern; it does not prescribe a particular backend or its configuration.

Use levels and context according to the contract

PSR-3 defines eight named level methods, plus the generic log($level, ...) method. The standard levels correspond to RFC 5424. Passing a standard level to log() must have the same result as calling its matching named method.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
Level methods Typical signal
emergency, alert, critical Increasingly urgent serious conditions
error, warning Errors and conditions that warrant attention
notice, info, debug Noteworthy events, routine information, and diagnostic detail

These descriptions are practical orientation, not additional PSR-3 rules for deciding which level every event must use. If an implementation does not recognize a supplied level, the contract allows it to throw PsrLogInvalidArgumentException. Avoid custom levels unless the selected implementation explicitly supports them. The full contract is in the PSR-3 specification.

Keep the message stable; put changing values in context

Write message text as a static template and pass variable values in the context array. Placeholder names correspond to context keys:

$logger->info('User {userId} signed in', ['userId' => $userId]);

This lets implementations format or encode contextual values appropriately for their output. PHP-FIG’s PSR-3 Meta Document says context-specific variability belongs in the context array and that implementations are responsible for escaping context shown to users. Avoid interpolating raw user-controlled input into the message before passing it to the logger.

Pass exceptions under the exception key

When an exception or error should be logged with a stack trace, put the object in context under the key exception. In modern PHP, the relevant common type is Throwable, which includes both Exception and Error. Check that the value is a Throwable before treating it as one; arbitrary context data is not necessarily an exception.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

Other PSR-3 helpers

The package also defines tools for integration beyond direct constructor injection:

  • AbstractLogger and LoggerTrait help implement the forwarding methods around a logger’s core behavior.
  • NullLogger can serve as a no-op fallback when an integration has no logger to use.
  • LoggerAwareInterface and LoggerAwareTrait provide a setter-based way to give an object a logger.
  • LogLevel provides constants for standard level names.

These are conveniences in the PSR-3 package; they do not provide handlers or storage.

Check PHP and package compatibility before upgrading

Package requirements are version-specific. At the time of the cited Packagist records, psr/log 3.0.2, published September 11, 2024, required PHP 8.0 or later. Monolog 3.12.0, published September 9, 2026, required PHP 8.1 or later and psr/log ^2.0 or ^3.0. Verify the constraints for the exact releases and PHP version in your project before upgrading.

Monolog’s versioned documentation says 2.5 supports PHP 7.2 and later, while 1.25 supports PHP 5.3 through PHP 8.1 and is no longer maintained for PHP support fixes. These are facts about those releases, not blanket requirements for every Monolog version. Check the psr/log Packagist page, Monolog’s Packagist page, and Monolog documentation alongside your Composer constraints.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.