Hello, I'm running into an issue where we're fairly certain that we're dropping log messages somewhere along this path: device -> network -> VMware -> RHEL host -> syslog-ng 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: syslog-ng 3.2.5 Installer-Version: 3.2.5 Revision: ssh+git://bazsi@git.balabit //var/scm/git/syslog-ng/syslog-ng-ose--mainline--3.2#master#9d4bea28198bd731df1a61e980a2af5b88d81116 Compile-Date: Jan 15 2012 19:47:30 Enable-Threads: on Enable-Debug: off Enable-GProf: off Enable-Memtrace: off Enable-Sun-STREAMS: off Enable-IPv6: on Enable-Spoof-Source: on Enable-TCP-Wrapper: on Enable-SSL: off Enable-SQL: on Enable-Linux-Caps: off Enable-Pcre: on Enable-Pacct: off options { flush_lines (100); time_reopen (2); log_iw_size(100); log_fifo_size (65536); log_msg_size(8192); long_hostnames (off); use_dns(yes); use_fqdn(yes); keep_hostname (no); stats_freq(3600); stats_level(1); dns_cache(yes); keep_timestamp(no); }; When I looked at "syslog-ng-ctl stats" I see these "types" dropped processed stamp stored However I only see "dropped" counters for tcp destinations, and not for any of the sources or local destinations. 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? 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%... 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? Any help appreciated... Cheers, Jesse -- Jesse Bowling