Convert all log messages to PSR-3 format with placeholders

[hason]

It should be used for logging context instead of sprintf.

Before:

$this->logger->info(sprintf('Matched route "%s".', $parameters['_route'] ?? 'n/a'))

After:

$this->logger->info('Matched route "{route}".', ['route' => $parameters['_route'] ?? 'n/a'])

It is still possible to log human-readable messages with PsrLogMessageProcessor, which can be activated on a per-handler basis.

This can be really useful for subsequent processing in logfile monitoring systems as it makes it easier to identify similar messages.

[javiereguiluz]

@hason we must use "old PHP", so the new code would be instead:

$this->logger->info(
    'Matched route "{route}".',
    array('route' => isset($parameters['_route']) ? $parameters['_route'] : 'n/a')
);

[Pierstoval]

+1 for Javier.

This would turn into BC breaks, so I suggest thinking about this great idea for the 3.0 branch.

I'm 👍 on this 😄

[hason]

@javiereguiluz @Pierstoval I've used the new syntax for its brevity. It is used even in the Before sample.

[derrabus]

Thinking out loud: This semantic could also be used to highlight the variable parts of a log message when rendering the log in the Symfony Profiler.

[javiereguiluz]

@derrabus highlighting log messages is on my TODO list for the profiler. Now that it's been merged, I'll think about it again!

[derrabus]

My point is: Highlighting is hard, if you just have plain text messages, like when composing the messages with sprinf() or string concatenation. You would have to guess, what could be the important part of a log message. Okay, in the example above, the quotes would be a good indicator, but that assumption won't always work.

But if you get a template of the log message with variables to fill in, highlighting the variable part would probably improve the readability.

[lyrixx]

May be it's too late to discuss about this PR / issue but I'm against it. I really don't see the value added by this (all stuff related into the PSR + Monolog).

My point of view:

It's very useful for message with a level superior to the level that trigger the cross finger (ie warning / error or more). But for others (debug / info) errors it's IMHO useless. It's useless because there is no need to aggregate log message like Notified event "{event}" to listener "{listener}". You have to register a new processor to do the strtr jobs in order to be able to read the logs.

More over, without code it's not possible to strtr notice / info / debug message but to let error+ message.

Could we consider re-opening this this ?