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.
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.
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.
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.
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.
I agree with Vaibhav's answer: you have to know why you are logging.
So for internal logging only, we follow a pretty standard approach:
The granularity (for classical internal logging) is the main class, the one in charge of the main steps of the process.