CODEWITHSUNDEEP
loggingcoding-style
Joel
Joel

Reputation: 30156

Log message style guide

I'm looking for a style guide to log messages:

For example:

i.e. what makes a good / bad log message string

I'm particularly interested in what make a good log string - beyond including the TIME, SEVERITY and COMPONENT, as I tend to use log4j which gives me this information for free.

Upvotes: 11

Views: 7708

Answers (6)

IndustryUser1942
IndustryUser1942

Reputation: 1246

Not a guide, but for me most important points:

Guiding principals:

  • make it unambiguous
  • make it easy to grep

More concrete things:

  • Include timezone or log at GMT+0
  • Include context data (e.g. UserId if it is relevant to message like "User Login Failed")
  • Separate constant and dynamic part of log message ("user {userId} comment {comment id} missing", "user comment missing. U={userId} C={comment id}". One of them lends it self easier to grep; alternatively assigning unique log-msg-id, also would work towards same purpose)
  • There should be no doubt, which code line logged some particular message.
  • There is no need for proper English sentences. (somebody will be having wall of text on the screen, no need to make it more verbous than needed)

Upvotes: 0

Cody Myers
Cody Myers

Reputation: 321

The 10 Commandments of Logging is the perfect introduction into the world of logging.

This website will teach you the do's & dont's of creating your own log files.

Upvotes: 5

Frédéric Hamidi
Frédéric Hamidi

Reputation: 262939

On the convention side, for a few years I've been formatting my logs as:

severity timestamp source message

With severity being symbols for:

(-) Info
(!) Warning
(*) Error

E.g.:

(-) 2010-10-13T18:53:42 foo: Starting up...
(!) 2010-10-13T18:54:11 foo: bar: Unable to lock file "quux", will try again in 4 seconds.
(-) 2010-10-13T18:56:13 foo: Loading plugin "baz"...
(*) 2010-10-13T18:57:39 foo: baz: Error 0xbaadbeef during RPC.
(-) 2010-10-13T18:58:04 foo: Shutting down...

I found out it's easier to glance-search for specific message classes (all errors, all warnings), especially while browsing the logs using a pager in a terminal.

Upvotes: 1

Joseph Weissman
Joseph Weissman

Reputation: 5717

Effective logging is an art, but there are a few major items that can help:

  • Thread ID: Enterprise applications are often executed in a multithreaded environment. With thread ID information, you can distinguish one request from another.

  • Caller identity: The identity (or principal) of the caller is also an important piece of information. Because different users have different privileges, their execution paths could be very different. Putting the user's identity in the log messages can be a great help for a security-aware application.

  • Timestamp: Generally, users can only approximate the time at which a problem occurred. Without a timestamp, it's difficult for the support personnel to identify the problem.

  • Source code information: This includes class name, method name, and line number.

(These tips taken from this IBM article on Java logging.)

Upvotes: 1

liorda
liorda

Reputation: 1572

That really depends on your application. I may draw inspiration from anything at /var/log/*

Upvotes: 1

Michael Goldshteyn
Michael Goldshteyn

Reputation: 74370

Whatever you decide, if it's a text log, start each line with a good timestamp in, preferably, ISO format:

YYYY-MM-DDTHH:MM:SS.mmm

In all likelihood, you will want to follow the timestamp with a severity code.

Some good logging guidelines can be found here:

http://watchitlater.com/blog/2009/12/logging-guidelines/

and here

http://download.oracle.com/docs/cd/B32110_01/web.1013/b28952/logging.htm

Upvotes: 2

Related Questions