Hi Vladimir, I've never used it, but I see there already is an imsolaris module: http://www.rsyslog.com/doc/imsolaris.html
2014/1/20 Vladimir Marek <[email protected]> > 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. > _______________________________________________ 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.
