[Dancer-users] Logging and "info"

[David Morel]

On 27 Mar 2012, at 22:17, Ovid wrote:
> ----- Original Message -----
>
>> From: Alexis Sukrieh <sukria at 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