[5.6] Rework Logging

[taylorotwell]

This is a re-write / re-work of many of @phroggyy's ideas to improve logging.

Implemented:

• Multi-driver logging support so you can have multiple logging channels per app.
• "Pipes" in @phroggyy's pull request have been re-worked as "taps". Allows customization of logging channel post-creation.
• Continued support for functionality provided by configureMonologUsing maintained using custom driver type with factory invokable that returns any PSR3 compatible logger. This allows full customization of entire logging channel.

I decided not to implement Log::event functionality from PR because I think that would be better suited for something like a ShouldLog interface on the event itself (to complement ShouldBroadcast, etc.).

Primary breaking changes:

• New log configuration file / settings.
• configureMonologUsing now custom driver type.
• Illuminate\Contracts\Log removed. Was literal duplication of PSR3 logging interface.
• Illuminate\Log\Writer renamed to Illuminate\Log\Logger.

[phroggyy]

Not sure I agree on a watch method – I don't see why our application should react to any kind of log message, instead you'd react to an exception thrown or similar. Can you explain the use-case for watch

[phroggyy]

It would be advisable to pass the exception in the context as monolog provides special exception rendering:

$logger->emergency('Unable to create configured logger. Using emergency logger.', ['exception' => $e]);

[taylorotwell]

Ah OK, Thanks

[phroggyy]

I don't see why we should call __invoke() manually here, seems dirty if we're not using __invoke for its purpose (treating an object as a method essentially), might as well use another method name then.

[taylorotwell]

Do you have a method name suggestion?

[phroggyy]

handle would follow the middleware standard. process or execute could be options too

[mfn]

The why I learnt to expect how handle works, is that it's arguments were resolved by the Container and injected (think: Console commands and Jobs).

[phroggyy]

Could you include an example of what the new config file will look like @taylorotwell?

[sisve]

Is it possible to keep the old Writer class, mark it deprecated, and have it forward calls to the new code? Just to give people some time to migrate their old code?

[taylorotwell]

@sisve I don’t plan on doing that. The migration isn’t large enough to warrant it.

[GrahamCampbell]

Laravel 5.5 LTS will still be around after 5.6 is released, so people have some time if they need it.

[taylorotwell]

@phroggyy I'm fine with removing watch method.

[taylorotwell]

Here is what the basic logging configuration file would look like:

<?php

return [

    'default' => env('LOG_CHANNEL', 'single'),

    'channels' => [
        'single' => [
            'driver' => 'single',
            'tap' => [App\Log\ConfigureLogger::class],
            'path' => storage_path('logs/laravel.log'),
            'level' => 'debug',
        ],

        'daily' => [
            'driver' => 'daily',
            'path' => storage_path('logs/laravel.log'),
            'level' => 'debug',
            'days' => 3,
        ],

        'syslog' => [
            'driver' => 'syslog',
            'level' => 'debug',
        ],

        'errorlog' => [
            'driver' => 'errorlog',
            'level' => 'debug',
        ],
    ],

];

[taylorotwell]

Removed watch method and made other recommended changes.