To help with 2+3, during our code review (individual and
formal), we make sure test cases (unit and/or integration)
are triggering support-facing log messages. That way you
can *see* the messages before going live. Silly ones like
"file not found" show up pretty quickly as being useless.
Look at your code coverage and make sure important support
issues are triggered (really...try hard to do this...it's
amazing how much error-handling code itself contains bugs).
Also developer messages show up pretty quickly when our
support team scans the log files in our pre-production
environment that by definition are running with the same
log configuration as production would for up at least 1wk
before going live. If you don't have a distinct pre-prod
environment, then at least "pretend" in another staging
environment for a few days with the proposed prod logging
configuration..have your support look at what's showing up
in the log files. Are the prod errors really support errors
that should alert some support person at 2am in the morning?
It's amazing the differences that show up between what a
developer thinks is important and what is actually important
in a 24x7 global production environment...
For large applications (or highly geo-dispersed ones), I've
also found task-based logging (as opposed to class-based)
logging to be far more useful to the support team (and
indirectly to the development team). During production, who
the heck can remember *all* the classes involved in a
particular operation...so we have categories that represent
the specific services or business functions (in addition to)
the class based typical cruft. NOTE: this is something you'll
have to review and reinforce over and over esp. if you fluid
teams.
HTH,
The Wabbit
Jason Irwin wrote:
Hi Julius,
I asked about best practice a while back, so it's good to see this come up
again as I am still trying to get and idea on what "best practice" is with
regards to logging.
I agree with avoiding multiple-lines, but there are occasions where this
simply isn't possible. These should really only be at the DEBUG level and
are probably a candidate to go into a separate log file to avoid cluttering
up the main one.
I have three other pet hates with logging
1) Log messages which only make sense with the code as a reference. These
are simply useless to the support team. e.g. "strThing populated". Really.
How very nice. What the heck is "strThing" and why should I care? A better
message may be something like "Thing set to 'x' from table 'y'". Every
developer should ask themselves "Will this message help or confuse the
support team when they see it?" Certainly for the ERROR and INFO levels.
2) Log messages which hide information. "The file could not be found."
What file? Where? Do I even know why it was being accessed? The log
message should always contain the file path (or meaningful relative path)
and the name. The same holds true to other connections don't log
"Connection refused", log "Connection to 'xyz' refused". Again, this all
about helping the support team.
3) DEBUG is for developers. Higher levels are for the support team and
(possibly) client admins. Don't forget! In my experience may developers do
and log technical stuff at these higher levels which is just confusing and
means the support team cannot do their job and have to push work back onto
engineering to decipher.
I am more than likely guilty of all 3!
Cheers,
J.
-----Original Message-----
From: Julius Davies [mailto:[EMAIL PROTECTED]
Sent: 06 June 2008 05:28
To: [email protected]
Subject: log4j best practises
Here's a page of what I consider log4j best practises:
http://juliusdavies.ca/logging.html
Any comments are very welcome!
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
