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 ;) ------------------------------------------------------------------------------ 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 Shinken-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shinken-devel
