Logging best practices, do they exist?

[marcopas]

I was wondering if there are any "logging best practices"? I am interested in what i need to take into account when when writing log-code, so what do you actually log inside you applications?

For example the loglevels, I tend to only use
log.debug
log.info
log.warn
log.error

As far as to what data i log, i still have not found a good guideline, so i am wondering what others user? Example in this case could be that the 'params' object is always dumped to the log?
Any hints and tips on logging are highly appreciated.

- Marco
---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Adam Evans]

It's a tough one.

Any data you log needs to tell you something useful, it's a obvious answer but actually figuring out what will be useful is a tough one.

If you log an exception for example don't just put in the log message a exception has happened, that won't help you track down the problem it'll just tell you their was a problem which you'll probably already know. Try to put in more info which will help you find out what was done when the exception happened.

For exceptions I pass the exception to the logger to get the stacktrace so can see where it was thrown ie:

try {
  ...
} catch (ParseException ex){
  log.info "User ${username} entered a invalid date format [${value}] on ${page} ...".toString(), ex
}

[Kimble]

Log4j's JavaDoc gives a few hints on what the various levels are meant for.
http://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/Level.html

[Jean Barmash 1]

I have adopted a bit of a convention that I add to most of my domain classes a method toDebugString(), which has a few key pieces information to identify that object in the log messages.  Typically this is type of object (i.e. human-readable and compressed), id, maybe name.

For example, I deal with Utility Accounts, so my UtilityAccount domain object has a toDebugString() method that prints "(UA[G] #333)" - Utility Account, Gas, Id 333.  This provides both contextual meaning in the log messages, and ability to find the domain object in case it's an issue that is specific to this object. 

Cheers,

Jean

On Thu, Jan 13, 2011 at 2:16 PM, Kimble <[hidden email]> wrote:

Log4j's JavaDoc gives a few hints on what the various levels are meant for.
http://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/Level.html

-----
 - Kim
Have a nice day!
--
View this message in context: http://grails.1312388.n4.nabble.com/Logging-best-practices-do-they-exist-tp3216096p3216467.html

Sent from the Grails - user mailing list archive at Nabble.com.

---------------------------------------------------------------------

To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email

[Erik Pragt]

>
> try {
>  ...
> } catch (ParseException ex){
>  log.info "User ${username} entered a invalid date format [${value}] on
> ${page} ...".toString(), ex
> }

Interesting example regarding the username. This is not how I would do it, but I would use a MDC for that, which is explained nicely in this blog: http://veerasundar.com/blog/2009/11/log4j-mdc-mapped-diagnostic-context-example-code/

We use that for our application, since we have around 1500 users, who, together, produce quite a bit of logging. To distinguish between those users, we changed the log pattern to always include the username, but you could use it for much more information

Erik

> --
> View this message in context: http://grails.1312388.n4.nabble.com/Logging-best-practices-do-they-exist-tp3216096p3216172.html
> Sent from the Grails - user mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Sébastien Blanc]

Well Erik, 

your answer has apparently activated Burt's curiosity  ;-) He just published a blog post about it :

http://burtbeckwith.com/blog/?p=521

I really love this ultra reactive grails community !

Have a nice weekend,

Seb

  

On Fri, Jan 14, 2011 at 4:46 PM, Erik Pragt <[hidden email]> wrote:

>
> try {
>  ...
> } catch (ParseException ex){
>  log.info "User ${username} entered a invalid date format [${value}] on
> ${page} ...".toString(), ex
> }

Interesting example regarding the username. This is not how I would do it, but I would use a MDC for that, which is explained nicely in this blog: http://veerasundar.com/blog/2009/11/log4j-mdc-mapped-diagnostic-context-example-code/

We use that for our application, since we have around 1500 users, who, together, produce quite a bit of logging. To distinguish between those users, we changed the log pattern to always include the username, but you could use it for much more information

Erik

> --
> View this message in context: http://grails.1312388.n4.nabble.com/Logging-best-practices-do-they-exist-tp3216096p3216172.html
> Sent from the Grails - user mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email