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

Windows

[dawnread]

Event log. Standard place to find all logs.

Re:My favorite logging app...

[zero_offset]

Too many posts hit +4. Decrease the number of moderators.

I hate going off-topic, but we all know /. discourages "meta-discussion" (e.g. discussion about slash itself). Anyway, I'd say a better solution would be to expand the moderation cap. Instead of topping out at +5, let the range run from +20 to -20, for example. I find a few of the -1 posts amusing or interesting -- after all I don't always agree with the mods. Really worthless GNAA crap or whatever will disappear down a deep dark hole (no pun intended), and it'll give the users a much broader range for evaluating the "worth" of up-modded posts. This is particularly worthwhile now that Karma is not a numeric quantity and is basically something nobody has good reason to care much about any more.

Just some rambling thoughts.