Handling large message load
This section provides tips on optimizing the performance of syslog-ng. Optimizing the performance is important for syslog-ng hosts that handle large traffic.
-
Disable DNS resolution, or resolve hostnames locally. For details, see Using name resolution in syslog-ng.
-
Enable flow-control for the TCP sources. For details, see Managing incoming and outgoing messages with flow-control.
-
Do not use the usertty() destination driver. Under heavy load, the users are not be able to read the messages from the console, and it slows down syslog-ng.
-
Do not use regular expressions in our filters. Evaluating general regular expressions puts a high load on the CPU. Use simple filter functions and logical operators instead. For details, see Regular expressions.
-
Caution: When receiving messages using the UDP protocol, increase the size of the UDP receive buffer on the receiver host (that is, the syslog-ng OSE server or relay receiving the messages). Note that on certain platforms, for example, on Red Hat Enterprise Linux 5, even low message load (~200 messages per second) can result in message loss, unless the so-rcvbuf() option of the source is increased. In such cases, you will need to increase the net.core.rmem_max parameter of the host (for example, to 1024000), but do not modify net.core.rmem_default parameter.
As a general rule, increase the so-rcvbuf() so that the buffer size in kilobytes is higher than the rate of incoming messages per second. For example, to receive 2000 messages per second, set the so-rcvbuf() at least to 2 097 152 bytes.
-
Increase the value of the flush-lines() parameter. Increasing flush-lines() from 0 to 100 can increase the performance of syslog-ng OSE by 100%.
Using name resolution in syslog-ng
The syslog-ng application can resolve the hostnames of the clients and include them in the log messages. However, the performance of syslog-ng is severely degraded if the domain name server is unaccessible or slow. Therefore, it is not recommended to resolve hostnames in syslog-ng. If you must use name resolution from syslog-ng, consider the following:
-
Use DNS caching. Verify that the DNS cache is large enough to store all important hostnames. (By default, the syslog-ng DNS cache stores 1007 entries.)
options { dns-cache-size(2000); }; -
If the IP addresses of the clients change only rarely, set the expiry of the DNS cache large.
options { dns-cache-expire(87600); }; -
If possible, resolve the hostnames locally. For details, see Resolving hostnames locally.
|
|
NOTE:
Domain name resolution is important mainly in relay and server mode. |
Resolving hostnames locally
Purpose:
Resolving hostnames locally enables you to display hostnames in the log files for frequently used hosts, without having to rely on a DNS server. The known IP address \xe2\x80\x93 hostname pairs are stored locally in a file. In the log messages, syslog-ng will replace the IP addresses of known hosts with their hostnames. To configure local name resolution, complete the following steps:
Steps:
-
Add the hostnames and the respective IP addresses to the file used for local name resolution. On Linux and UNIX systems, this is the /etc/hosts file. Consult the documentation of your operating system for details.
-
Instruct syslog-ng to resolve hostnames locally. Set the use-dns() option of syslog-ng to persist_only.
-
Set the dns-cache-hosts() option to point to the file storing the hostnames.
options { use-dns(persist_only); dns-cache-hosts(/etc/hosts); };
Collecting logs from chroot
Purpose:
To collect logs from a chroot using a syslog-ng client running on the host, complete the following steps:
Figure 21: Collecting logs from chroot
Steps:
-
Create a /dev directory within the chroot. The applications running in the chroot send their log messages here.
-
Create a local source in the configuration file of the syslog-ng application running outside the chroot. This source should point to the /dev/log file within the chroot (for example to the /chroot/dev/log directory).
-
Include the source in a log statement.
NOTE: You need to set up timezone information within your chroot as well. This usually means creating a symlink to /etc/localtime.