How to handle logs, points, markers and best practices!

1. Logs

2. Objective
• all activities that affect user state or
balances are formally trackedAuditable
• it’s possible to determine where an
activity occurs in all tiers of the
application
Traceable
• logs cannot be overwritten or tampered
with by local or remote users
High
integrity

3. Message Priorities/Levels
• Severe errors that cause premature termination.fatal
• Other runtime errors or unexpected conditions.error
• are undesirable or unexpected, but not necessarily
"wrong".Warn
• Interesting runtime events (startup/shutdown).Info
• detailed information on the flow through the system.Debug
• more detailed information.Trace

4. What to log?
Log all the things
Work Smarter, not Harder

5. Default Message Priority/Level
By default the message priority
should be no lower than info.
That is, by default debug message
should not be seen in the logs.

6. Default production log level
WARNING

7. Where to define logger layout?
• private static Logger log = Logger.getLogger(
MyClass.class )
– log.error()
– log.warn()
– log.info()
– log.debug()
• "%r [%t] %-5p %c - %m%n"
– 176 [main] INFO org.foo.Bar - Located nearest gas
station.

8. What format to use?
• A SINGLE LINE
• Timestamps with timezone, to the
millisecond or nanosecond
• Class name + line number
• Meaningful context

9. Best practices for app
• Do not allow exceptions to go
unhandled/reach the browser
• Display custom error pages to users with an
email link for feedback
• Do not enable “Robust Exception Information”
in production.
• Rotate log files to keep them current

10. Use parameterized logging
• LOG.debug("Method called with arg " + arg);
• BAD: string varies with argument

11. Use parameterized logging
• if (LOG.isDebugEnabled()) {
LOG.debug("Method called with arg {}", arg);
• BAD: code clutter

12. Use parameterized logging
• LOG.debug("arg is {}", arg);
• BAD: wrong level of language, this would be
okay on TRACE

13. Use parameterized logging
• LOG.debug("Method called with arg {}", arg);
• GOOD: string literal, no dynamic objects

14. Exception example
• catch (SomeException ex) { LOG.warn("Failed
to do something with {}, continuing", arg, ex);
}
• GOOD: note how there is no "{}" for ex

15. Provide useful event context
• LOG.debug(arg.toString());
• VERY BAD:
– no context provided
– non-constant message string
– assumes useful toString()

16. Provide useful event context
• LOG.debug("{}", arg);
• VERY BAD
– no context provided

17. Provide useful event context
• try { doSomething(arg); ... }
catch (SomeException ex) { }
• COMPLETELY BAD
– silently ignoring errors!!!

18. Provide useful event context
• try { doSomething(arg);}
catch (SomeException ex) {
LOG.warn(ex.getMessage()); }
• EXTREMELY BAD
– message is not constant
– no context is provided
– ex.getCause() is lost
– call stack is lost

19. Provide useful event context
• try { doSomething(arg); ... }
catch (SomeException ex) {
LOG.warn("Failed to do something with {},
ignoring it", arg, ex); }
• GOOD
– string literal
– we explain what we tried to do
– we pass along information we have about the failure
– we explain that we recovered from the failure

20. Provide useful event context
• try { doSomething(arg); ... }
catch (SomeException ex) { LOG.error("Failed to do
something with {}", arg, ex);
throw new RuntimeException("Failed to do
something", ex); }
• GOOD
– string literal
– we explain what we tried to do
– we pass along information we have about the failure
– we escalate the failure to our caller
– we also 'chain' the exception so it is not lost and can be
correlated

21. Anything else?
• Separate files for different areas of interest
• Always Log To Local Disk

22. • http://juliusdavies.ca/logging.html