Tricky but what the hell here goes -- I would advise raising your helicopter view a mile or so. The challenge, especially if you are providing a solution to the whole world via CPAN, tends in the context to be to design a cohesive logging system for diverse components written in different sources (fail that and your efforts are relatively futile) e.g. perl, c, bash, SQL, (update plus system and http logs) that meets at least the following criteria:

Logging has the same format especially timestamp for all components in the system.

Originating source of each line of logging can be easily determined from the line of logging.

Logged info must be designed to assist support engineers as well as developers (best achieved by separate or concatenated logging for each audience type

The difference between the line of logging and further information and/or guilty data needs to be clear from the logging syntax you choose.

and whatever else other monks might notice (it is also getting late for me).

I would also advise using a namespace that is less mistakable with the mathematical concept of log, i.e. use Logging instead of log. My first thought was that your module had something to do with logs to base 4 which I suggest is not so stupid given that logs to base 8 are important in devORops - a profession I recently accidentally adopted which might well be on the up.

upd+ ok you can get away with some diversity and nonconformity but you cannot ignore what the overall objective of logging is (support/maintenace of an application system) to the extent you seem to have done so in the narrowness of your scope.

upd+ if you do design it for more general use, you'd want to make a callable API of it and have your Perl module also call that.