Re: [Shinken-devel] Standard daemons logs

[nap <nap...@gm...>]

On Sat, Jan 8, 2011 at 7:14 PM, Hartmut Goebel
<h.g...@go...>wrote:

> Am 07.01.2011 12:41, schrieb nap:
> > I don't the he logging point. The main thing/problem here is "what if
> > the daemon is not initialized" ? Logging/print/what ever don't change
> > anything here. Use the logging module, or a simple print don't change
> > anything that the user need:
> > *global log -> brok module because all logs are broks in daemons
> > *local logs for "debuging" purpose, only and if only the user want it.
> > He want to debug a offline daemon too. And the only place where we can
> > put this log place is in the ini file.
> This point is: When using the standard logging module, the choice is
> given into the admins hands. He can decide what to log locally and what
> to send remotely. This can easily be changes in the config file. He can
> even decide to add another logging destination, e.g. syslog or  NT event
> log. Or (with some additional programming) add sophisticated filters to
> decide what to send to which logging stream.
>
Yes, but we need to give this to the admins in a easy way. This mean some
configuration capabilities for the configuration module. If it's too hard to
be used, they just won't use it.


>
> All of this is already implemented in the std. logging module. There is
> no need to reinvent the weel and there is no need to decided within the
> shinken code what should be logged where and when. *Everything* is send
> to the std. logging module and the configuration routes the message to
> where it belongs.
>
> If you are new to the standard logging module, please have a look at
> <http://docs.python.org/library/logging.html#configuring-logging> and
> look for the  logging.conf example. This example defines
> > After, a print or a logging I don't care. Print is good for what we
> > are doing, I do not see what problem the loggin will solve here.
> The main point for logging is: You get both local an remote logging for
> free. Plus filtering on levels. Plus add additional logging
> destinations. Plus ...
>
Not really. The local logging is not a logger/print problem. Logging is a
way to how write, not "what write". But if the logger module help us on
theses 2 sides, make the code more maintenable and solve user problem (what
to users want for logging after all? Isn't it the first question we should
answer before know how to code it?) yes, it's a must have.




> > replacement. But it won't solve the ini local_log thing. There are 2
> > differents problems.
> It does :-) Because on call call log to several logging destinations.
>
> The default config would simply contain two log targets: one remote
> (using the current mechanism for sending logs to the broker) and one
> local (rotating log file, errors and warnings). If some admin wants more
> local logging, he simply changes the config file.
>
No. There still 2 differents problems. Distributed modules should be
configured on the arbiter configuration, while local log is for the local
daemon (so not only the broker, but scheduler, pollers and reactionners
too). Remerber that we have 2 kinds for configuration : the global one, and
N local ones, for each daemon. The local one must be as small as possible,
and the global should manage all "architecture" part.

But of course logger can be users for the 2 problems. But let separate them,
they are not related, it's 2 differents problems, they don't solve the same
things for the users.

I'll add a simple log for the daemons, and if you want start to work on a
logging module. Start with a "feature like" change, then add new
capabilites, and so new configuration parameters :) If it's a easy
maintenable code that give us more power, I'll be happy to commit it :)



Jean


>
> @all: Please do not full quote. Thanks!
>
> --
> Schönen Gruß - Regards
> Hartmut Goebel
> Dipl.-Informatiker (univ.), CISSP, CSSLP
>
> Goebel Consult
> Spezialist für IT-Sicherheit in komplexen Umgebungen
> http://www.goebel-consult.de
>
> Monatliche Kolumne: http://www.cissp-gefluester.de/
> Goebel Consult mit Mitglied bei http://www.7-it.de
>
>
>
>
> ------------------------------------------------------------------------------
> Gaining the trust of online customers is vital for the success of any
> company
> that requires sensitive data to be transmitted over the Web.   Learn how to
> best implement a security strategy that keeps consumers' information secure
> and instills the confidence they need to proceed with transactions.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> Shinken-devel mailing list
> Shi...@li...
> https://lists.sourceforge.net/lists/listinfo/shinken-devel
>
>