Hi all, I noticed that when I'm trying to log information, I have several log levels (core() apparently reserved for the core, as one might expect): * debug * warning * error I have a case where I would like to log informational data that is neither a warning or error. However, I don't want to log it as debug because I still want this logged in production. I propose adding an "info" log level that has a log level of 4 and thus should always be logged if logging is enabled. It would behave like other log levels: info "All bid requests were denied for auction $auction_id"; Does this make sense or am I missing something obvious? Here are the log levels from Log::Log4perl (http://search.cpan.org/~mschilli/Log-Log4perl-1.36/lib/Log/Log4perl.pm#Log_L...) $logger->trace("..."); # Log a trace message $logger->debug("..."); # Log a debug message $logger->info("..."); # Log a info message $logger->warn("..."); # Log a warn message $logger->error("..."); # Log a error message $logger->fatal("..."); # Log a fatal message Cheers, Ovid -- Live and work overseas - http://overseas-exile.blogspot.com/ Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog - http://blogs.perl.org/users/ovid/ Twitter - http://twitter.com/OvidPerl/
Hi, I agree with that, info sounds good. We don't want to have too many levels, to be able to stay simple, but info seems to be missing indeed On 27 March 2012 13:05, Ovid <curtis_ovid_poe@yahoo.com> wrote:
Hi all,
I noticed that when I'm trying to log information, I have several log levels (core() apparently reserved for the core, as one might expect):
* debug * warning * error
I have a case where I would like to log informational data that is neither a warning or error. However, I don't want to log it as debug because I still want this logged in production.
I propose adding an "info" log level that has a log level of 4 and thus should always be logged if logging is enabled. It would behave like other log levels:
info "All bid requests were denied for auction $auction_id";
Does this make sense or am I missing something obvious?
Here are the log levels from Log::Log4perl ( http://search.cpan.org/~mschilli/Log-Log4perl-1.36/lib/Log/Log4perl.pm#Log_L... )
$logger->trace("..."); # Log a trace message $logger->debug("..."); # Log a debug message $logger->info("..."); # Log a info message $logger->warn("..."); # Log a warn message $logger->error("..."); # Log a error message $logger->fatal("..."); # Log a fatal message
Cheers, Ovid -- Live and work overseas - http://overseas-exile.blogspot.com/ Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog - http://blogs.perl.org/users/ovid/ Twitter - http://twitter.com/OvidPerl/
_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
Agreed. On Tue, Mar 27, 2012 at 2:38 PM, damien krotkine <dkrotkine@gmail.com>wrote:
Hi,
I agree with that, info sounds good. We don't want to have too many levels, to be able to stay simple, but info seems to be missing indeed
On 27 March 2012 13:05, Ovid <curtis_ovid_poe@yahoo.com> wrote:
Hi all,
I noticed that when I'm trying to log information, I have several log levels (core() apparently reserved for the core, as one might expect):
* debug * warning * error
I have a case where I would like to log informational data that is neither a warning or error. However, I don't want to log it as debug because I still want this logged in production.
I propose adding an "info" log level that has a log level of 4 and thus should always be logged if logging is enabled. It would behave like other log levels:
info "All bid requests were denied for auction $auction_id";
Does this make sense or am I missing something obvious?
Here are the log levels from Log::Log4perl ( http://search.cpan.org/~mschilli/Log-Log4perl-1.36/lib/Log/Log4perl.pm#Log_L... )
$logger->trace("..."); # Log a trace message $logger->debug("..."); # Log a debug message $logger->info("..."); # Log a info message $logger->warn("..."); # Log a warn message $logger->error("..."); # Log a error message $logger->fatal("..."); # Log a fatal message
Cheers, Ovid -- Live and work overseas - http://overseas-exile.blogspot.com/ Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog - http://blogs.perl.org/users/ovid/ Twitter - http://twitter.com/OvidPerl/
_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
Pull request submitted: https://github.com/sukria/Dancer/pull/765 The only open question is this bit in Dancer::Logger::Abstract: my $levels = { # levels < 0 are for core only core => -10, # levels > 0 are for end-users only debug => 1, warn => 2, warning => 2, error => 3, info => 4, }; 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. Full docs and tests included. Also, in Dancer.pm, the list of FUNCTIONS (https://metacpan.org/module/Dancer#FUNCTIONS) is huge and could stand to have some organization. For example, the debug, warning, error and info log functions could stand to be grouped under a "Logging Functions" label. I did not bother to do this because if some are grouped, everything should be grouped and I don't yet know Dancer well enough to know all of of the logical groupings. Plus, I have a day job :) Cheers, Ovid -- Live and work overseas - http://overseas-exile.blogspot.com/ Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog - http://blogs.perl.org/users/ovid/ Twitter - http://twitter.com/OvidPerl/
________________________________ From: sawyer x <xsawyerx@gmail.com> To: Cc: Perl Dancer <dancer-users@perldancer.org> Sent: Tuesday, 27 March 2012, 14:39 Subject: Re: [Dancer-users] Logging and "info"
Agreed.
On Tue, Mar 27, 2012 at 2:38 PM, damien krotkine <dkrotkine@gmail.com> wrote:
Hi,
I agree with that, info sounds good. We don't want to have too many levels, to be able to stay simple, but info seems to be missing indeed
On 27 March 2012 13:05, Ovid <curtis_ovid_poe@yahoo.com> wrote:
Hi all,
I noticed that when I'm trying to log information, I have several log levels (core() apparently reserved for the core, as one might expect):
* debug * warning * error I have a case where I would like to log informational data that is neither a warning or error. However, I don't want to log it as debug because I still want this logged in production.
I propose adding an "info" log level that has a log level of 4 and thus should always be logged if logging is enabled. It would behave like other log levels:
info "All bid requests were denied for auction $auction_id";
Does this make sense or am I missing something obvious?
Here are the log levels from Log::Log4perl (http://search.cpan.org/~mschilli/Log-Log4perl-1.36/lib/Log/Log4perl.pm#Log_L...)
$logger->trace("..."); # Log a trace message $logger->debug("..."); # Log a debug message $logger->info("..."); # Log a info message $logger->warn("..."); # Log a warn message $logger->error("..."); # Log a error message $logger->fatal("..."); # Log a fatal message
Cheers, Ovid -- Live and work overseas - http://overseas-exile.blogspot.com/ Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog - http://blogs.perl.org/users/ovid/ Twitter - http://twitter.com/OvidPerl/ _______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
On Tue, Mar 27, 2012 at 4:37 PM, Ovid <curtis_ovid_poe@yahoo.com> wrote:
Pull request submitted: https://github.com/sukria/Dancer/pull/765
The only open question is this bit in Dancer::Logger::Abstract:
my $levels = {
# levels < 0 are for core only core => -10,
# levels > 0 are for end-users only debug => 1, warn => 2, warning => 2, error => 3, info => 4, };
The meaning of "info" in Log::Log4perl is something between a debug message and a warning, so it should have weight 1.5 in the table above (if it makes sense, of course). I'm not telling that this is the way to go, just that a well established module in the Perl ecosystem assigns a different semantic to the info log level and this might lead to confusion. Just to do some blatant self-promotion, if you need additional log levels you can take a look at Dancer::Logger::Log4perl and use e.g. Log::Log4perl's methods provided with the :easy mode of operation (i.e. TRACE/DEBUG/INFO/WARN/ERROR/FATAL/ALWAYS, the last being probably what you mean by "info"). Regards, Flavio.
I agree with Flavio : imho, INFO should not be at weight 4, but between debug and warn. On 27 March 2012 21:31, Flavio Poletti <polettix@gmail.com> wrote:
On Tue, Mar 27, 2012 at 4:37 PM, Ovid <curtis_ovid_poe@yahoo.com> wrote:
Pull request submitted: https://github.com/sukria/Dancer/pull/765
The only open question is this bit in Dancer::Logger::Abstract:
my $levels = {
# levels < 0 are for core only core => -10,
# levels > 0 are for end-users only debug => 1, warn => 2, warning => 2, error => 3, info => 4, };
The meaning of "info" in Log::Log4perl is something between a debug message and a warning, so it should have weight 1.5 in the table above (if it makes sense, of course). I'm not telling that this is the way to go, just that a well established module in the Perl ecosystem assigns a different semantic to the info log level and this might lead to confusion.
Just to do some blatant self-promotion, if you need additional log levels you can take a look at Dancer::Logger::Log4perl and use e.g. Log::Log4perl's methods provided with the :easy mode of operation (i.e. TRACE/DEBUG/INFO/WARN/ERROR/FATAL/ALWAYS, the last being probably what you mean by "info").
Regards,
Flavio.
_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
My reading of this thread leans toward what I think was Ovid's intent -- "debug", "warn", "warning", and "error" proclaim something about the application, the code. While "info" is intended for the business logic, the function that the application is performing. On Mar 27, 2012, at 2:36 PM, damien krotkine wrote:
I agree with Flavio : imho, INFO should not be at weight 4, but between debug and warn.
On 27 March 2012 21:31, Flavio Poletti <polettix@gmail.com> wrote:
On Tue, Mar 27, 2012 at 4:37 PM, Ovid <curtis_ovid_poe@yahoo.com> wrote:
Pull request submitted: https://github.com/sukria/Dancer/pull/765
The only open question is this bit in Dancer::Logger::Abstract:
my $levels = {
# levels < 0 are for core only core => -10,
# levels > 0 are for end-users only debug => 1, warn => 2, warning => 2, error => 3, info => 4, };
The meaning of "info" in Log::Log4perl is something between a debug message and a warning, so it should have weight 1.5 in the table above (if it makes sense, of course). I'm not telling that this is the way to go, just that a well established module in the Perl ecosystem assigns a different semantic to the info log level and this might lead to confusion.
Just to do some blatant self-promotion, if you need additional log levels you can take a look at Dancer::Logger::Log4perl and use e.g. Log::Log4perl's methods provided with the :easy mode of operation (i.e. TRACE/DEBUG/INFO/WARN/ERROR/FATAL/ALWAYS, the last being probably what you mean by "info").
Regards,
Flavio.
Thanks Curtis for the PR. Le 27 mars 2012 16:37, Ovid <curtis_ovid_poe@yahoo.com> a écrit :
The only open question is this bit in Dancer::Logger::Abstract:
my $levels = {
# levels < 0 are for core only core => -10,
# levels > 0 are for end-users only debug => 1, warn => 2, warning => 2, error => 3, info => 4, };
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 ;)
----- 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. Cheers, Ovid -- Live and work overseas - http://overseas-exile.blogspot.com/ Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog - http://blogs.perl.org/users/ovid/ Twitter - http://twitter.com/OvidPerl/
Le 27 mars 2012 22:17, Ovid <curtis_ovid_poe@yahoo.com> a écrit :
Everything everyone has said about lowering the info level makes sense. It just fails in my particular case :)
Hmm, I think you have the answer here: if it's correct in the geneic case but not in the particular case you're facing, then the patch may be wrong for Dancer's internal logger. Maybe what you want to do is something else than "logging messages to the core logger at the info level". That being said, adding an "info" level to the logger (between debug and warning) makes perfect sense.
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.
Personnaly I would have used debug for that, or warning (or the newborn info level). I don't see why it's a problem, but maybe I miss something. Also, for my apps, I never disable warnings or errors on production, I clearly want to see them if there is any, so why not having the info stuff? I think I'm missing something :) Regards,
----- Original Message -----
From: Alexis Sukrieh <sukria@sukria.net>
That being said, adding an "info" level to the logger (between debug and warning) makes perfect sense.
OK, I'll update the patch tomorrow.
Also, for my apps, I never disable warnings or errors on production, I clearly want to see them if there is any, so why not having the info stuff? I think I'm missing something :)
Fair enough. I don't like to disable them on production either, but I've had a lot of pushback about that on some jobs. Cheers, Ovid -- Live and work overseas - http://overseas-exile.blogspot.com/ Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog - http://blogs.perl.org/users/ovid/ Twitter - http://twitter.com/OvidPerl/
----- Original Message -----
From: Alexis Sukrieh <sukria@sukria.net>
Personnaly I would have used debug for that, or warning (or the newborn info level). I don't see why it's a problem, but maybe I miss something.
I have updated the pull request. I have *not* updated the POD yet because I want to make sure people are happy with it before I change the docs again :) Once everyone is comfortable with it, I'll finish it up. As for why I would prefer info separate from warning: I hate to overload the semantics of something. It keeps biting developers repeatedly, even when it seems like a safe thing to do (I have a long explanation of one facet of this at http://blogs.perl.org/users/ovid/2010/02/exceptions-as-flow-control.html) In this case, if I'm grepping the logs for warnings, I don't want a bug of info statements showing up, and vice versa :) Cheers, Ovid -- Live and work overseas - http://overseas-exile.blogspot.com/ Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog - http://blogs.perl.org/users/ovid/ Twitter - http://twitter.com/OvidPerl/
On 28 March 2012 09:51, Ovid <curtis_ovid_poe@yahoo.com> wrote:
As for why I would prefer info separate from warning: I hate to overload the semantics of something. It keeps biting developers repeatedly, even when it seems like a safe thing to do (I have a long explanation of one facet of this at http://blogs.perl.org/users/ovid/2010/02/exceptions-as-flow-control.html)
So, I think you'll be interested by the fact that we implemented continuations in Dancer, using exceptions. I tried to do it properly , by monkey-patching Try::Tiny and have two seperate exceptions families : Dancer::Exception for when things go wrong, and Dancer::Continuation that are meant to be used only internally, to break flow control. I decided to not use Upper::Stack and co, to stick ith simple technology. But maybe I should revisit it. Let me know what you think of the code :) https://github.com/sukria/Dancer/blob/devel/lib/Dancer/Exception.pm
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
On Tue, 27 Mar 2012 13:17:56 -0700 (PDT) Ovid <curtis_ovid_poe@yahoo.com> wrote:
Everything everyone has said about lowering the info level makes sense. It just fails in my particular case :)
I'd agree with the other comments regarding the priority of the 'info' level.
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.
Perhaps we should tweak the 'log' setting to allow either a specified log level to be provided, meaning "anything at or above this level" as it currently does, *or* the ability to provide a list of specific levels - so you could say, e.g.: log: - info - error That could be more flexible, and would probably suit your use-case, no?
On Tue, Mar 27, 2012 at 1:05 PM, Ovid <curtis_ovid_poe@yahoo.com> wrote:
Hi all,
I noticed that when I'm trying to log information, I have several log levels (core() apparently reserved for the core, as one might expect):
* debug * warning * error
In a "spot the outsider" (don't know if it's clear in English!) game, "core" would win hands off. While debug/warning/error speak about the severity of the message, core talks about who's generating the message and not about its importance (probably the assumption is that all messages from core have the same importance, of course). (BTW, in module Dancer::Logger::Log4perl I mapped core messages to the INFO level; I noticed that they tend to be emitted more or less with the same logic. Should they be promoted to some ANY level? Probably - I'd like some feedback about it.) I think that the introduction of an "info" logging facility would be an improvement, hope to see it soon. Cheers, Flavio.
participants (8)
-
Alexis Sukrieh -
damien krotkine -
David Morel -
David Precious -
Flavio Poletti -
Ovid -
Puneet Kishor -
sawyer x