Logs

Your application's log records, in the panel, beside the exceptions and requests they belong to.

Turning it on

Two things: the channel, and the application feature.

'channels' => [
    'stack' => [
        'driver' => 'stack',
        'channels' => ['single', 'larabug', 'larabug-logs'],
        'ignore_exceptions' => false,
    ],

    'larabug-logs' => [
        'driver' => 'larabug-logs',
        'level' => 'info',
    ],
],

Then accept Logs on the application.

The two channels are different things

Most applications want both. They answer different questions, and neither is a replacement for the other.

The level

'logs' => [
    'level' => env('LB_LOGS_LEVEL', 'info'),
],

info and up by default. The channel's own level wins over this one, which is what lets a stack write everything to disk and ship only warnings to LaraBug.

Debug is a level, not a plan. An application at debug in production will spend its allowance on log lines rather than on the errors it took them to explain.

What is sent

The timestamp, the level, the channel, the message, the context and Monolog's extra, the environment and the release.

Plus the three things that make a line worth having: the trace id, so the record sits with the request or job that wrote it; the exception id, when the record was written alongside one; and the user identifier, when there is one.

An exception key in the context is dropped before sending. It is the largest thing in the payload, and it arrives properly as an exception through the other channel.

Context

'max_context_keys' => env('LB_LOGS_MAX_CONTEXT_KEYS', 50),

Context is sent as given, so the rule is the one from filtering sensitive data: what you put in a log line is what gets stored. Objects are reduced to their class name rather than serialised, and long values are truncated.

Batching

logs.batch_size is fifty, logs.max_retries is three, and the buffer is flushed when the application terminates. A request that logs forty lines makes one call, not forty.

Deprecations

Laravel throws its deprecation warnings away unless you tell it otherwise: logging.deprecations points at the null channel. Clients newer than 4.0.0-beta.12 add LaraBug to that channel themselves, next to wherever you already send them, and logs.deprecations in config/larabug.php turns it off.

They arrive as warnings on the deprecations channel, so Logs has to be accepted on the application. A deprecation fires on every call, so the client sends each one the first time it happens in a process and then at most once an interval, with a count of how many times it happened in between. Each record carries the file and line it was raised at and whether PHP or Laravel raised it.

LaraBug opens one issue per deprecation, at low priority, the first time it sees one. A deprecation is a file, a line and a message with its values taken out, so "Implicit conversion from float 6360.07 to int" and the same line with another float are one issue, titled with {n} where the number was, and the issue quotes one of the messages as it arrived. The issue names the message, the file and line, how many times it happened over the last day, and when it was first and last seen. It also says whether the file is yours or under vendor/: a deprecation in your code is fixed by changing that line, and one in a package by upgrading the package.

The issue resolves itself once the deprecation has not been seen for seven days. Older clients send no deprecations, and nothing is opened for them.