Log processors
The purpose of a log processor is (usually) to modify a log record or add more detailed information to it.
Log processors allow you to manipulate log records without changing the code that actually calls the log method (inversion of control). This enables you to add any information from outside the scope of the actual calling function, such as webserver environment variables. The TYPO3 Core ships with some basic log processors, but more can be added with extensions.
Built-in log processors
This section describes the log processors that are shipped with the TYPO3 Core. Some processors have options to allow the customization of the particular processor. See the Configuration section for how to use these options.
IntrospectionProcessor
The introspection processor adds backtrace data about where the log event was triggered.
By default, the following parameters from the original function call are added:
- file
- The absolute path to the file.
- line
- The line number.
- class
- The class name.
- function
- The function name.
Options
-
- Default
false
Adds a full backtrace stack to the log.
shiftBackTraceLevel
-
- Default
0
Removes the given number of entries from the top of the backtrace stack.
MemoryUsageProcessor
The memory usage processor adds the amount of used memory to the log record (result from memory_get_usage()).
Options
-
- Default
true
Use the real size of memory allocated from system instead of
emallocvalue.()
formatSize
-
- Default
true
Whether the size is formatted with
General.Utility:: format Size ()
MemoryPeakUsageProcessor
The memory peak usage processor adds the peak amount of used memory to the log record (result from memory_get_peak_usage()).
Options
-
- Default
true
Use the real size of memory allocated from system instead of
emallocvalue.()
formatSize
-
- Default
true
Whether the size is formatted with
General.Utility:: format Size ()
RequestIdProcessor
New in version 15.0 Breaking: #110219 - Log request ID provided by log processor
The request ID is added to the log record by this processor instead of being passed through the logger.
The request ID processor
\TYPO3\ adds the unique ID of
the current request to the log record, so that all entries written during a
single request can be correlated.
Log attaches this processor to every
logger it creates, for all severity levels covered by the configured log
writers. It is registered internally rather than through the
processor configuration, so
overriding that configuration cannot remove the request ID from the log
output.
A logger that is instantiated manually, bypassing
Log, writes log records without a
request ID unless the processor is attached explicitly.
WebProcessor
The web processor adds selected webserver environment variables to the log record,
that means, all possible values from
\TYPO3\.
Custom log processors
Custom log processors can be added through extensions. Every log processor has to implement the interface EXT:core/Classes/Log/Processor/ProcessorInterface.php (GitHub). It is suggested to extend the abstract class EXT:core/Classes/Log/Processor/AbstractProcessor.php (GitHub) which allows you use configuration options by adding the corresponding properties and setter methods.
<?php
namespace MyVendor\MyExtension\Log\Processor;
use TYPO3\CMS\Core\Log\LogRecord;
class MyProcessor extends \TYPO3\CMS\Core\Log\Processor\AbstractProcessor
{
protected bool $option = true;
public function setOption(bool $option): void
{
$this->option = $option;
}
public function processLogRecord(LogRecord $logRecord): LogRecord
{
// add magic
return $logRecord;
}
}
Please keep in mind that TYPO3 will silently continue operating,
in case a log processor is throwing an exception while executing
the
process method.