Logging isn't for when things go right, it's for when things go wrong.
But you don't know when things go wrong until it already happened,
so log everything, all the time, and rotate often.
In one family of programs we have two levels of logging: Error and Debug. However, I find that in production it's never useful to turn off debug-logging, because that level of detail is actually useful when an error strikes.
In my programs I usually have three levels of logging: Info, Error, Fatal Error, and Debug. The admin is notified of Fatal Errors. The other logs provide more information.
I've been thinking of a "smart" error logging facility; you log debug and error-messages as usual, but the smart error logging will keep track of the n most recent debug messages at all times. When an actual error is logged, the recent debug lines are also written to the error log, providing the context that lead to the error. The subsequent n debug messages will also be written to the error log, providing details of what happened as a result of the error (if anything).
We logged each user "gesture" (entered "foo" in the bar field, clicked OK, etc.), which gave us a trail of breadcrumbs to follow to repeat the failure, though in practice we rarely had to look back more than a dozen entries from the end of the log. Usually things jumped right out.
The biggest mistake I see people make when they approach logging is to over engineer it early, rather than starting with something simple that works, and letting experience guide enhancements.
If does not currently incorporate the type of contextual logging which you seek, but would form an excellent base from which to build an alternate logging platform.
