How Should an Application's Logs Work?

emmjayell writes "You've been there, loaded up a new application (think server-based app like Apache or Samba ...), it's working okay for a few days or a few months, then the intermittent problems start. Usually it's the CEO or someone else of relative importance that is the first victim. You can't readily duplicate the problem, so you go to find out where the application put's it's logs - maybe it's in var/log/messages - maybe in it's own directory - sometimes it's right there and available in some administrative GUI. So what makes you happiest when diagnosing the problem? Do you want tools to access it? UI or command line? Do you want it formatted to use tools like cut and sed? Do you have any examples of an app that does a great job with system logging and diag logging? Background: My team is working on an application that is gearing up for a first release. We have a logging framework in place already (we are using Apache: logging.apache.org/) -- so that covers how we are logging, but not what we should log and how it should be laid out for optimal use."

Comments

loggin and microsoft

[Velex]

Any kid of log is fine with me as long as it's there and it gives me some kind of insight into what's going wrong, e.g. "can't open this file," "that file's corrupt," "null pointer." Of course, text files are nice, because you can actually search through them.

Sadly, most applications for M$ operating systems usually just leave things like, "Error #543892157893421 occured." When you go to look up what error 84901257893423 is, no one in the world seems to have had it. Tech support proceeds to blame your hardware vendor, who blames your software vendor, ad nauseum. Seems like most applications for m$ operating systems just pull error numbers out of their asses.

Re:loggin and microsoft

[Nyarly]

Sometimes I fastasize abotu getting the SW field tech and HW field tech at the same time, and locking them both in a dis-used closet with the box until it works. Probably, I'd open the closet months later to find two stinking corpses and the server whirring with quiet malevolence.

To paraphrase, utopia cannot begin until the last SW field tech is strangled with the entrails of the last HW field tech.

Re:It's a log

[Anonymous Coward]

Write to a god damned text file. Add a timestamp. Be verbose. Is it really that hard to figure out?

You've been there, sitting at a console peering at your application's newly created text log file after a crash. The question, naturally, turns to editors. Should you open it with vi? Maybe emacs? Is nano the tool you're looking for?

What editor makes you happiest when viewing log files? Do you enjoy navigating with intuitive kay combinations? Does syntax highlighting make your day? Do you have any examples of an editor that does a great job with system log files? Background: My team is new to the command-line, but we're gearing up for this brave new experience.

Re:tyvm

[Kalgash]

You're welcome. And thanks for the posted BONUS. The /. may not reflect it but you and I both know it's there.