[ovs-dev] [PATCH] vlog.c: Avoid duplicating log message in rsyslog if enabling syslog-target

[Ben Pfaff]

After speaking to the author of the current code, it works as it does
because of a concern that the connection to the remote syslog might be
unreliable, that the remote data is harder to get at, and that it's
harder to see it in the context of other messages logged on the local
system, so that the redundancy has some value.  Michael, do any of
these arguments apply to what you're working on?

On Wed, Apr 15, 2015 at 09:17:24AM -0700, Ben Pfaff wrote:
> Presumably there is a use case for sending to both local syslogd and to
> a remote UDP server.  It is probably even a VMware use case, because
> this feature was added by Henry Mai (then a VMware employee), who didn't
> often contribute to OVS.  I guess that he would not have designed it to
> send to both targets, and documented it to do so, if that was
> undesirable.  I would not want to break this use case.
> 
> Henry: if it's OK to ask you a question even though you've departed
> VMware, can you tell us why --syslog-target sends to both the local and
> the remote targets, instead of replacing the local target?  Thanks!
> 
> On Wed, Apr 15, 2015 at 05:17:35AM +0000, Michael Hu (NSBU) wrote:
> > Hi Ben,
> > 
> > Some logger analysis tool has some local agent listening on a single node to collect logs. One of the popular tool called log insight which uses rsyslogd as local client to listen and transferring log to log insight server.
> > 
> > Currently syslog() function does not support structured data with key/value pairs in the log header specified by RFC 5424. 
> > https://tools.ietf.org/html/rfc5424
> > Log analysis tool uses these header to categorize and filter log messages. If sending structured data as main log message, it won't be recognized by the log collector. That's why we have to send raw UDP packet directly to rsyslogd which contains both structured header and main log messages.
> > 
> > If using vlog to send udp to rsyslogd by specifying  --syslog-target=127.0.0:514, we would see duplicated messages in /var/log/syslog as vlog also calls syslog() for the same message. That is the reason for this patch.
> > 
> > BTW, since this parameter is called syslog-target, do we expect user to either specify this to send udp log message or let vlog call syslog() but not both at the same time? Is there other use case to send UDP packet and call syslog() at the same time?
> > 
> > Thanks,
> > Michael
> > 
> > ________________________________________
> > From: Ben Pfaff <blp at nicira.com>
> > Sent: Tuesday, April 14, 2015 9:11 PM
> > To: Gurucharan Shetty
> > Cc: Michael Hu; ovs-dev
> > Subject: Re: [ovs-dev] [PATCH] vlog.c: Avoid duplicating log message in rsyslog if enabling syslog-target
> > 
> > On Fri, Apr 10, 2015 at 07:30:13AM -0700, Gurucharan Shetty wrote:
> > > On Thu, Apr 9, 2015 at 8:42 PM, Michael Hu <humichael at nicira.com> wrote:
> > > > Currently if --syslog-target=127.0.0.1:514 is enabled, syslog would have
> > > > duplicated log messages. The fix will not call syslog() if already having
> > > > syslog_fd indicating message is sent through udp.
> > >
> > > You forgot to add a Signed-off-by.
> > > When I 'git am' this patch, I get:
> > > Applying: vlog.c: Avoid duplicating log message in rsyslog if enabling
> > > syslog-target
> > > fatal: corrupt patch at line 15
> > >
> > > I personally think that your patch makes sense. But the documentation
> > > (e.g. 'man ovs-vswitchd') says:
> > >
> > > --syslog-target=host:port
> > >               Send syslog messages to UDP port on host,  in  addition  to  the
> > >               system  syslog.   The host must be a numerical IP address, not a
> > >               hostname.
> > >
> > > So when this feature was added, I think it was mostly meant for a
> > > remote IP address and not local. So your patch breaks the "in
> > > addition" part of the current expectation.
> > 
> > I'd like to hear why one would pass --syslog-target=127.0.0:514 at all.
> > Why is this useful, if the system already has a working syslog()
> > facility?
> > 
> > Thanks,
> > 
> > Ben.