|Classes of Renato De Oliveira Lucena||>||PHP Pokemon Script||>||vendor/monolog/monolog/doc/01-usage.md||>||Download|
If you do not use Composer, you can grab the code from GitHub, and use any PSR-0 compatible autoloader (e.g. the Symfony2 ClassLoader component) to load Monolog classes.
This allows for flexible logging setups, for example having a
You can create many
Each Handler also has a Formatter, a default one with settings that make sense will be created if you don't set one. The formatters normalize and format incoming records so that they can be used by the handlers to output useful information.
Custom severity levels are not available. Only the eight RFC 5424 levels (debug, info, notice, warning, error, critical, alert, emergency) are present for basic filtering purposes, but for sorting and other use cases that would require flexibility, you should add Processors to the Logger that can add extra information (tags, user ip, ..) to the records before they are handled.
Monolog supports the logging levels described by RFC 5424.
Configuring a logger
Here is a basic setup to log to a file and to firephp on the DEBUG level:
Let's explain it. The first step is to create the logger instance which will be used in your code. The argument is a channel name, which is useful when you use several loggers (see below for more details about it).
The logger itself does not know how to handle a record. It delegates it to some handlers. The code above registers two handlers in the stack to allow handling records in two different ways.
Note that the FirePHPHandler is called first as it is added on top of the stack. This allows you to temporarily add a logger with bubbling disabled if you want to override other configured loggers.
> If you use Monolog standalone and are looking for an easy way to > configure many handlers, the theorchard/monolog-cascade > can help you build complex logging configs via PHP arrays, yaml or json configs.
Adding extra data in the records
Monolog provides two different ways to add extra informations along the simple textual message.
Using the logging context
The first way is the context, allowing to pass an array of data along the record:
Simple handlers (like the StreamHandler for instance) will simply format the array to a string but richer handlers can take advantage of the context (FirePHP is able to display arrays in pretty way for instance).
The second way is to add extra data for all records by using a processor.
Processors can be any callable. They will get the record as parameter and
must return it after having eventually changed the
Monolog provides some built-in processors that can be used in your project. Look at the dedicated chapter for the list.
> Tip: processors can also be registered on a specific handler instead of the logger to apply only for this handler.
Channels are a great way to identify to which part of the application a record is related. This is useful in big applications (and is leveraged by MonologBundle in Symfony2).
Picture two loggers sharing a handler that writes to a single log file. Channels would allow you to identify the logger that issued every record. You can easily grep through the log files filtering this or that channel.
Customizing the log format
In Monolog it's easy to customize the format of the logs written into files, sockets, mails, databases and other handlers. Most of the handlers use the
value to be automatically put into the log device. This value depends on the formatter settings. You can choose between predefined formatter classes or write your own (e.g. a multiline text file for human-readable output).
To configure a predefined formatter class, just set it as the handler's field:
You may also reuse the same formatter between multiple handlers and share those handlers between multiple loggers.