Hi All,
I'm wondering what kind of information should be logged to a file once an application has moved into a Production environment? Besides the logging of exceptions and errors...
Should the start and end of each method be logged? The start and end of a running service? Each time the application saves data to a database or calls an external service? I'm trying to find the balance between logging/tracing everything and only logging errors.
I like to use different levels. The least detailed shows startup and shutdown of service as well as errors and exceptions. The most detailed could go as far as showing the value of every local variable, function entry/exit and so on.
The more detail you can get easily, the less digging and the less likely you are to have to jump on a plane to go where the problem is . . . .
K
It really depends upon you, there are no hard & fast rules.
Couple of months back we were working on this Java application and used log4j for logging, in log4j we were able to define in code our logs as either debug, warning, error, info etc.
Our debug logging was almost on every functions start & end, every successful not successful transaction was logged as "info", "error" in exceptions were logged & likewise.
Once we moved the application in the production environment after a month or so we switched of all debug logging through .properties files without restarting the application & we were good to go.
In a production environment I have logging set to "INFO" by default (using log4net), and at this level I log sufficient information to have a very good chance of diagnosing any errors. So what is "sufficient" information? Well, that all depends on your system. In our system I log the entry and exit points from the most important methods, including their input parameters and return values (unless this is a lot of data). I'm willing to accept an 5-10% overhead for logging (but you should measure this).
My perferred format is like this:
Method entry:
->MyMethod(1, "arg1")
Method exit:
<-MyMethod(1, "arg1") = true
The arrows mean I can easily see whether this is entry or exit. By including the arguments and return value I get the most critical data for diagnosing errors. I only ever have one return point from my methods, so I do not have to worry about multiple exit points for my logging.
By logging method entry/exit I find I do not have to log much else--if your code is properly decomposed into methods then this will document the execution flow through your application.
Do not make the mistake of not logging enough info because you are worried about the performance hit--measure this so you are happy with the overhead, but are confident that you are logging enough to diagnose faults purely based on the info that is in the log. What you do not what to have to do is switch the logging on to more detail after your customer has reported a fault, and then hope the fault occurs again.
I also use a DEBUG logging level which logs practically everything. This is only used in dev/test, or perhaps in production but only after consultation with the customer.