One logger to rule them all

I called the vote on the Logger Interface proposal last week. When the vote ends next week it will become PSR-3 (since it already collected a majority). The fourth recommendation from the PHP-FIG group, and the first one actually including interfaces/code, which is a great milestone.

You can read the proposal if you have not done so yet, but I wanted to discuss the goal and long term hopes I have in more details here.

Where we come from

Most PHP frameworks and larger applications have in the past implemented their own logging solutions and this makes sense since I think everyone recognizes the usefulness of logs. Traditionally most of those did not have many external dependencies, established libraries were few and far between. Having no logging capability in those was not such a hindrance.

Libraries deserve logs too

Yet in the last couple years, thanks to GitHub allowing easier sharing, composer allowing more reusability, and mentalities shifting slowly to a less-NIH approach, we are seeing more and more libraries used in applications and even by frameworks themselves. This is great, but as soon as you call a library you enter a black box and if you want anything to show up in your logs you have to log yourself.

The availability of the PSR-3 interface means that libraries can optionally accept a Psr\Log\LoggerInterface instance, and if it is given to them they can log to it. That opens up a whole lot of possibilities for tighter integration of libraries with the framework/application loggers. I really hope library developers will jump on this and start logging more things so that when things go south it is easier to identify problems by looking at your application logs.

Take a deep breath

I am sure people will have questions or complaints regarding details of the interface itself, but I hope this helped you see the broader benefits it brings.

December 13, 2012 // PHP

Post a comment

Subscribe to this RSS Feed Comments

2012-12-20 18:49:29


Good work, thanks for driving this!

2012-12-20 19:01:26

Eugene OZ

It's all my subjective opinion, but I hope it's communty.

4. PSR-0, 1 and 2 MUST be followed.
MUST? PSR-2 is set of useless subjective rules. I don't like "spaces instead tabs" rule, and it will be violation of PSR-3? Ridiculous.

5. The vendor namespace MUST be `Psr`.
Shouldn't be the vendor name? Hm...

7. Composer package MUST be named `psr/<package>` e.g. `psr/log`.

Composer is already part of PHP or some "php standards"?
I don't like Composer and will not use Composer, so it's violation of this "standard"?

Standards should not work against the freedom.

2012-12-20 19:04:48


@Eugene: Please try and read more carefully. What you are complaining about here is the bylaw about naming things in PHP-FIG code. It is not a PSR, it's a bylaw. It just says how the PHP-FIG should act, but it is not a recommendation to anyone else. And it is only logical that PHP-FIG abides by its own rules. In any case this is unrelated to the LoggerInterface PSR.

2012-12-20 19:16:34


Good work!

My only regret is that

$logger->debug("hello  {}, welcome", [$name]);

is not possible (you have to use indexes), but that's a minor complaint.

Eugene: those rules apply to future PSR (like PSR-3, the LoggerInterface).

Implementations (for example YOUR code) are not subject to those rules.

2012-12-20 20:02:06


deep breath

what is the current extent of monolog in terms of libraries already able to receive something like monolog?

Also if frameworks would have this kind of interface and not only libraries.


2012-12-21 12:55:15

Magnus Nordlander

This is great! I've been following the discussion in the mailing list and I'm very glad this finally will pass, despite all of the near-infinitely extended discussions regarding the placeholder syntax :)

Keep up the good work!

2012-12-23 13:03:52


This looks super mundane. But it's supposed to be a common denominator interface, I guess? At least it allows to go beyond an inextensible set of 1:1 php notice level translitarations. Not sure about the mixed $level; though looks a bit indecisive, even though the consts presuppose it stringy of course. But why aren't generic exceptions then earmarked for?

(I'd hope we would advance to structured logs / journals also somewhen. Currently implies texty logs.)

2012-12-26 13:16:58


awesome, congratulations! really looking forward to see this one happen.