best way to handle multi-line kernel messages

best way to handle multi-line kernel messages

[david]

a query was made on the rsyslog mailing list about the possibility of 
rsyslog handling kernel messages better. Currently each line of logs is a 
separate log entry (and as log entries traverse networks there are thigns 
taht can cause them to get re-ordered). It would be nice to be able to 
combine multi-line logs into one log entry.

The problem is figuring out how to tell when one log entry finishes and 
the next starts.

>From examining logs it looks like follow-up lines are frequently (but not 
always) indented with some form of whitespace (this indentation taking 
place after the timestamp if that's enabled)

but this is not consistantly the case.

I suspect that there is not currently any good way for something to really 
tell when one log entry has finished and another is starting, but I wanted 
to ask here if there is anything that I should be able to rely on (with 
the thought that fixing log messages that don't work that way coudl be 
somethign for -janitors or newbes to work on)

or is this a completely hopeless task that people receiving logs should 
not even try to do?

David Lang

Re: best way to handle multi-line kernel messages

[Joe Perches]

On Wed, 2011-07-13 at 17:30 -0700, david@lang.hm wrote:
> a query was made on the rsyslog mailing list about the possibility of 
> rsyslog handling kernel messages better. Currently each line of logs is a 
> separate log entry (and as log entries traverse networks there are thigns 
> taht can cause them to get re-ordered). It would be nice to be able to 
> combine multi-line logs into one log entry.
> 
> The problem is figuring out how to tell when one log entry finishes and 
> the next starts.
> 
> >From examining logs it looks like follow-up lines are frequently (but not 
> always) indented with some form of whitespace (this indentation taking 
> place after the timestamp if that's enabled)
> but this is not consistantly the case.

No, not at all.  Most follow-on lines are pr_cont.

> I suspect that there is not currently any good way for something to really 
> tell when one log entry has finished and another is starting,

There isn't.

> but I wanted 
> to ask here if there is anything that I should be able to rely on (with 
> the thought that fixing log messages that don't work that way coudl be 
> somethign for -janitors or newbes to work on)

you'll have to implement something like:

pr_start(&cookie);
pr_multi_<level>(cookie, fmt, ...);
pr_multi_cont(cookie, fmt, ...);
pr_end(cookie);

> or is this a completely hopeless task that people receiving logs should 
> not even try to do?

There really aren't _that_ many places where
multiple calls to printk/pr_level are made.