On Sat, Jan 18, 2014 at 10:18:49AM +0100, Rainer Gerhards wrote:
> On Fri, Jan 17, 2014 at 10:51 PM, Vladimir Marek
> <[email protected]>wrote:
>
> > > It's actually _very_ common for things to send malformed messages,
> > missing
> > > the PRI, missing the timestamp, missing the hostname, or all of the
> > above.
> > >
> > > Rsyslog has a series of heuristics to try and do the 'right' thing when
> > it
> > > gets such messages, but it's guessing, and it's guesses are not always
> > > right.
> >
> > Ah, ok, that is new area for me. Are there any other heuristic apart
> > from "beginning by 'z'"? I guess that messages starting with 'z' will be
> > quite frequent on Solaris, because of 'zfs' and 'zpool'...
> >
>
> I need to correct David a little bit here, but only in the specific case of
> per-message compression. This is a rsyslog-specific *protocol* extension,
> and it is well defined: as I said, valid syslog messages must start with
> "<" as first character in the header. We utilize this to signify compressed
> messages (at the transport layer!). If per-message compression is enabled,
> and if there is gain in compression, a "z" is inserted before the actual
> message, followed by the compressed message itself. The receiver can always
> correctly detect this, as valid messages need to start with "<" and so "z"
> always means this is a compressed message - or a totally malformed one (I
> have *never* seen messages without the <PRI> part in practice, no matter
> how malformed they were otherwise).
I see.
> What you get looks like only the MSG part of the message (note: this is NOT
> the message as whole -- see RFCs!) WITHOUT any headers. That will cause
> problems with almost all syslog implementations (maybe minor ones, like
> being put into incorrect bins or being totally ignored).
You are right.
> I guess the root cause of the problem you experience is an invalid template
> that's applied somewhere within the relay chain.
Actually, it seems that this is rather just how syslog messages look on
Solaris.
Looking into solaris syslogd source, the messages generally are either
in the form of
Jan 20 17:00:23 root: [ID 702911 user.error] My message
or without date just
zfs: [ID 249136 kern.info] imported version 35 pool pool usi
So the proper way forward would be to write custom parser, right? Other
option would be to enhance the imsolaris module/plugin to enhance the
messages to make them parseable by the standard RFC* parsers. What do
you think?
Thank you
--
Vlad
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of
sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE
THAT.
