On 12-08-18 7:39 AM, Hartmut Goebel wrote:
> Am 18.08.2012 06:30, schrieb Francois Mikus:
>> 1. Default logging level set to INFO instead of NOTSET which equates
>> to DEBUG in reality.
>>
> I suggest setting the defaullt level to WARNING. "INFO" is much to
> verbose, normally one is not interested in all this stuff.
I see this as a compromise, because the initial logging ONLY uses the
default level. As the INI files set the logging level
a bit later in the process when they start using their local log file.
Of course, this does hide some warnings or errors in the flood of messages.
>> 1. Default logging level of all INI files set to WARNING.
>>
> You probably mean: When reading the INI files, there should be used a
> logger with has default level set to WARNING and messages should be
> logged with INFO. On this I agree.
Yes, correct.
>
>> 1. Create a new logging class GENERAL, which would be set at 35,
>> between warning and error
>>
> I doubt, this is required.
> 1) <http://docs.python.org/howto/logging.html#when-to-use-logging> as a
> good overview for when to use which log-level.
> 2) E.g. postifx is logging start/stop messages with INFO level. (I just
> tested this).
I guess this comes down to the principle of least astonishment. I like
to see that start/stop messages, without the gazillion other messages. ;-)
>> 1.
>>
>>
>> 1. This logging class would serve to announce low volume general
>> interest information. Ex. Daemon X start, Module X loaded,
>> Arbiter loaded configuration. System operation, etc.
>> 2. This would serve to make warning and error level useful and
>> with basic markers as to the health of the system. (Running
>> yes or no)
>>
> Unix philosophy is: if there is no message, everything is okay.
Yes, true.
>> 1. Scripted change to add the name of the .py file at the start of
>> all logger.level("[Python-file-name] Message")
>>
> This is a standard feature of the Python standard logging module. Just
> add "%(filename)s" to the format. See
> <http://docs.python.org/library/logging.html#logrecord-attributes> for
> more of this.
Ah, this is nice. I will do this or see below the other possibility.
Namespace parameters that can be passed to logging module.
>
>> 1. This would not change or replace messages that already have
>> [something-or-other] in brackets at the start of the message.
>>
> This would require the formatter to parse the message, which ist
> time-consuming.
You misunderstood my meaning.
This change would be done by an offline one time script to do all the
files and add it to all the logger.xxx, log_mgr.xxx, self.log.xxx
messages. This would not be a runtime action.
>
>> 1. Why? This will make it easier to enable debugging, and filter
>> out messages with a few simple filters, keeping only
>> interesting stuff. Debug has way too much information that
>> can<t be filtered today.
>>
> There may (I don't know yet) be better ways to achieve this.
>
> Before implementing, please what some days. I'm already working on a new
> logging module, but need to implement performance-tests.
As mentioned earlier, this is outside of the log.py module.
There is also something in the standard logging module that permits the
identification of a namespace.
arbiter.daemon.blah
Which is passed as an option instead of embedding the source of the
message in the message itself. I have not dug too deep in how it works.
Not sure of the implications.
Thank you for the response.
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
