Daniel ab1334c0cf the whole shebang %!s(int64=10) %!d(string=hai) anos
..
doc ab1334c0cf the whole shebang %!s(int64=10) %!d(string=hai) anos
src ab1334c0cf the whole shebang %!s(int64=10) %!d(string=hai) anos
tests ab1334c0cf the whole shebang %!s(int64=10) %!d(string=hai) anos
CHANGELOG.mdown ab1334c0cf the whole shebang %!s(int64=10) %!d(string=hai) anos
LICENSE ab1334c0cf the whole shebang %!s(int64=10) %!d(string=hai) anos
README.mdown ab1334c0cf the whole shebang %!s(int64=10) %!d(string=hai) anos
composer.json ab1334c0cf the whole shebang %!s(int64=10) %!d(string=hai) anos
phpunit.xml.dist ab1334c0cf the whole shebang %!s(int64=10) %!d(string=hai) anos

README.mdown

Monolog - Logging for PHP 5.3+ Build Status

Total Downloads Latest Stable Version

Monolog sends your logs to files, sockets, inboxes, databases and various web services. See the complete list of handlers below. Special handlers allow you to build advanced logging strategies.

This library implements the PSR-3 interface that you can type-hint against in your own libraries to keep a maximum of interoperability. You can also use it in your applications to make sure you can always use another compatible logger at a later time.

Usage

<?php

use Monolog\Logger;
use Monolog\Handler\StreamHandler;

// create a log channel
$log = new Logger('name');
$log->pushHandler(new StreamHandler('path/to/your.log', Logger::WARNING));

// add records to the log
$log->addWarning('Foo');
$log->addError('Bar');

Core Concepts

Every Logger instance has a channel (name) and a stack of handlers. Whenever you add a record to the logger, it traverses the handler stack. Each handler decides whether it handled fully the record, and if so, the propagation of the record ends there.

This allows for flexible logging setups, for example having a StreamHandler at the bottom of the stack that will log anything to disk, and on top of that add a MailHandler that will send emails only when an error message is logged. Handlers also have a $bubble property which defines whether they block the record or not if they handled it. In this example, setting the MailHandler's $bubble argument to false means that records handled by the MailHandler will not propagate to the StreamHandler anymore.

You can create many Loggers, each defining a channel (e.g.: db, request, router, ..) and each of them combining various handlers, which can be shared or not. The channel is reflected in the logs and allows you to easily see or filter records.

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.

Log Levels

Monolog supports all 8 logging levels defined in RFC 5424, but unless you specifically need syslog compatibility, it is advised to only use DEBUG, INFO, WARNING, ERROR, CRITICAL, ALERT.

  • DEBUG (100): Detailed debug information.

  • INFO (200): Interesting events. Examples: User logs in, SQL logs.

  • NOTICE (250): Normal but significant events.

  • WARNING (300): Exceptional occurrences that are not errors. Examples: Use of deprecated APIs, poor use of an API, undesirable things that are not necessarily wrong.

  • ERROR (400): Runtime errors that do not require immediate action but should typically be logged and monitored.

  • CRITICAL (500): Critical conditions. Example: Application component unavailable, unexpected exception.

  • ALERT (550): Action must be taken immediately. Example: Entire website down, database unavailable, etc. This should trigger the SMS alerts and wake you up.

  • EMERGENCY (600): Emergency: system is unusable.

Docs

See the doc directory for more detailed documentation. The following is only a list of all parts that come with Monolog.

Handlers

Log to files and syslog

  • StreamHandler: Logs records into any PHP stream, use this for log files.
  • RotatingFileHandler: Logs records to a file and creates one logfile per day. It will also delete files older than $maxFiles. You should use logrotate for high profile setups though, this is just meant as a quick and dirty solution.
  • SyslogHandler: Logs records to the syslog.
  • ErrorLogHandler: Logs records to PHP's error_log() function.

Send alerts and emails

  • NativeMailerHandler: Sends emails using PHP's mail() function.
  • SwiftMailerHandler: Sends emails using a Swift_Mailer instance.
  • PushoverHandler: Sends mobile notifications via the Pushover API.
  • HipChatHandler: Logs records to a HipChat chat room using its API.

Log specific servers and networked logging

  • SocketHandler: Logs records to sockets, use this for UNIX and TCP sockets. See an example.
  • AmqpHandler: Logs records to an amqp compatible server. Requires the php-amqp extension (1.0+).
  • GelfHandler: Logs records to a Graylog2 server.
  • CubeHandler: Logs records to a Cube server.
  • RavenHandler: Logs records to a Sentry server using raven.
  • ZendMonitorHandler: Logs records to the Zend Monitor present in Zend Server.
  • NewRelicHandler: Logs records to a NewRelic application.

Logging in development

  • FirePHPHandler: Handler for FirePHP, providing inline console messages within FireBug.
  • ChromePHPHandler: Handler for ChromePHP, providing inline console messages within Chrome.

Log to databases

  • RedisHandler: Logs records to a redis server.
  • MongoDBHandler: Handler to write records in MongoDB via a Mongo extension connection.
  • CouchDBHandler: Logs records to a CouchDB server.
  • DoctrineCouchDBHandler: Logs records to a CouchDB server via the Doctrine CouchDB ODM.

Wrappers / Special Handlers

  • FingersCrossedHandler: A very interesting wrapper. It takes a logger as parameter and will accumulate log records of all levels until a record exceeds the defined severity level. At which point it delivers all records, including those of lower severity, to the handler it wraps. This means that until an error actually happens you will not see anything in your logs, but when it happens you will have the full information, including debug and info records. This provides you with all the information you need, but only when you need it.
  • NullHandler: Any record it can handle will be thrown away. This can be used to put on top of an existing handler stack to disable it temporarily.
  • BufferHandler: This handler will buffer all the log records it receives until close() is called at which point it will call handleBatch() on the handler it wraps with all the log messages at once. This is very useful to send an email with all records at once for example instead of having one mail for every log record.
  • GroupHandler: This handler groups other handlers. Every record received is sent to all the handlers it is configured with.
  • TestHandler: Used for testing, it records everything that is sent to it and has accessors to read out the information.

Formatters

  • LineFormatter: Formats a log record into a one-line string.
  • NormalizerFormatter: Normalizes objects/resources down to strings so a record can easily be serialized/encoded.
  • JsonFormatter: Encodes a log record into json.
  • WildfireFormatter: Used to format log records into the Wildfire/FirePHP protocol, only useful for the FirePHPHandler.
  • ChromePHPFormatter: Used to format log records into the ChromePHP format, only useful for the ChromePHPHandler.
  • GelfFormatter: Used to format log records into Gelf message instances, only useful for the GelfHandler.
  • LogstashFormatter: Used to format log records into logstash event json, useful for any handler listed under inputs here.

Processors

  • IntrospectionProcessor: Adds the line/file/class/method from which the log call originated.
  • WebProcessor: Adds the current request URI, request method and client IP to a log record.
  • MemoryUsageProcessor: Adds the current memory usage to a log record.
  • MemoryPeakUsageProcessor: Adds the peak memory usage to a log record.
  • ProcessIdProcessor: Adds the process id to a log record.
  • UidProcessor: Adds a unique identifier to a log record.

Utilities

  • ErrorHandler: The Monolog\ErrorHandler class allows you to easily register a Logger instance as an exception handler, error handler or fatal error handler.
  • ErrorLevelActivationStrategy: Activates a FingersCrossedHandler when a certain log level is reached.
  • ChannelLevelActivationStrategy: Activates a FingersCrossedHandler when a certain log level is reached, depending on which channel received the log record.

About

Requirements

  • Any flavor of PHP 5.3 or above should do
  • [optional] PHPUnit 3.5+ to execute the test suite (phpunit --version)

Submitting bugs and feature requests

Bugs and feature request are tracked on GitHub

Frameworks Integration

  • Frameworks and libraries using PSR-3 can be used very easily with Monolog since it implements the interface.
  • Symfony2 comes out of the box with Monolog.
  • Silex comes out of the box with Monolog.
  • Laravel4 comes out of the box with Monolog.
  • PPI comes out of the box with Monolog.
  • CakePHP is usable with Monolog via the cakephp-monolog plugin.
  • Slim is usable with Monolog via the Slim-Monolog log writer.

Author

Jordi Boggiano - j.boggiano@seld.be - http://twitter.com/seldaek
See also the list of contributors which participated in this project.

License

Monolog is licensed under the MIT License - see the LICENSE file for details

Acknowledgements

This library is heavily inspired by Python's Logbook library, although most concepts have been adjusted to fit to the PHP world.