What to register / track in a production environment

Question

I am wondering what information should be written to the file after the application has moved to the production environment? Besides logging exceptions and errors ...

Should the beginning and end of each method be recorded? The beginning and end of a running service? Every time an application saves data to a database or calls an external service? I try to find a balance between logging / tracing everything and only registration errors.

Answer 1

It really is up to you, there are no hard and fast rules.

A few months ago we worked on this Java application and used log4j for logging, in log4j we were able to define our logs in the code as debugs, warnings, errors, information, etc.

Our debug log was on almost all the beginnings and ends of every successful transaction registered as “information”, an “error” in exceptions was recorded and similarly.

As soon as we moved the application to the production environment after a month or so, we turned off debugging logging via .properties files without restarting the application, and we were good to go.

Answer 2

In the production environment, by default I register the value "INFO" (using log4net), and at this level I record enough information to have a very good chance of diagnosing any errors. So what is “sufficient” information? Well, it all depends on your system. In our system, I register the entry and exit points of the most important methods, including their input parameters and return values ​​(if this is not so much data). I am ready to accept 5-10% of the overhead for registration (but you have to measure it).

My perferred format is as follows:

Method input:

-> MyMethod (1, "arg1")

Method Output:

<-MyMethod (1, "arg1") = true

The arrows mean that I can easily see if this is an input or an output. Including arguments and return value, I get the most important data for diagnosing errors. I have only one return point from my methods, so I don’t have to worry about multiple exit points for my logging.

When I entered / exited the registration method, I found that I did not need to register much more - if your code is correctly decomposed into methods, then it will document the execution flow through your application.

Do not make mistakes so you don’t register enough information because you are worried about efficiency - measure it so that you are happy with the overhead, but you are sure that you are registered enough to diagnose errors based solely on information in the journal. What you do not need to do is to include the registration in more details after your client reports an error and then hopes that the error reappears.

I also use the DEBUG logging level, which logs almost everything. This is used only in dev / test or, possibly, in production, but only after consulting with the client.

Answer 3

I like to use different levels. The least verbose indicates startup and shutdown, as well as errors and exceptions. You can get to the most detail by showing the value of each local variable, entering / turning off a function, etc.

The more details you can easily get, the less you dig and, less likely, you have to jump on an airplane, to go where the problem is.,.

TO