Consider:

• Logging Do's and Dont's
• The Dark Art of Logging
• Everything you ever needed to know about logging (okay, this one was a comment on the other two being published, but it's funny)

The advice is funny in a "holy crap do people need this, you made me cry" kind of way. Really?

People need to be told to log exception stack traces?

People need to be told to parameterize logging statements? Although this one is funny, because it uses SLF4J, and SLF4J's logging formats are hilarious in a post-1.4 world. Come on.

log.info("You passed me [%s] as an argument.", argumentValue);

Trace logging with aspects is kinda funny too - for one thing, it's actually decent advice, but for another, you're TRACING. Dude. Even the log statement submission should be in an executor.

The Dark Art of Logging is funny too - it's like they're instructing people to log stuff, you know? It's stuff that once you use it at all, you look at your navel and think "Gee I really should give myself enough information to reconstruct the call." Hmm, maybe people do need these silly posts.

This is why stuff like Dynatrace exists, because people don't even think to log enough to help themselves I guess. It's a good business if you can get it.

William Louth is right, though - this stuff is modern caveman. This is why our field is so immature - people don't know how to do the basics, we tell ourselves how to do the basics all the time, and we never ever really seem to get it.

If you were creating a baseline of information that a competent programmer would have to know, what would be in that baseline? SQL, Logging, C, Java, OCaml?

Well, in all fairness, logging's not BAD.

Ideally, in my experience, it's used for triage more than anything else, and can be horribly misused; that said, with so many frameworks involved in applications now, it's certainly convenient to triage with a simple "oh turn on this log level for that package."

That's why dynatrace and jxinsight are great for production apps; they're designed to give you what logging WOULD give you, except done more properly and with far lower overhead. But the poor man's jxinsight is ... logging. 

That's just the way it is. You can say "logging is bad" or "logging is an indicator for failure" or "people who use logging are stupid" if you like, but the bottom line is that it's just a tool to get stuff done.

If I understand the article correctly, nobody is saying that "logging is bad". Just that even the basic techniques are poorly understood and misused by many programmers, and therefore we are still in the dark ages. We can't discuss more advanced techniques or tools before we understand the basics and their limitations.

In answer to Richard's question: yes, I think people still need to be told about this, because so many of us still get it wrong.

Are you really that much proud of yourself ?

Can't you imagine that newbies gets into java everyday ?

You should read about "The Design of Everyday Things", you would understand that if people are working around something, it may be a design or conception issue.

It's not because something is not obvious for somebody that it means he is a peace of crap.

If that was a response to my post, that's not what I mean at all. I certainly don't think someone is a fool because he doesn't understand the basics. However, I do know experienced programmers who don't always get logging right. I know I don't! 

The basics should always be taught. It's necessary to have articles aimed at beginners. However, experts may get annoyed if a basic technique is presented as if it was big news.

I remember it welll.being a java newbie what to buy a graphic designer

If I understand the article correctly, nobody is saying that "logging is bad".

William Louth is.  According to him, "don’t do it. 11 times out of 10 you are doing it wrong and should be using something else – events, metering, or diagnostics."

Thanks James for pointing out what I consider to be a rather obvious statement in light of how misused/abused logging is in generally which by the way is not just confined to Java newbies even the average developer over at SpringSource can't seem to apply it right judging by the number of releases which claim to address performance problems caused by logging itself. We can't seem to let this be go blaming the million or so logging libraries in existence which by the way was recently increased by one by the JBoss team. But even that is out of date by the time this message is posted. Admittedly there are all pretty much crap but maybe the failure has its origin in the approach itself. A poor approach leads to poor design leads to poor implementation leads to poor usage....

I hope to get the chance to write up a less colorful rebuttal with another interested party without the clubbing to death this subject.

Logging is the lowest common denominator for ....

William-

Are you saying that there is no place for logging?  I fully agree with logging not meeting certain needs but I still see a place for it.

For example, in my work, I may be challenged to show why a certain transaction worked (or didn't) months or even years after the fact.  What would you suggest for this and why wouldn't logging (simple to understand and easy to implement) meet my needs?

thanks,

-James

I can't recall having used logging  in production for triage.  Maybe a couple of times I've turned up the logging level of a production system.  Typically creating guidelines and adding on features for logging (above and beyond what the logging library gives you) end up over-complicating stuff and will probably not be used.  Everyone loves to write cool new loggers and appenders.  The best way to observe whether you are logging correctly, is to look at the log and ask yourself whether it makes sense, can you follow it, and would it be possible for someone else to understand what was going on at 2AM in the morning should all hell break loose.

However, for forensics, logging can be very valuable - if you cannot observe the fault that occurred when you choose, the log may be able to point you in the direction of what failed - assuming it is readable.

"That's why dynatrace and jxinsight are great for production apps; they're designed to give you what logging WOULD give you, except done more properly and with far lower overhead. But the poor man's jxinsight is ... logging."

Wouldn't logging still be required as a head's up that something has gone wrong in production, at which point you can dive in with dynatrace and jxinsight to investigate further, or would you leave those tools running all the time just in case?

One of the problems with logging stack traces is with a production system that's being used by say 1000 users. If only 1% of those hit the faulting code, then you get 10 stack traces for the same thing. If 10% hit it, then you get 100 duplicate stack traces. You only really want 1 and then log messages that just say "Oh, I hit that problem too!!". Maybe some sort of intelligent exception logging framework is required.

 

 

I don't get your point. Of course people need to be told best practices, or what you call "basics". Otherwise they waste their time (and their employer's time) in finding out the hard way.

• Never use System.out.printxx or System.err.printxx methods
• Using java.util.logging or jakarta.commons.log = ok
• Using Log4J = better
• Using SLF4J - wrapping SLF4J, JUL or JCL = even better
• BEST = Using LogBack with SLF4J support, and bridging JUL & JCL - faster, more flexible, written by same person as Log4J, http://logback.qos.ch

See blog on Logback with Maven in Spring Project: http://gordondickens.com/wordpress/2010/11/07/configuring-logback-in-roo/

Using a RollingFileAppender? Consider JDBCAppender and run OLAP analytics on top of that (Oracle/Hyperion Interactive Reporting or similar).

Will give you an edge in this stone age ;)

I'm curious if anybody tried to use replaysolutions.com log amplification feature? 

Thanks!

its ok if it does not affect the system itself

stork club movie

I remember it welll.being a java newbie what to buy a graphic designer