while my opinion might not be so relevant, i think that too many levels of logging make the decision to assign a particular event to a precise log level too discretional and possibly smoky and confusing particulary when you need to add code later and the perception of what level apply to an event can be slightly changed.

By other hand it always depends on the nature of the application: I think, about logging, you must think about the consumer of information to decide correctly. Normally there are just two consumers: the user and the programmer. Again normally the programmer want to be aware of user problems, but is not always true: infact you can have, let's say, a huge file upload application where you want/must tell between user_error and client_error and server_error as you can have another application where you want a supervisor_info distinct from a general info level.

In most complex situations you can have some consumers of information that overlap so you have granulary defined log levels that group togheter under some circumstance: $usrlog = qw(ERROR USER_INFO); $supervisorlog = (SUPER_INFO USER_ERROR) and so on..

In such cases is better to have the possibility of manually include a log level into another. Generally DEBUG implies all other levels: you may prefere something different in some circumstance. You can build up the list of levels with the rule that if only one level is specified for, let say, user it contains all the lower ones but if you specify more of them this will be the final list: so you can have $usr_log = qw(INFO); is the same of $usr_log = qw(INFO WARN ERR FATAL); but $dev_log = qw(DEBUG ERROR FATAL DB_ERROR DB_WARN DB_FATAL); that does not contains INFO nor WARN

But in the majority of the case there are only the programmer and the user; if so i'd choose something simpler (as i'v done in my little log experiment):

FATAL  user and dev must be aware that the application cannot continue
+: a fundamental resource cannot be reached, authentication failure fo
+r the main application, another instance of a singleton is running...
+ 

ERROR any error that does not fall in the fatal ones: user login error
+s, needed but not necessary files cannot be written or read. This lev
+el mixes user's errors and application ones as generally both consume
+rs are interested in them

WARNING unexpected behaviours that are not strictly errors as choosing
+ a destination folder that does not exists, a destination files that 
+already exists. user's warnings generally let the user to rerun some 
+action. application warnings are autorecoverable errors like database
+ connectivity impossible with the first DB but a second attempt will 
+be made 

INFO any positive feedback from the application to the end user   

DEBUG  any positive feedback from the application to the programmer: t
+he file was open, the DB is available, the datastructure taken will b
+e dumped..
[download]

L*