Logging conventions [closed]

问题:

What conventions do you use for log categories in log4j or similar libraries ? Usually you see class names as categories, but have you used other systems ?

What about log levels ? What levels do you use and in which case ?

Update: as some of you replied, there is no 'right' answer. I'm just looking for what different conventions people use as a possible source of inspiration.

回答1:

I have 3 levels: errors, warnings and verbose log telling whatever the program is doing at a time.

I use class+function as a context.

回答2:

I agree with Vaibhav's answer: you have to know why you are logging.

• for debug internal technical debug informations, log4j or any other library is fine (provided their usage does not artificially augment the cyclomatic complexity of the functions)
• for transversal punctual logging (across the whole code), some Aspect-Oriented approach is better suited
• for monitoring, you enter to an whole other level of logging, namely the KPI, with the need to record those information through a publication bus (like TIBCO for instance) to some kind of database.

So for internal logging only, we follow a pretty standard approach:

• severe for any error that may compromise the program
• info for following the internal progression
• fine for some sub-step details

The granularity (for classical internal logging) is the main class, the one in charge of the main steps of the process.

回答3:

We have had extensive debates about this over the years and the only thing we all agree on is that there is no perfect answer!

What we have settled on is using a top level category name to differentiate between broad categories: e.g. 'Operation' relates to anything the user might care about, 'Internal' relates to things only the developer will care about, 'Audit' is used for tracking interesting events.

Beyond that we try to limit the number of categories, since we find no-one ever turns them on/off at the more detailed level. So instead of class names we try to group them into the functional area, eg. Query, Updates, etc.

回答4:

The logging depends on your requirement. If you are making a log which simply keeps tabs on whether there have been any problems (such as logging exceptions), then you may only require Class and Function name.

However, if you have a functional requirement for creating and audit trail of sorts, then the logging has to be taken to a whole different level of detail.

回答5:

We have debug logs which are class + method.

We also have specific logs for certain actions, e.g., connection received on a socket. These are what I call 'Fact Logs' or 'Audit Trail Logs', they log a single type of thing. Of course recently I just stick these into a database because the facts you are capturing can be quite a lot more complex than a string of text, they can include state at a particular time. I.e., you roll your own audit trail recording mechanism for each audit you require.

When debugging we will set the package/class we are debugging to DEBUG in log4j, whilst leaving the rootlogger at ERROR, and we will have a debugging log file for that which hopefully leaves out all the gumpf logging from other areas of the application.

But there isn't really a 'right way' to do these things. A combination of mechanisms seems good but it depends on what you want to log.