tereta/logger

1.0.8 2026-04-27 23:10 UTC

Requires

• php: >=8.4
• tereta/core: ^1.0
• tereta/di: ^1.0

Apache-2.0

README

🌐 Русский | English

The module Tereta.Logger provides a logging mechanism for the Tereta application. It allows you to log messages with different levels of severity, such as debug, info, warn, and error. The logs can be configured to be written to different backends, such as the console or a file.

Log Level Configuration

Each log level (debug, info, warn, error) is configured independently. This allows granular control — for example, you can enable only error and debug while keeping info and warn disabled.

Configuration is done via .config.php:

->set('logger', Value::factory()->create()
    ->set('debug', false)
    ->set('info', false)
    ->set('warn', false)
    ->set('error', true))

Levels are not hierarchical: enabling error does not automatically enable lower levels.

Production checklist

The logger is intentionally silent until it is told what to write — there is no fallback to PHP's error_log(). Three things must be wired up before the first log call, otherwise messages are dropped without warning:

1. Enable the levels you want. Every level defaults to false. Either bind the logger config block shown above, or call directly:

   use Tereta\Logger\Services\Channel\Config as ChannelConfig;
   
   ChannelConfig::singleton()->set('error', true);
   

2. Define ROOT_DIRECTORY. The default general and error channels resolve their paths relative to this constant (ROOT_DIRECTORY/var/logs/{general,error}.log). When the constant is missing, Output::singleton() throws \RuntimeException on first use. Either define it at bootstrap, or register every channel explicitly via Output::singleton()->setChannel(...) before the first lookup.

3. Long-running processes (FPM workers reused across requests, Kafka consumers, RoadRunner) should reset state at request/iteration boundaries to avoid leaking channel and level configuration across isolated units of work:

   Output::singleton()::resetSingleton();
   ChannelConfig::singleton()::resetSingleton();
   Tereta\Logger\Factories\Strategy::singleton()::resetSingleton();
   

   The same resetSingleton() is what test teardown should call.

Substituting implementations

Default adapters and singletons can be swapped through the DI container — register the override before the first singleton() call (or after a resetSingleton()):

use Tereta\Di\Services\Container;
use Tereta\Logger\Strategies\File as FileStrategy;

Container::register(FileStrategy::class, MyCustomFileStrategy::class);

Usage

To use the logging functionality, you can import the Tereta\Logger module and call the appropriate logging functions. For example:

use Tereta\Logger\Services\Output;

Output::singleton()->channel('general')->debug('This is a debug message');
Output::singleton()->channel('general')->info('This is an info message');
Output::singleton()->channel('general')->warn('This is a warning message');
Output::singleton()->channel('general')->error('This is an error message');
Output::singleton()->channel('debugger')->debug('This is a debug message');