[ovs-dev] [PATCH 1/2] vlog: abstract out interface to syslog daemon

Ansis Atteka aatteka at nicira.com
Wed Jun 17 17:28:09 UTC 2015


On Wed, Jun 17, 2015 at 7:51 AM, Ben Pfaff <blp at nicira.com> wrote:
> On Wed, Jun 17, 2015 at 12:53:53AM -0700, Ansis Atteka wrote:
>> This patch helps to address two issues on Ubuntu 15.04 (and most likely
>> other Linux distributions) when rsyslog daemon is configured to relay
>> log messages from OVS to a remote log collector:
>>
>> 1. libc syslog() function adds unwanted prefix to every message before
>>    sending it over /dev/log Unix domain socket; and
>>
>> 2. rsyslogd daemon that comes with Ubuntu 15.04 is too old and
>>    does not allow to specify custom syslog message parsers when
>>    it received message over Unix domain socket.
>>
>> Solution to those two issues would be to use --syslog-method=udp:127.0.0.1:514
>> argument when starting OVS.
>>
>> Signed-Off-By: Ansis Atteka <aatteka at nicira.com>
>
> It seems like syslog_libc_create() and syslog_direct_create() might more
> usefully return a pointer to the inner syslogger structure, so that the
> caller does not have to blindly cast.
Ok, I can do that.

>
> We've previously had a request to make it possible to turn off local
> syslogging, only syslogging to the --syslog-target address.  This could
> now be done easily by adding a "none" --syslog-method that just throws
> away log messages.

I am not sure If I conveyed purpose of this patch clearly.

1) I actually thought to mark "--syslog-target address:port" flag as
deprecated, because now one can achieve similar result with
"--syslog-method udp:address:port".

2) I don't think that --syslog-target argument originally was
introduced with the idea so that one would be able to log to remote
syslog destinations. Instead it workarounds libc and rsyslogd
limitations that are present on distributions like Ubuntu when one
wants to use different logging format. For example, 1) current libc
syslog() call adds fixed prefix to every message; and 2) current
rsyslogd daemons do not allow to specify custom message parsers if
message was received over UNIX domain socket. However, this rsyslogd
limitation does not apply to messages that rsyslogd received over UDP
socket.

3) --syslog-target flag really does not solve remote logging problem because:
3.1) it requires ovs-* daemon to be restarted whenever log collector's
IP address changes
3.2) I don't see syslog message encryption being implemented in OVS to
provide security for remote logging
3.3) if administrator would want to forward all syslog messages to a
remote log collector he would have to update each individual daemon
3.3) Solution to 3.1), 3.2) and 3.3) is to configure rsyslogd daemon
running on the same host as syslog relay and let the syslog clients to
log to /dev/log or 127.0.0.1:514. I think that this is how admins
actually would configure syslog.

4) --syslog-target is a hack too because it uses hardcoded syslog
message format.

>
> The existing send_to_syslog_fd() has a fallback to handle messages that
> are too long to send.  I guess that's a real corner case that would only
> come up for messages longer than about 64 kB, but it might still be
> worth including in syslog_direct_log().

If I am reading [http://tools.ietf.org/html/rfc5424#section-6.1]
correctly then the maximum syslog message length is limited by
underlying transport protocol. In other words, for example, if one
VLOG_INFO(long_message) invocation would lead to two UDP datagrams,
then I don't see how syslog server would know how to stitch them
together into a single logical syslog message.

Also the write() in a loop approach for --syslog-target would not be
thread safe if one day we would decide to use TCP for syslog. The
while loop should be nested inside a lock.

>
> While we're at it, is it possible to also use the new syslog
> infrastructure for --syslog-target?  I guess that the syntax would be
> compatible, if we assumed that anything that started with a digit was a
> UDP target.

Do you think it makes sense to maintain both - -syslog-method and
--syslog-target at the same time? Can we just deprecate
--syslog-target?



More information about the dev mailing list