Following some tests..
The log_mgr variable assignments are extraneous, inluding the self.log
calls.
There is a single getLogger call done per daemon, and this instance
keeps state through out the life of the daemon, thee are no further
instantiations so logging levels are preserved globally. This is
sub-optimal if we wanted to enable different logging for a function, we
would need another logger instantiated, but that is for another time.
Now the focus is cleanup and normalize.
A pull requests incorporates these changes.
Cheers,
X
On 12-08-19 10:00 PM, Francois Mikus wrote:
> Answering myself is strange but hey, I am confused.
>
> In parts of the code, logger is used like this:
>
>
> from shinken.log import logger
> log_mgr = logger
> log_mgr.info("message")
>
> or ========
>
> from shinken.log import logger
> logger.info("message")
>
> or ========
>
> from shinken.log import logger
> self.log = logger
> self.log.load_obj(self, name)
> logger.info ('message")
>
> or ==========
>
> from shinken.log import logger
> self.log = logger
> self.log.load_obj(self)
> self.log.info("message")
>
>
> ============
>
> From what I understand of the structure. The daemon reads the config.
> daemon.py has access to the property, loads the configurable level.
> Now, should logging calls use self.log.info or logger.info for it to be
> the default class level, the per daemon level (the logger is an object
> with indepedant properties).
>
>
> Thank you for bearing with me and feel free to correct me if I
> misunderstood something.
>
> X
>
>
> On 12-08-19 8:01 PM, Francois Mikus wrote:
>> On 12-08-19 7:24 PM, Francois Mikus wrote:
>>> Another logging question.
>>>
>>>
>>> The logger module knows about the default log level.
>>> The main daemons all know about the configured logging level from the
>>> INI file and can set their respective logging instances to match the
>>> INI file level.
>>>
>>> Other objects that import the logger module never set the logging
>>> level, so are using the default which is currently NOTSET meaning
>>> DEBUG level.
>>>
>>> What is the best practice to make the logging level propagate to the
>>> rest of the program.
>>>
>> Ok, I read through , Package ipapython :: Module log_manager,
>> documentation from John Dennis. Pretty sweet logging wrapper.
>>
>> I expect that we have to do the following:
>>
>> import the logger module
>> get a logger instance from the root (or a child of the root) using
>> getLogger. Namespace is defined as the name passed in argument to
>> getLogger. Unfortunately, the Shinken log.py wrapper class does not
>> support namespaces. (I am not a python king, so correct me if I am wrong.)
>>
>> Having used get logger create get a logger instance, it should have the
>> logging level set from the root. Root instance having been defined by
>> one of the daemons which set level based on the INI.
>>
>> For debugging specific classes, the module log_manager provides a way to
>> have specific levels set for logger instances which could differ from
>> what is defined in an ancestor. (parent, grandparent, ..., root)
>>
>> For now, I will edit my changes to use getLogger and at least match the
>> logging level set from the root. If we want to use a different logging
>> wrapper module, we can do a bulk update later on. Have a good week, this
>> is one bear I want to have wrestled before 1.2.
>>
>> X
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Shinken-devel mailing list
>> Shinken-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/shinken-devel
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Shinken-devel mailing list
> Shinken-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/shinken-devel
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Shinken-devel mailing list
Shinken-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shinken-devel
