OK, let me get my thinking straight. The input in question is imsolaris? Not via the network? In that case, imsolaris is probably doing wrong. Question than, however, is how do messages get the proper syslog severity with the regular solaris syslogd? imsolaris should probably do the same...
Rainer On Mon, Jan 20, 2014 at 6:29 PM, Vladimir Marek <[email protected]>wrote: > Yes, that's what I meant by "or enhance the imsolaris module/plugin to > enhance the messages". Not really well formed English sentence by me :-/ > The module mostly connects rsyslog to Solaris kernel log stream and > passes the message to normal rsyslog processing. This could be one > convenient place to enhance the messages and maybe create some > additional flags similar to NO_PRI_IN_RAW. > > I am currently deciding whether it would be better to enhance imsolaris, > or to create completely new parser for solaris messages. Any suggestion, > please? :) Ideally I would want to have the fixes pushed back to > official rsyslog source tree. > > Thank you > -- > Vlad > > > > > 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. > _______________________________________________ > 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.
