[
https://issues.apache.org/jira/browse/LOG4NET-448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14260419#comment-14260419
]
Dominik Psenner commented on LOG4NET-448:
-----------------------------------------
Hi
Without looking into the details, one would have to implement a new syslog
appender compliant to the new rfc. With respect to backwards compatibility, it
will probably have to be implemented in a fresh new class. It feels like lot of
work and it might take a long time. If you need it anytime soon, you should
start writing an appender that works for you and we might merge the outcome
into log4net core.
Cheers
> Remote syslog messages coming in as separate messages via RemoteSyslogAppender
> ------------------------------------------------------------------------------
>
> Key: LOG4NET-448
> URL: https://issues.apache.org/jira/browse/LOG4NET-448
> Project: Log4net
> Issue Type: Bug
> Reporter: Jon Mabe
>
> We use sumologic.com to manage our system and application logs. In our .net
> apps we're using log4net and RemoteSyslogAppender to send logs to sumologic
> syslog collectors.
> After upgrading log4net to include the change from LOG4NET-370 our remote
> syslog messages began to come through to sumologic as a new message for each
> line.
> Screenshot of behavior, logs at top are log4net 1.2.11, logs at bottom are
> 1.2.13 http://cl.ly/image/2z380b0J0N2B?_ga=1.215263703.1124333839.1419368556
> Upon reporting this to sumologic this was the response:
> {quote}
> That said, I do not think this is what is occurring in your case. What I
> notice from your screenshot is that there are syslog priorities tagged to
> each log line ie. <11> so it looks like Log4Net is actually sending these as
> separate messages. This would be inline with the following text within the
> Jira you noted for the Log4net.
> "The solution appears to be sending each line of the log message as a
> separate syslog packet."
> If Log4Net is actually sending each line at its own packet (due to the
> newlines) then the Collector is seeing each of these as its own message and
> will not know how to group them back together.
> {quote}
> Obviously, this is problematic for how we're logging with remotesyslog and
> sumologic.
> We discussed where the issue here might lay. And it appears there is some
> opportunity for changes in log4net's RemoteSyslogAppender:
> {quote}
> "Log4Net does not appear to be doing anything incorrect based on Syslog RFC
> 3164, which is the current Syslog RFC log4Net is following. Section 4.1.3 of
> this RFC stipulates that messages should not contain anything but visible
> characters and spaces. (ABNF vchar) Their solution to this was to send a new
> message at each line break. The other option may have been to strip the
> newlines from the messages, however I believe they probably wanted to
> maintain the breaks in some way in order to make the messages more "readable."
> Now all that said there is a more recent RFC for Syslog (RFC 5424) which
> obsoletes 3164 and as I understand it is a bit more lenient with regard to
> the allowable characters.
> Section 6.4 of this RFC states:
> "The syslog application SHOULD avoid octet values below 32 (the traditional
> US-ASCII control character range except DEL). These values are legal, but a
> syslog application MAY modify these characters upon reception. For example,
> it might change them into an escape sequence (e.g., value 0 may be changed to
> "\0"). A syslog application SHOULD NOT modify any other octet values."
> So the answer here is really "it depends." They are doing it right per the
> RFC they are following, however they should probably be following the latest
> standard.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
