Namespaced logger configuration

[PavelLoparev]

Hi, guys.

I think it would be nice to have a possibility to define namespace/class loggers. So I wrote monolog-cascade-namespaced library. It allows developers to have loggers for specific classes or loggers which will log all the messages from the classes which are in some namespace etc. You know, log4j style. If you need specific logger configuration in the place where you've instantiated it - just set up needed handlers/processors for a needed logger in a config file. Otherwise, you will be given a default logger.

Just want to know your opinion on this. Do you have any plans to implement something like this directly in monolog-cascade? If yes I would get it done. The reason why I haven't made a pull-request to monolog-cascade initially is I just thought it's not more than a wrapper for configuring monolog loggers. But then I thought over and decided to suggest merging)

[PavelLoparev]

Hi, @jessmchung.
Could you please take a look at this?

[rantonmattei]

That was definitely the initial intent when I created Cascade, however we hit a roadblock as Monolog does not support inheriting Loggers out of the box. See Seldaek/monolog#777 that got denied and closed unfortunately.

But in your case, when you refer to "namespaced loggers", you think of Php namespaces that are used for class mapping. The original intent was a bit different. It was using namespaces to make children loggers inherit behavior from their parents:
A.B would log with any handlers, processors, etc. defined for B but also log to any handlers, processors, etc. defined for A. This use case is more generic. A or B can be anything: url path, class names, etc.

The logging Python module (that inspired Cascade) does support this out of the box and that was one the reasons of why I wrote Cascade, but it did not work eventually because of Monolog structure. Obviously you can extend Monolog and tweak it but the impact won't be the same.

As for your package, I can see some value especially when developing and/or debugging, however I don't know if I would use this kind of logging on Production except for very specific cases or implementation (let's say with some design patterns, etc.) I find it odd to link loggers to specific classes and I'm pretty sure you can achieve the same thing with processors (see IntrospectionProcessor)

Thanks for your interest in Cascade!
Cheers,
Raf

[PavelLoparev]

Yes, we're talking about a bit different concepts of "namespace" loggers. But anyway I want to clarify the main idea of "namespaced cascade" because seems like I haven't managed to articulate it clearly.

I find it odd to link loggers to specific classes and I'm pretty sure you can achieve the same thing with processors (see IntrospectionProcessor)

The idea not only in link loggers to specific classes. It helps to solve next "issues" in cascade:

1. You have to define needed loggers in advance. It means you will have to think what logger you will use in this and that class and define as many loggers as many classes you have (if you want them to use different loggers).
2. You can't dynamically change the logger which will be returned by Cascade::getLogger('my_logger') because you have hardcoded name. It means that if you want to change the logger then you will have to edit your application classes which is odd. It should be configurable in config files but not hardcoded. You may say that you don't need to edit app classes but you can change logger definition in a config file instead. Yes, you can but then the logger will be changed throughout your application where you instantiate it with Cascade::getLogger('my_logger') (instead of changing logger for one place you change it for entire application).
3. You can't define a logger for a specific class. I mean you can but then you will need to reference it by its name and you will face problem №2 from this list.
4. You can't define a logger for a specific namespace. I mean classes from My\NameSpace1 will use one logger and classes from My\NameSpace2 another.

Real life usage example: I have an application which consists of some major layers like db layer, cloud api integration layer, business logic layer etc. And I understand that I don't need debug log records from api layer (from all the classes of this layer) all the time. I need them only when I debug some edge cases. Using monolog cascade you need as many loggers defined in your config files as many classes are in your api layer. Using "namespaced" cascade you can just say "all the classes from MyNamespace\Api namespace now will use this logger with own handlers (log records with severity >= debug)" and you don't have to go through all the classes and change string values in Cascade::getLogger('my_logger'). This is the main idea of CascadeNamespaced::getLogger(get_called_class()).

I think it's something that can't be done using IntrospectionProcessor. Maybe I'm wrong? Could you please show a minimal example of how to solve all these "issues" using this processor? Maybe I'm doing something totally wrong with monolog and monolog cascade)

[rantonmattei]

Again, Cascade cannot handle this at the moment, this would have to be done at the Monolog level and after youinstantiate your logger. The namespace (channel in Monolog terminology) is determined when we set the logger to Monolog's registry right here.

What Cascade does is read a config file, configure logger(s) accordingly and set them to Monolog's registry so they are available at runtime.

Processors is one way to go. The IntrospectionProcessor might help as it adds info on the calling code into the log record. Generally speaking Processors modify your log record on the fly prior to
logging. Another solution would be to build your own to add the class namespace to the log record.

Another option would be to build a quick lib that would wrap Monolog and use its registry (or your own registry) and save your loggers to it using namespaces. You can use the same lazy loading approach as Cascade (see here).