I'd also like to see a laracast on best practices and ideas for logging

Yea indeed @moak, let's log this to @jeffreyway :D

I made a suggestion here https://laracasts.com/discuss/channels/requests/logging-with-laravel If people support it will that maybe catch his attention?

I wanted to use something like this yesterday in one of my apps. Would like to see some options for multiple files as well. Having everything in one file makes it hard to find the relevant info.

Indeed @bashy

Saw this yesterday: https://github.com/GrahamCampbell/Laravel-LogViewer

Haven't tried it but looks like it splits up the different types by reading the single file.

http://www.chrisduell.com/blog/development/using-custom-monolog-handlers-in-laravel/

This tutorial shows generally how to grab the Monolog instance from laravel and use a custom handler.

@toltech That's for Laravel 4 :)

True. Alright heres a direct answer to the question being asked in this thread (for L5):

You can override the Illuminate\Foundation\Bootstrap\ConfigureLogging Class in the Bootstrap directory (as the documentation states).

Steps are:

1. Create a ConfigureLogging Class in the /bootstrap directory that implements the configureHandlers() method from Illuminate\Foundation\Bootstrap\ConfigureLogging.
2. Open App/Console/Kernal.php. It extends ConsoleKernal, which has a $bootstrappers attribute. Overwrite that attribute in App/Console/Kernal.php and register your new /bootstrap/ConfigureLogging class:

// App/Console/Kernal.php
...
class Kernel extends ConsoleKernel {

    /**
     * OVERRIDING PARENT CLASS
     * The bootstrap classes for the application.
     *
     * @var array
     */
    protected $bootstrappers = [
        'Illuminate\Foundation\Bootstrap\DetectEnvironment',
        'Illuminate\Foundation\Bootstrap\LoadConfiguration',
        'Illuminate\Foundation\Bootstrap\HandleExceptions',
        'Illuminate\Foundation\Bootstrap\RegisterFacades',
        'Illuminate\Foundation\Bootstrap\SetRequestForConsole',
        'Illuminate\Foundation\Bootstrap\RegisterProviders',
        'Illuminate\Foundation\Bootstrap\BootProviders',
        'Bootstrap\ConfigureLogging' // custom logger bootstrapper
    ];
...

3. Do the same for app/Http/Kernal.php
4. Register your new new bootstrap namespace in composer.json and run composer dumpautoload. My namespace is Bootstrap.

// composer.json
...
"autoload": {
        "psr-4": {
                "Bootstrap\\": "bootstrap/"
        }
    },
...

5. Implement the custom handlers you want in the configureHandlers method in /bootstrap/ConfigureLogging. Something like:

// bootstrap/ConfigureLogging
<?php namespace Bootstrap;

use Monolog\Logger as Monolog;
use Illuminate\Log\Writer;
use Illuminate\Contracts\Foundation\Application;
use Illuminate\Foundation\Bootstrap\ConfigureLogging as BaseConfigureLogging;
use Monolog\Handler\StreamHandler;

class ConfigureLogging extends BaseConfigureLogging{

    /**
     * OVERRIDE PARENT
     * Configure the Monolog handlers for the application.
     *
     * @param  \Illuminate\Contracts\Foundation\Application  $app
     * @param  \Illuminate\Log\Writer  $log
     * @return void
     */
    protected function configureHandlers(Application $app, Writer $log)
    {

        $bubble = false;

        // Stream Handlers
        $infoStreamHandler = new StreamHandler( storage_path("/logs/laravel_info.log"), Monolog::INFO, $bubble);
        $warningStreamHandler = new StreamHandler( storage_path("/logs/laravel_warning.log"), Monolog::WARNING, $bubble);
        $errorStreamHandler = new StreamHandler( storage_path("/logs/laravel_error.log"), Monolog::ERROR, $bubble);

        // Get monolog instance and push handlers
        $monolog = $log->getMonolog();
        $monolog->pushHandler($infoStreamHandler);
        $monolog->pushHandler($warningStreamHandler);
        $monolog->pushHandler($errorStreamHandler);

        $log->useDailyFiles($app->storagePath().'/logs/daily.log');
    }

One note on that snippet, the order you push the streamhandlers on is important: push the most restrictive on last, so that it is hit first. Otherwise, say if you pushed the infoStreamHandler on last, it would log everything above it also and an error wouldn't make it to the error handler.

This will result in 3 log files:

• laravel_error.log - just errors
• laravel_info.log - just info
• laravel_warning.log - just warnings *daily log file - all

A related question was asked which I also answered.

This was helpful, however I was implementing a mysql connection for my logs using wazarri/monolog-mysql and ran into issues with the DB facade not being fully setup. Essentially, the Bootstrap/ConfigureLogging class was being bootstrapped before the DB was being setup. Here's how I fixed that in case anyone else is trying this. This is in app\Http\Kernel.php. I like this method because it not only replaces the Bootstrap for logging, but also moves it to the end of the stack so everything else is ready for use.

/**
     * Constructor
     */
    public function __construct(Application $app, Router $router)
    {
        parent::__construct($app, $router);

        foreach($this->bootstrappers as $key => $boostrapper)
        {
            if($boostrapper === 'Illuminate\Foundation\Bootstrap\ConfigureLogging')
            {
                unset($this->bootstrappers[$key]);

            }
        }
        $this->bootstrappers[] = 'Bootstrap\ConfigureLogging';
    }

You can have full control over your log configuration without having to remove the built in ConfigureLogging bootstrapper. The app has a configureMonologUsing function which gives you everything you need. More details under "Custom Monolog Configuration" here: http://laravel.com/docs/5.1/errors#configuration

As @jclermont stated, you can easily do this without all the work mentioned in the best answer.

Inside bootstrap\app.php you can simply add the following:

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

$app->configureMonologUsing(function($monolog) {
    $monolog->pushHandler(new StreamHandler(storage_path('logs/laravel_info.log'), Logger::INFO));
    $monolog->pushHandler(new StreamHandler(storage_path('logs/laravel_warning.log'), Logger::WARNING));
});

Simply repeat the call to pushHandler() with your remaining severity levels.

@Phil_S, that works great.

Does anyone know how to setup monolog to send the same messages to two different places? For example, what if I wanted to send errors (and higher) to loggly while still having complete local log files? The bubble parameter indicates that this should be possible, but I can't seem to get it working.

@ui-matt, I'm not sure this is the best way, the following code writes Debug messages to laravel_debug.log AND laravel.log.

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

$app->configureMonologUsing(function ($monolog) {
    $monolog->pushHandler(new StreamHandler(storage_path('logs/laravel_debug.log'), Logger::DEBUG, false));
    $monolog->pushHandler(new StreamHandler(storage_path('logs/laravel.log'), Logger::DEBUG, true));
    $monolog->pushHandler(new StreamHandler(storage_path('logs/laravel.log'), Logger::INFO, false));
});

Here log path is changed according to log levels. But what if, i have two different path for log files each contains log with all levels or custom configured level?

For example I have two paths for Api Logs and Sms Logs having different path.

How can i define two logs? currently logging is done like
ex Log::emergency('Log string'); This string is logged according to defined stream handler of emergency level.

But instead i want this log to write in API path log or Sms path log.

@udgeet I guess, you might need a new facade for this. Laravel's Log also is only a facade, and you can create your own facades for your custom loggers. Here is my example of some abstract BusinessLog facade

namespace App\Services\Facades;

use Illuminate\Support\Facades\Facade;

class BusinessLog extends Facade
{
    /**
     * Get the registered name of the component.
     *
     * @return string
     */
    protected static function getFacadeAccessor()
    {
        return "log.business";
    }
}

In my case, I also took the opportunity to specify completely custom line formats etc., so here's how you could implement custom logging handler:

namespace App\Services\Log;

use Illuminate\Log\Writer;

use Monolog\Logger as Monolog;
use Monolog\Formatter\LineFormatter;
use Monolog\Handler\RotatingFileHandler;

class BusinessLogWriter extends Writer
{
    // you can customize these as you wish
    const LINE_FORMAT = "[%datetime%] %level_name%: %message% %context% %extra%\n";
    
    /**
     * Creator for convenient reuse of some Writer functions
     * 
     * @return Monolog
     */
    public function createLogger($path, $numOfKeepFiles, $level)
    {
        // create business logger with prefix
        $log = new Monolog("business");
        
        // create the kind of handler as you wish
        $handler = new RotatingFileHandler(
                $path, 
                $numOfKeepFiles,
                $this->parseLevel($level));  
        
        $handler->setFormatter(
            new LineFormatter(static::LINE_FORMAT, null, true, true));
        
        $log->pushHandler($handler);

        return $log;
    }
}

And then in providers/AppServiceProvider:

$this->app->instance("log.business", 
            (new BusinessLogWriter())
            ->createLogger(
                $this->app->storagePath()."/logs/business/business.log",
                config("app.log_max_files", 0), // how long to keep - default will be forever
                config("app.log_level", "debug")
            ));

After a full day of head scratching, I've finally nailed a nasty side-effect of the chosen answer.

If you install newrelic with those changes the entire framework will stop responding with the infamous Uncaught exception 'ReflectionException' with message 'Class log does not exist'

At least in my case, in order to avoid that, the only thing I need to do was to swap the order of Bootstrap\ConfigureLogging and move it to the third position of $bootstrappers, respecting this way the framework original order.

After reading some more answers here, I do think that the answer of @jclermont is actually the best one.

As my app was big, I needed separate log files, and maintain the existing Laravel's Log interface as much as possible. I needed something like:

Log::write('audit', 'User logged in to the app.');

or

Log::info('event', 'User sent out 2 emails.');

Here is my solution in detail if you need something similar: http://stackoverflow.com/questions/37809989/laravel-5-2-custom-log-file-for-different-tasks/40218479#40218479

@sharq Would it be possible for you to tag your logs in the log message, such as resource:event/resource:audit. My monolog message is basically a json payload with structures like

[2016 - 11 - 16 00: 37: 28] lumen.INFO: Commencing job attempt. 
"payload": {
    "pid": 24273,
    "job_id": "ec908bd5-e024-44ab-a734-150cc7223eb3",
        "resource": "events"
}

Also in addition to @toltech answer, one can have daily log files by adding these lines to __construct method:

$this->channels['event']['path'] = 'logs/audit-' . date('Y-m-d') . '.log';
$this->channels['audit']['path'] = 'logs/audit-' . date('Y-m-d') . '.log'; 

What about if I wanted to log to two different log files explicitly?

Say... logging debug information for client1's endpoint to /logs/laravel_client1.log and then debug information for client2's endpoint to /logs/laravel_client2.log

@ludo237 try this https://github.com/tolawho/loggy