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

Michael Hu (NSBU) humichael at vmware.com
Wed Apr 22 17:59:54 UTC 2015


To reply to Ben's suggestion.

That may not work as rsyslogd will server multiple producers. Other
producers only send UDP without calling syslog(). I will look to add a new
cmd line option.

Thanks,
Michael 






On 4/22/15 8:15 AM, "Gurucharan Shetty" <shettyg at nicira.com> wrote:

>On Wed, Apr 22, 2015 at 7:45 AM, Ben Pfaff <blp at nicira.com> wrote:
>> Another suggestion I received off-list was to change the rsyslog
>> daemon's configuration to not to write its output locally.
>I think we would not have control over changing the rsyslog daemon in
>the hypervisors controlled by a sysadmin.
>
>I think a new '--no-local-syslog' command line would maintain
>backwards compatibility.
>
>
>>
>> On Tue, Apr 21, 2015 at 09:33:45PM +0000, Michael Hu (NSBU) wrote:
>>> Thanks for the suggestion, Ben.
>>>
>>> I will add a new command line option.
>>>
>>> Thanks,
>>> Michael
>>>
>>>
>>>
>>>
>>>
>>>
>>> On 4/21/15 12:30 PM, "Ben Pfaff" <blp at nicira.com> wrote:
>>>
>>> >
>>> >
>>> > What if we add a command line option that
>>> >disables logging to the local syslog, instead logging just to the
>>> >--syslog-target?
>>> >
>>> >
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> On 4/20/15 12:36 PM, "Ben Pfaff" <blp at nicira.com> wrote:
>>> >>
>>> >> >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://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_
>>>>>>>htm
>>> >>>>l_
>>> >>
>>> 
>>>>>>>rfc5424&d=AwIBAg&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=Cj4
>>>>>>>PPu
>>> >>>>e3
>>> >>
>>> 
>>>>>>>W0GyOLVXTqBSOj3Puq_bWcXnUDF91V-EpLY&m=E4Qw3lzvS7sJs2pgUWAt9pCqJQUwTQ
>>>>>>>lVI
>>> >>>>Wk
>>> >> >>C-5aHETs&s=JrIt7nB_vZmH6vT9LaU_ADT6BI24jLbee2wFAXucW2w&e=
>>> >> >> > 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.
>>> >>
>>>




More information about the dev mailing list