Jon Mabe created LOG4NET-448:
--------------------------------
Summary: 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)
