<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
If it is a network issue (typically with load on the receiving side)
you can try<br>
netstat -su<br>
<br>
It can't let you know if a packet (udp) did not make it to the host,
but it can show things that the kernel identifies that caused the
packet to not make it to the application.<br>
<br>
Might help a little<br>
<br>
Jim<br>
<br>
<br>
<div class="moz-cite-prefix">On 03/07/2014 01:25 AM, Balazs
Scheidler wrote:<br>
</div>
<blockquote
cite="mid:CAKcfE+ZeW7eGQJzKXTi--L1yvFWk4kxLxJvjqWNV4K=Hc+__yw@mail.gmail.com"
type="cite">
<p dir="ltr"><br>
On Feb 28, 2014 10:59 PM, "Jesse Bowling" <<a
moz-do-not-send="true" href="mailto:jessebowling@gmail.com">jessebowling@gmail.com</a>>
wrote:<br>
><br>
> Hello,<br>
><br>
> I'm running into an issue where we're fairly certain that
we're dropping log messages somewhere along this path:<br>
><br>
> device -> network -> VMware -> RHEL host ->
syslog-ng<br>
><br>
> What I'd like to understand better is what statistics I can
gather from syslog-ng itself to help show or rule out drops in
the software. I'm using the following general config:<br>
><br>
> syslog-ng 3.2.5<br>
> Installer-Version: 3.2.5<br>
> Revision:
<a class="moz-txt-link-abbreviated" href="mailto:ssh+git://bazsi@git.balabit//var/scm/git/syslog-ng/syslog-ng-ose--mainline--3.2#master#9d4bea28198bd731df1a61e980a2af5b88d81116">ssh+git://bazsi@git.balabit//var/scm/git/syslog-ng/syslog-ng-ose--mainline--3.2#master#9d4bea28198bd731df1a61e980a2af5b88d81116</a><br>
> Compile-Date: Jan 15 2012 19:47:30<br>
> Enable-Threads: on<br>
> Enable-Debug: off<br>
> Enable-GProf: off<br>
> Enable-Memtrace: off<br>
> Enable-Sun-STREAMS: off<br>
> Enable-IPv6: on<br>
> Enable-Spoof-Source: on<br>
> Enable-TCP-Wrapper: on<br>
> Enable-SSL: off<br>
> Enable-SQL: on<br>
> Enable-Linux-Caps: off<br>
> Enable-Pcre: on<br>
> Enable-Pacct: off<br>
><br>
> options {<br>
> flush_lines (100);<br>
> time_reopen (2);<br>
> log_iw_size(100);<br>
> log_fifo_size (65536);<br>
> log_msg_size(8192);<br>
> long_hostnames (off);<br>
> use_dns(yes);<br>
> use_fqdn(yes);<br>
> keep_hostname (no);<br>
> stats_freq(3600);<br>
> stats_level(1);<br>
> dns_cache(yes);<br>
> keep_timestamp(no);<br>
> };<br>
><br>
> When I looked at "syslog-ng-ctl stats" I see these "types"<br>
><br>
> dropped<br>
> processed<br>
> stamp<br>
> stored<br>
><br>
> However I only see "dropped" counters for tcp destinations,
and not for any of the sources or local destinations. <br>
</p>
<p dir="ltr">Dropped is defined for destinations only. Sources
never drop messages.</p>
<p dir="ltr">What do you mean on 'local destinations'?</p>
<p dir="ltr">What happens is that sources dispatch incoming
messages to all configured destinations. Destinations keep a
queue of messages that are being sent.</p>
<p dir="ltr">If the destination queue is full, new messages get
dropped, but this should only happen if the destination is
slower and flow control is not enabled on the specific path.</p>
<p dir="ltr">You can increase the queue size with the
log-fifo-size option.</p>
<p dir="ltr">You can enable flow control using flags(flow-control)
within the log statement.</p>
<p dir="ltr">> Does "dropped" only make sense in the remote
destination case? Is there anything I can turn on/examine to
tune my syslog-ng performance and verify whether I have drops
occurring within syslog-ng?<br>
><br>
> For the RHEL host portion I've tried watching netstat -su
and netstat -st but the error counters for those do not seem to
indicate that the level of issue we're seeing lies there. The
processor for syslog-ng is busy, but averages 75%...<br>
><br>
> Is it foolish to expect VMware to keep up with the level of
logs we're taking in? Might virtualization be hiding drops from
me?</p>
<p dir="ltr">It depends on how much logs you have.</p>
<p dir="ltr">UDP is a tricky beast with a number of drop points
both within and outside syslog-ng.</p>
<p dir="ltr">Syslog-ng is able to process hundreds of thousands of
messages in some use cases. With udp the biggest issue is
dropping packets in the kernel receive queue, but you can scale
that to 20-30k msg per second.</p>
<p dir="ltr">><br>
> Any help appreciated...<br>
><br>
> Cheers,<br>
><br>
> Jesse<br>
><br>
> -- <br>
> Jesse Bowling<br>
><br>
><br>
>
______________________________________________________________________________<br>
> Member info: <a moz-do-not-send="true"
href="https://lists.balabit.hu/mailman/listinfo/syslog-ng">https://lists.balabit.hu/mailman/listinfo/syslog-ng</a><br>
> Documentation: <a moz-do-not-send="true"
href="http://www.balabit.com/support/documentation/?product=syslog-ng">http://www.balabit.com/support/documentation/?product=syslog-ng</a><br>
> FAQ: <a moz-do-not-send="true"
href="http://www.balabit.com/wiki/syslog-ng-faq">http://www.balabit.com/wiki/syslog-ng-faq</a><br>
><br>
><br>
</p>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">______________________________________________________________________________
Member info: <a class="moz-txt-link-freetext" href="https://lists.balabit.hu/mailman/listinfo/syslog-ng">https://lists.balabit.hu/mailman/listinfo/syslog-ng</a>
Documentation: <a class="moz-txt-link-freetext" href="http://www.balabit.com/support/documentation/?product=syslog-ng">http://www.balabit.com/support/documentation/?product=syslog-ng</a>
FAQ: <a class="moz-txt-link-freetext" href="http://www.balabit.com/wiki/syslog-ng-faq">http://www.balabit.com/wiki/syslog-ng-faq</a>
</pre>
</blockquote>
<br>
</body>
</html>