> >>>> I'm having trouble making multiline messages survive when > >> forwardning them > >>>> to a remote rsyslog host (both client and server running rsyslog > >> 5.8.10). > >>>> > >>>> I am using imfile and $InputFileReadMode 2 (for understandig > >> indented > >>>> multiline logs) to read tomcat catalina logs which contains lots > of > >>>> indented multiline java stacktraces and it works just fine when > >> pushing > >>>> them to local syslog but at the remote host every line has a date > >> stamp. Is > >>>> there any way to make this work? > >>> > >>> what needs to happen is for the imfile module to escape the lf and > >> replace it > >>> with #015 (following the standard rsyslog escape logic). This > should > >> be a > >>> pretty trivial modification to the source to do this. I'll look at > >> throwing > >>> together a patch soon if someone else doesn't do it first. > >> > >> I think this trivial patch will do the job. > >> > >> In the cases where a newline was left in the message before, it now > >> truncates > >> the pending message by one character and then adds the string "#015" > to > >> the > >> message in it's place. > >> > >> note that I have not tested this yet, and I won't get a chance to > for a > >> while > >> (possibly not even today) > > > > David, > > > > this sounds pretty useful, but I am a bit hesitant to apply it as is. > > Shouldn't there be config options to turn this on or off? I can see > that some > > folks really want to have the LF instead of the escape... > > I would like to see more control around the escaping of characters (tab > escaping > comes to mind
Yeah, I have noted that. A good solution is probably to have a "doEscape" lookup table, where for each char value there is a boolen switch to whether or not escape (we could limit this to the 33 US-ASCII control chars). Each of the to be set separately. A probable step even further (and with performance-implication) would be the detection of UTF-8 sequences, as the very same byte values must not be escaped in a multibyte sequence. > > Given our current limitations on escaping characters, it wouldn't hurt > to > condition these based on the $EscapeControlCharactersOnReceive option > (which > defaults to on) > > given that in both of these cases, we are pulling the LF off of the > string to > add in the new characters, wrapping these five lines with an if() > should be > enough. Sounds fair. I'll have a look to add this, but will work a bit more in the queue today (at least I got some free time fort hat, so... ;)) Rainer > David Lang > _______________________________________________ > 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.
