On 27 Mar 2012, at 22:17, Ovid wrote:
----- Original Message -----
From: Alexis Sukrieh <sukria@sukria.net>
I put info at level 4 under the premise that these messages should always be in the logs. I am using this branch at work and so far it works fine.
Hmm, to me "info" should be below warning. If the user does not even want to see error messages, he wont want to see "info" messages.
My two cents ;)
Everything everyone has said about lowering the info level makes sense. It just fails in my particular case :)
Specifically, I'm developing a rapid prototype of a real-time bidding system where I want to capture some information quickly. I only want to pay attention to it if there is a problem and then I'm happy to grep the logs. If the proof of concept is successful, I'll probably (not guaranteed) convert the info statements to log the data into the database. Unfortunately, that means if I move the proof of concept into production and lose the warnings, I lose the info I want, also. That's why I put the level at 4.
That being said, I'm happy to stand corrected on this. Perhaps I should create a separate logging mechanism or temporarily log *everything* in production? I was just following the "simplest thing that could possibly work" approach.
If you want to see a lot of things, (including warnings), I'd rather go the other way around: use the TRACE level. This is what I usually use at work, when I want to send most of what a script does to some logging mechanism, by configuration or when running it on the command line. You can adjust your log4perl configuration to send the level's output to a different destination than what gets the 'warning and above' messages, which is typically some file in /var/log/. Your destination for TRACE could be a different file, a specific facility you configure through a log4perl Syslog appender (say , local7 for instance), or anything you choose. This way you don't pollute the 'normal' logs and still get all the output where you chose to have it. And when you don't need it anymore, you can simply turn it off by changing your configuration, and switching some constant or a BEGIN time variable (yuk, I know) so the Log4perl calls for that level are not even compiled. Also, Log4perl's flexibility is such that you could very well: - use a different category (or 'logger') only for those messages by having the specific logging that you want done in 1 proxy class only, and have the general/normal configuration ignore it. you would then have 2 destinations for your logging. Have a look at: http://xrl.us/bmzmsc - use a filter on the logged statements to decide their destination at runtime (see Log::Log4perl::Filter) - any other crazy idea that Log4perl allows (there are a few). This is just another way of saying Log4perl's documentation is a goldmine. Ask if you need more precise config examples, but this should get you started ok (or at least start a discussion, since I'm far from a Log4perl expert, really) David Morel