logging-log4net-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dominik Psenner (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LOG4NET-448) Remote syslog messages coming in as separate messages via RemoteSyslogAppender
Date Mon, 29 Dec 2014 20:34:13 GMT

    [ 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)

Mime
View raw message