Manual:Structured logging

Structured logging is operational (debug) logging that includes structured data for easier post-processing. Starting in MediaWiki 1.25, the PSR-3 logging standard is available for use by MediaWiki core and extensions to replace  and   debug logging calls. The PSR-3 standard allows attaching an array of context data to each log message to provide structured key=>value pairs.

Use informative severity levels

 * These are messages that are useful for local development and are generally too "spammy" to output on a production wiki. This would typically include anything currently being logged via wfDebug.
 * These are messages that are useful for local development and are generally too "spammy" to output on a production wiki. This would typically include anything currently being logged via wfDebug.


 * Valuable state change information. This level is a great place to record information that would be useful in a production environment when tracing the path of a request that eventually had an error. This is currently the level automatically associated with  calls when mapped to PSR-3.
 * Valuable state change information. This level is a great place to record information that would be useful in a production environment when tracing the path of a request that eventually had an error. This is currently the level automatically associated with  calls when mapped to PSR-3.


 * A soft error condition such as a recoverable error or another condition that typically should not be seen but isn't halting for the operation in process.
 * A soft error condition such as a recoverable error or another condition that typically should not be seen but isn't halting for the operation in process.


 * A hard error such as a caught exception with no recovery path.
 * A hard error such as a caught exception with no recovery path.

Add structured data to logging context
Add useful structured information to the log message using the logging context that can be used to find related messages and trace the cause of the error. This is especially important and useful for  and   level messages where the wiki operator may not be familiar with the code path and needs to be able to find a good bug report.


 * If an Exception object is passed in the context data, it MUST be in the 'exception' key (e.g. )
 * Record the method that emitted the error:
 * Attach parameters or other interesting state to messages.
 * Replace faux structure such as tab separated items, label=value/label:value pairs, or json serialization