Re: logging configurator

Peter Donald wrote:
> Hi,
> 
> For a couple of years now there has been people asking for "admin oriented" 
> logging configuration in Phoenix and a few other apps. Unfortunately the 
> logging now is more oriented towards the developer rather than the end user. 
> I am currently writing up a bunch of documentation and this has become 
> painfully obvious to me. So I was planning on putting together something that 
> would make logging easier for admins.

yes - definitely a must - I'm actually dealing with such an issue atm!

> One of the best systems for admin style configuration is Unixs syslog. While 
> each different syslog daemon has a slightly different format for 
> configuration I have attached a representative format from a Mandrake linux.
> 
> You will notice that each line defines what a category (such as kern or news) 
> and a priority (such as debug or warn). Under syslog the categorys are fixed 
> and so are the prioritys.

so I take it you want to make the logging categories/propriories changeable?

> I want to use the same sort of ideas but convert it into xml and allow user 
> defined sets of levels. I was thinking about having a configuration format 
> such as 
> 
> <logging version="1.0" packages="org.spice.logconf.lib">
> 
>   <destination name="dest1" type="File" target="/var/logs/myapp.log"/>
>   <destination name="dest2" type="RotatingFile" target="/var/logs/dest2.log">
>   ...config goes here...
>   </destination>
> 
>   <channels destination="dest1">
>     <include name="*.auth"/>
>     <exclude name="http.*"/>
>     <include name="network.encoder" priority="WARN"/>
>   </channels>
> </logging>

I tend to prefer this sort of configuration, ie define your objects 
first with their config and then customise later.

> To use this you try to instantiate each destination by appending its Type to 
> the list of packages and then with out any package prefixes. In this case 
> dest1 would try to instantiate "org.spice.logconf.lib.File" and then "File" 
> destinations. Each destination is then attached to loggers that are specified 
> in channels declaration.
> 

a question:  would this configurable logging sit on top of the app 
logging, in phoenix case the environment.xml, or in place of?
it's not entirely clear from the context.
It would seems an enhancement of the <logs> target - hence a 
replacement.  But might also think of a layered approach (see below for 
more)

> Another possible configuration format being.
> 
> <logging version="1.0" packages="org.spice.logconf.lib">
> 
>   <destination name="dest1" type="File" target="/var/logs/myapp.log">
>     <channels>
>       <include name="*.auth"/>
>       <exclude name="http.*"/>
>       <include name="network.encoder" priority="WARN"/>
>     </channels>
>   </destination>
> 
>   <destination name="dest2" type="RotatingFile" target="/var/logs/dest2.log">
>     <config>
>     ...config goes here...
>     </config>
>     <channels>
>       <include name="*.auth"/>
>       <exclude name="http.*"/>
>       <include name="network.encoder" priority="WARN"/>
>     </channels>
>   </destination>
> 
> </logging>

while I prefer the first, it would pobably make sense to offer both, as 
it is quite easy to do, and let people choose which they want to use.


> It will use some of the ideas from the Excalibur logger toolkit but probably 
> be more focused on providing admins ease of use and easy mechanism to 
> validate logging configs. Some people have also asked for the ability to 
> throw exceptions when a new logger category is created that has not been 
> accounted for.
> 
> Thoughts? 

+1 on the idea.  My first thought is on the issue of the design aim:
do we aim for a logging component that will be used by phoenix and other 
apps, or for something that is app-agnostic and simply filters according 
to the configuration chosen?

Off the top of my head I would think that the second approach would be
less binding wrt the app, more generic and more powerful.
Essentially, we could provide views on a set of log files (which can 
already be achieved with present logging).  A bit like a "relational 
logging system":-)


> Any better config formats?

I think those are fine - as long as they are comprehensible and clear.

Cheers, Mauro




-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com