On Fri, Jan 7, 2011 at 5:08 PM, Laurent Guyon <[email protected]>wrote:
> Le vendredi 07 janvier 2011 à 12:41 +0100, nap a écrit : > > > > > > On Fri, Jan 7, 2011 at 11:49 AM, Laurent Guyon > > <[email protected]> wrote: > > Le vendredi 07 janvier 2011 à 11:33 +0100, Hartmut Goebel a > > écrit : > > > Am 06.01.2011 09:52, schrieb nap: > > > > Yep, the broker way is cool for getting a common log file, > > but in the > > > > begining, got local logs to see what is bad in the > > > > configuration/architecture can be useful. I think I'll add > > a > > > > "local_log" parameter in the etc/*d.ini files with void > > default value. > > > > So if the user want local log, he just need to enable it > > (so you see > > > > why a log module don't load for example ;) ). > > > IMHO this yet another config variable is a bad idea. The > > standard > > > logging module already delivers all we need. > > > > > > The current remote logging will become a logging handler, > > logging can be > > > configured in the daemons config file. Easy to understand > > for everybody. > > > Local and remote logging can be switched on and of as > > desired, > > > log-levels can be configured per handler. Logs can be > > filtered, etc. And > > > all this is for free :-) > > > > > > The remote handler may be build on top of the current remote > > logging > > > facility. Or can be enhanced to not format the message by it > > self, but > > > pass it on the toe remote side to be filtered there. > > > > > > My idea is to switch to *completely* the standard logging > > module. No > > > more print-statements anywhere. Everything is going via > > logging. > > > > > > +1, the best and smarter way to go imho ;) > > 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. > > > > 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. If it > > solve one yes, it's available in every python since years, so it can > > be a good replacement. But it won't solve the ini local_log thing. > > There are 2 differents problems. > > > > In fact, "all we need is logs" (lalala la la ^^), whatever the solution > used ;) > :) > > For me, the need of local logs is not only for debugging purposes, but > for logging normal working messages (some check result have been > processed, some notification have been sent, error reporting...). Imho, > every daemon needs a local log, because it's imposible to rely only on > remote logs ;) > > I think it's a admin choice. Local is good at the begining, but when all is smooth, have a common place to parse all data can be a great thing. Let give the user the choice :) Jean > Laurent > > > > > > ------------------------------------------------------------------------------ > 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/shinken-devel >
------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/shinken-devel
