How in-depth should the logging be?

This question is more-or-less code agnostic. Provided code analysis would be helpful though.

Background: I've never got along with logging too well - probably because I've never had a need to review the non-error level logs. I comply with logging practices on work projects, but I usually don't do any logging in personal projects.

Below is an exempt from the game server module. The class is a persistent connection with the client, and is responsible for receiving (responders) and sending (commands) information from and to the client. Please only analyze the logging.

```
class CommandProtocol(AMP):

def __init__(self, factory):
self.factory = factory

def connectionMade(self):
self.uid = str(id(self))
self.factory.clients[self.uid] = self
logging.info("Client '%s' is connected.", self.uid)

#--------------------------------------------------------------------------
# responders

def queue_int(self, action, arg):
self.factory.requests.add_request(self.uid, (action, arg))
logging.debug(
"Client '%s' queued int '%s' with value '%d'.",
self.uid, action, arg)
return {}
commands.QueueInt.responder(queue_int)

def queue_str(self, action, arg):
self.factory.requests.add_request(self.uid, (action, arg))
logging.debug(
"Client '%s' queued str '%s' with value '%s'.",
self.uid, action, arg)
return {}
commands.QueueStr.responder(queue_str)

def queue_tuple_of_int(self, action, arg1, arg2):
self.factory.requests.add_request(self.uid, (action, (arg1, arg2)))
logging.debug(
"Client '%s' queued tuple of int '%s' with value '(%d, %d)'.",
self.uid, action, arg1, arg2)
return {}
commands.QueueTupleOfInt.responder(queue_tuple_of_int)

def queue_tuple_of_str(self, action, arg1, arg2):
self.factory.requests.add_request(self.uid, (action, (a

my logs will contain too much information

Think of your log as a database of logged records. You might have all logged records contain the same number of fields (client#, action, result, etc) and each event decides which fields to fill in when generating the record. Or, you might have N different record layouts (connect event record, query event record, setgui event record, etc) and each event creates the record type specific to that event.

In either case, don't worry that you might have too many records or that records contain too much info, because what you also need to create is a log viewer/filter that allows only the records and contents of interest to be displayed or dumped.

The first logging option (all records contain the same number of fields, although many may be empty) is preferable, because lots of database tools can then be used.

For example, if your logging code creates a table of SQLite records, you can use SQLite to conveniently select and report only the logged events of interest.

StackExchange Code Review Q#46419, answer score: 3