views:

244

answers:

2

When using log4perl, the debug log layout that I'm using is :

log4perl.appender.D10.layout=PatternLayout
log4perl.appender.D10.layout.ConversionPattern=%d [pid=%P] %p %F{1} (%L) %M %m%n
log4perl.appender.D10.Filter = DebugAndUp

This produces very verbose debug logs, for example:

2008/11/26 11:57:28 [pid=25485] DEBUG SomeModule.pm (331) functions::SomeModule::Test Test XXX was successfull
2008/11/26 11:57:29 [pid=25485] ERROR SomeOtherUnrelatedModule.pm (99999) functions::SomeModule::AnotherTest AnotherTest YYY has faled

This works great, and provides excellent debugging data.

However, each line of the debug log contains different function names, pid length, etc. This makes each line layout differently, and makes reading debug logs much harder than it needs to be.

Is there a way in log4perl to format the line so that the debugging metadata (everything up until the actual log message) be padded at the end with spaces/tabs, and have the actual message start at the same column of text?

+5  A: 

You can pad the single fields that make up your entries. For example [pid=%5P] will always give you at least 5 characters for the PID.

The "Quantify Placeholders" section in the docs for Log::Log4perl::Layout gives more details.

innaM
+3  A: 

There are a couple of ways to go with this, although you have to figure out which one works better for your situation:

  1. Use a different appender if you are working live. Have that appender use a pattern that shows only the information you want. If you're working in a single process, for instance, your alternate appender might leave of the PID and the timestamp. You might only need the file name and line number.

  2. Use %n to put newlines in the right place. That makes it multi-line output that is slightly harder to parse later, but you can choose another sequence for the input record separator (say, a literal "[EOL]") to make it easy to read entry-by-entry.

  3. Log to a database instead of a file. For your reports, select just the columns you want to inspect.

  4. Log everything, but write a filter to go through the log file ad-hoc to display just the parts that you want to see, such as only the debugging messages, the entries between certain times, only the entries involving a file, and so on.

brian d foy