Download the PHP package wshafer/psr11-monolog without Composer
On this page you can find all versions of the php package wshafer/psr11-monolog. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download wshafer/psr11-monolog
More information about wshafer/psr11-monolog
Files in wshafer/psr11-monolog
Package psr11-monolog
Short Description Monolog Facotories for PSR-11
License BSD-2-Clause
Homepage https://github.com/wshafer/psr11-monolog
Informations about the package psr11-monolog
PSR-11 Monolog
This repository has moved and is no longer maintained. Please visit the new repo here: https://gitlab.com/blazon/psr11-monolog
Monolog Factories for PSR-11
Table of Contents
- Installation
- Usage
- Containers
- Pimple
- Zend Service Manager
- Frameworks
- Zend Expressive
- Zend Framework 3
- Configuration
- Minimal Configuration
- Example
- Full Configuration
- Full Example
- Channels
- Handlers
- Log to files and syslog
- StreamHandler
- RotatingFileHandler
- SyslogHandler
- ErrorLogHandler
- ProcessHandler
- Send alerts and emails
- NativeMailerHandler
- SwiftMailerHandler
- PushoverHandler
- FlowdockHandler
- SlackWebhookHandler
- SlackHandler
- SendGridHandler
- MandrillHandler
- FleepHookHandler
- IFTTTHandler
- TelegramBotHandler
- Log specific servers and networked logging
- SocketHandler
- AmqpHandler
- GelfHandler
- CubeHandler
- ZendMonitorHandler
- NewRelicHandler
- LogglyHandler
- RollbarHandler
- SyslogUdpHandler
- LogEntriesHandler
- InsightOpsHandler
- LogmaticHandler
- SqsHandler
- Logging in development
- FirePHPHandler
- ChromePHPHandler
- BrowserConsoleHandler
- PHPConsoleHandler
- Log to databases
- RedisHandler
- MongoDBHandler
- CouchDBHandler
- DoctrineCouchDBHandler
- ElasticSearchHandler
- DynamoDbHandler
- Wrappers / Special Handlers
- FingersCrossedHandler
- DeduplicationHandler
- WhatFailureGroupHandler
- FallbackGroupHandler
- BufferHandler
- GroupHandler
- FilterHandler
- SamplingHandler
- NoopHandler
- NullHandler
- PsrHandler
- TestHandler
- OverflowHandler
- Log to files and syslog
- Formatters
- LineFomatter
- HtmlFormatter
- NormalizerFormatter
- ScalarFormatter
- JsonFormatter
- WildfireFormatter
- ChromePHPFormatter
- GelfMessageFormatter
- LogstashFormatter
- ElasticaFormatter
- LogglyFormatter:
- FlowdockFormatter
- MongoDBFormatter
- LogmaticFormatter
- Processors
- PsrLogMessageProcessor
- IntrospectionProcessor
- WebProcessor
- MemoryUsageProcessor
- MemoryPeakUsageProcessor
- ProcessIdProcessor
- UidProcessor
- GitProcessor
- MercurialProcessor
- TagProcessor
- HostnameProcessor
- Minimal Configuration
- Upgrades
- Version 2 to version 3
- Version 1 to version 2
Installation
Usage
Additional info can be found in the documentation
Containers
Any PSR-11 container wil work. In order to do that you will need to add configuration
and register a new service that points to WShafer\PSR11MonoLog\MonologFactory
Below are some specific container examples to get you started
Pimple
Zend Service Manager
Frameworks
Any framework that use a PSR-11 should work fine. Below are some specific framework examples to get you started
Zend Expressive
You'll need to add configuration and register the services you'd like to use. There are number of ways to do that
but the recommended way is to create a new config file config/autoload/monolog.global.php
Configuration
config/autoload/monolog.global.php
Zend Framework 3
You'll need to add configuration and register the services you'd like to use. There are number of ways to do that
but the recommended way is to create a new config file config/autoload/monolog.global.php
Configuration
config/autoload/monolog.global.php
Module Config
If you're not using the Zend Component Installer you will also need to register the Module.
config/modules.config.php (ZF 3 skeleton)
config/application.config.php (ZF 2 skeleton)
Configuration
Monolog uses four types of services that will each need to be configured for your application.
In addition you will need to create a named service that maps to the \WShafer\PSR11MonoLog\MonologFactory
based on the container you are using.
-
Named Services : These are services names wired up to a factory. The configuration will differ based on the type of container / framework in use.
-
Channels : 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 here.
Picture two loggers sharing a handler that writes to a single log file. Channels allow you to identify the logger that issued every record. You can easily grep through the log files filtering this or that channel.
-
Handlers : These services do all the heavy lifting and log your message to the wired up system. There are many different handlers available to you, but he one you will most likely want to use for basic file logging is the StreamHandler. Tip: You can use the same handler for multiple channels.
-
Formatters : (Optional) Formatters are in charge of formatting the message for the handler. Generally you can use the defualt formatter for the handler you are using, in some circumstances you may however want to change the formatting of the message. Configuring a formatter will let you customize the message being sent to the log.
- Processors : (Optional) Processors can be used to add data, change the message, filter, you name it. Monolog provides some built-in processors that can be used in your project. Look at the Processors section for the list.
Minimal Configuration
A minimal configuration would consist of at least one default handler and one named service. Please note that if you don't specify a default handler a NullHandler will be used when you wire up the default logger.
Minimal Example (using Zend Expressive for the example):
Full Configuration
Full Example
Channels
Handlers
Log to files and syslog
StreamHandler
Logs records into any PHP stream, use this for log files.
Monolog Docs: StreamHandler
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.
Monolog Docs: RotatingFileHandler
SyslogHandler
Logs records to the syslog.
Monolog Docs: SyslogHandler PHP openlog(): openlog
ErrorLogHandler
Logs records to PHP's error_log() function.
Monolog Docs: ErrorLogHandler
ProcessHandler
Logs records to the STDIN of any process, specified by a command.
Monolog Docs: ProcessHandler
Send alerts and emails
NativeMailerHandler
Sends emails using PHP's mail() function.
Monolog Docs: NativeMailerHandler
SwiftMailerHandler
Sends emails using a Swift_Mailer instance.
Monolog Docs: SwiftMailerHandler
PushoverHandler
Sends mobile notifications via the Pushover API.
Monolog Docs: PushoverHandler
FlowdockHandler
Logs records to a Flowdock account.
Monolog Docs: FlowdockHandler
SlackWebhookHandler
Logs records to a Slack account using Slack Webhooks.
Monolog Docs: SlackWebhookHandler
SlackHandler
Logs records to a SlackHandler account using the Slack API (complex setup).
Monolog Docs: SlackHandler
SendGridHandler
Sends emails via the SendGrid API.
Monolog Docs: SendGridHandler
MandrillHandler
Sends emails via the Mandrill API using a Swift_Message instance.
Monolog Docs: MandrillHandler
FleepHookHandler
Logs records to a Fleep conversation using Webhooks.
Monolog Docs: FleepHookHandler
TelegramBotHandler
Logs records to a Telegram bot account.
Monolog Docs: TelegramBotHandler
Log specific servers and networked logging
SocketHandler
Logs records to sockets, use this for UNIX and TCP sockets. See an example.
Monolog Docs: SocketHandler
AmqpHandler
Logs records to an AMQP compatible server. Requires the php-amqp extension (1.0+) or the php-amqplib library.
Monolog Docs: AmqpHandler
GelfHandler
Logs records to a Graylog2 server. Requires package graylog2/gelf-php.
Monolog Docs: GelfHandler
CubeHandler
Logs records to a Cube server.
Note: Cube is not under active development, maintenance or support by Square (or by its original author Mike Bostock). It has been deprecated internally for over a year.
Monolog Docs: CubeHandler
ZendMonitorHandler
Logs records to the Zend Monitor present in Zend Server.
Monolog Docs: ZendMonitorHandler
NewRelicHandler
Logs records to a NewRelic application.
Monolog Docs: NewRelicHandler
LogglyHandler
Logs records to a Loggly account.
Monolog Docs: LogglyHandler
RollbarHandler:
Logs records to a Rollbar account.
_Note: RollerbarHandler is out of date with upstream changes. In addition the Rollerbar library suggests using the PsrHandler instead. See Rollerbar Docs for how to set this up.
Monolog Docs: RollbarHandler
SyslogUdpHandler
Logs records to a remote Syslogd server.
Monolog Docs: SyslogUdpHandler
LogEntriesHandler
Logs records to a LogEntries account.
Monolog Docs: LogEntriesHandler
InsightOpsHandler
Logs records to an InsightOps account.
Monolog Docs: InsightOpsHandler
LogmaticHandler
Logs records to a Logmatic account.
Monolog Docs: LogmaticHandler
SqsHandler
Logs records to an AWS SQS queue.
Monolog Docs: SqsHandler
Logging in development
FirePHPHandler
Handler for FirePHP, providing inline console messages within FireBug.
Note: The Firebug extension isn't being developed or maintained any longer.
Monolog Docs: FirePHPHandler
ChromePHPHandler
Handler for ChromePHP, providing inline console messages within Chrome.
Monolog Docs: ChromePHPHandler
BrowserConsoleHandler
Handler to send logs to browser's Javascript console with no browser extension required. Most browsers supporting console API are supported.
Monolog Docs: BrowserConsoleHandler
PHPConsoleHandler
Handler for PHP Console, providing inline console and notification popup messages within Chrome.
Monolog Docs: PHPConsoleHandler
Logging in development
RedisHandler
Logs records to a Redis server. Requires the php-redis extension or the Predis library.
Monolog Docs: RedisHandler
MongoDBHandler
Handler to write records in MongoDB via a Mongo extension connection.
Monolog Docs: MongoDBHandler
CouchDBHandler
Logs records to a CouchDB server.
Monolog Docs: CouchDBHandler
DoctrineCouchDBHandler
Logs records to a CouchDB server via the Doctrine CouchDB ODM.
Monolog Docs: DoctrineCouchDBHandler
ElasticaHandler
Logs records to an Elastic Search server.
Monolog Docs: ElasticSearchHandler
DynamoDbHandler
Logs records to a DynamoDB table with the AWS SDK.
Monolog Docs: DynamoDbHandler
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.
Monolog Docs: FingersCrossedHandler
DeduplicationHandler
Useful if you are sending notifications or emails when critical errors occur. It takes a logger as parameter and will accumulate log records of all levels until the end of the request (or flush() is called). At that point it delivers all records to the handler it wraps, but only if the records are unique over a given time period (60 seconds by default). If the records are duplicates they are simply discarded. The main use of this is in case of critical failure like if your database is unreachable for example all your requests will fail and that can result in a lot of notifications being sent. Adding this handler reduces the amount of notifications to a manageable level.
Monolog Docs: DeduplicationHandler
WhatFailureGroupHandler
This handler extends the GroupHandler ignoring exceptions raised by each child handler. This allows you to ignore issues where a remote tcp connection may have died but you do not want your entire application to crash and may wish to continue to log to other handlers.
Monolog Docs: WhatFailureGroupHandler
FallbackGroupHandler
This handler extends the GroupHandler ignoring exceptions raised by each child handler, until one has handled without throwing. This allows you to ignore issues where a remote tcp connection may have died but you do not want your entire application to crash and may wish to continue to attempt log to other handlers, until one does not throw.
Monolog Docs: FallbackGroupHandler
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.
Monolog Docs: BufferHandler
GroupHandler
This handler groups other handlers. Every record received is sent to all the handlers it is configured with.
Monolog Docs: GroupHandler
FilterHandler
Simple handler wrapper that filters records based on a list of levels
Monolog Docs: FilterHandler
SamplingHandler
A sampled event stream can be useful for logging high frequency events in a production environment where you only need an idea of what is happening and are not concerned with capturing every occurrence. Since the decision to handle or not handle a particular event is determined randomly, the resulting sampled log is not guaranteed to contain 1/N of the events that occurred in the application, but based on the Law of large numbers, it will tend to be close to this ratio with a large number of attempts.
Monolog Docs: SamplingHandler
NoopHandler
This handler handles anything by doing nothing. It does not stop processing the rest of the stack. This can be used for testing, or to disable a handler when overriding a configuration.
Monolog Docs: NoopHandler
NullHandler
Any record it can handle will be thrown away. This can be used to put on top of an existing stack to override it temporarily.
Monolog Docs: NullHandler
PsrHandler
Can be used to forward log records to an existing PSR-3 logger
Monolog Docs: PsrHandler
TestHandler
Used for testing, it records everything that is sent to it and has accessors to read out the information.
Monolog Docs: TestHandler
OverflowHandler
This handler will buffer all the log messages it receives, up until a configured threshold of number of messages of a certain lever is reached, after it will pass all log messages to the wrapped handler. Useful for applying in batch processing when you're only interested in significant failures instead of minor, single erroneous events.
Monolog Docs: OverflowHandler
Formatters
LineFomatter
Formats a log record into a one-line string.
Monolog Docs: LineFormatter
HtmlFormatter
Used to format log records into a human readable html table, mainly suitable for emails.
Monolog Docs: HtmlFormatter
NormalizerFormatter
Normalizes objects/resources down to strings so a record can easily be serialized/encoded.
Monolog Docs: NormalizerFormatter
ScalarFormatter
Used to format log records into an associative array of scalar values.
Monolog Docs: ScalarFormatter
JsonFormatter
Encodes a log record into json.
Monolog Docs: JsonFormatter
WildfireFormatter
Used to format log records into the Wildfire/FirePHP protocol, only useful for the FirePHPHandler.
Monolog Docs: WildfireFormatter
ChromePHPFormatter
Used to format log records into the ChromePHP format, only useful for the ChromePHPHandler.
Monolog Docs: ChromePHPFormatter
GelfMessageFormatter
Used to format log records into Gelf message instances, only useful for the GelfHandler.
Monolog Docs: GelfMessageFormatter
LogstashFormatter
Used to format log records into logstash event json, useful for any handler listed under inputs here.
Monolog Docs: LogstashFormatter
ElasticaFormatter
Used to format log records into logstash event json, useful for any handler listed under inputs here.
Monolog Docs: ElasticaFormatter
LogglyFormatter
Used to format log records into Loggly messages, only useful for the LogglyHandler.
Monolog Docs: LogglyFormatter
FlowdockFormatter
Used to format log records into Flowdock messages, only useful for the FlowdockHandler.
Monolog Docs: FlowdockFormatter
MongoDBFormatter
Converts \DateTime instances to \MongoDate and objects recursively to arrays, only useful with the MongoDBHandler.
Monolog Docs: MongoDBFormatter
LogmaticFormatter
User to format log records to Logmatic messages, only useful for the LogmaticHandler.
Monolog Docs: LogmaticFormatter
Processors
PsrLogMessageProcessor
Processes a log record's message according to PSR-3 rules, replacing {foo} with the value from $context['foo'].
Monolog Docs: PsrLogMessageProcessor
IntrospectionProcessor
Adds the line/file/class/method from which the log call originated.
Monolog Docs: IntrospectionProcessor
WebProcessor
Adds the current request URI, request method and client IP to a log record.
Monolog Docs: WebProcessor
MemoryUsageProcessor
Adds the current memory usage to a log record.
Monolog Docs: MemoryUsageProcessor
MemoryPeakUsageProcessor
Adds the peak memory usage to a log record.
Monolog Docs: MemoryPeakUsageProcessor
ProcessIdProcessor
Adds the process id to a log record.
Monolog Docs: ProcessIdProcessor
UidProcessor
Adds a unique identifier to a log record.
Monolog Docs: UidProcessor
GitProcessor
Adds the current git branch and commit to a log record.
Note: Only works if the git executable is in your working path.
Monolog Docs: GitProcessor
MercurialProcessor
Adds the current hg branch and commit to a log record.
Note: Only works if the hg executable is in your working path.
Monolog Docs: MercurialProcessor
TagProcessor
Adds an array of predefined tags to a log record.
Monolog Docs: TagProcessor
HostnameProcessor
Adds the current hostname to a log record.
Monolog Docs: HostnameProcessor
Upgrades
Version 2 to Version 3
Version 3 upgrade the Monolog package from version 1 to version 2. This has many breaking changes with it. Please see the UPGRADE.md for a list changes upstream.
This package also now requires PHP 7.2.
Version 1 to Version 2
When upgrading from version 1 to version 2, there shouldn't be any changes needed. Please note that using the ChannelChanger directly is no longer recommended. Named services should be used instead. See above for more info.
Changes
- A "default" channel entry and handler is added automatically to the config. This default channel requires you to either specify a configured handler for the channel OR there must be a 'default' channel configured in order to use it. Most Version 1 users should not have an issue with this change and the factories should still function normally.