rsyslog 3.22.3 (v3-stable)
Download file name: rsyslog 3.22.3 (v3-stable)
3.22.3 (devel)
md5sum: 9bc101b7450466abc2ec4f8b0698f785
Author: Rainer Gerhards (rgerhards@adiscon.com)
Version: 3.22.3 File size: 1,32 MB
Install locations for rsyslog
Not everyone uses the same linux distributions. If Linux at all. And some distributions store files different than others. When building a test environment, we stumbled upon the problem, that if we tried the usual know method
./configure --libdir=/lib --sbindir=/sbin
rsyslog won’t work. Even if there is already rsyslog installed, but we want to use a different version, we will be helpless. Therefore we want to collect a list of different distributions and the different installation paths.
All paths are for 32-Bit operating systems!
Fedora
libdir=/lib sbindir=/sbin
Ubuntu
libdir=/lib sbindir=/usr/sbin
CentOS
libdir=/lib sbindir=/sbin
Debian
libdir=/lib sbindir=/usr/sbin
If you know of other distributions and the install directories, please send us a notification via the mailing list, so we can add it here.
How to use tcpflood for rsyslog testing?
First of all tcpflood is a testing tool of the rsyslog testbench which is able to send a lot of messages via tcp.
This tool is included in the local rsyslog folder in ‘tests’. Before you can use tcpflood you have to build it first. Just switch in the mentioned folder and type
make tcpflood
Now you can use tcpflood by using the following command
./tcpflood -"options"
as example, just insert -m10000 as “options” to send 10000 messages.
./tcpflood -m10000
Please note that tcpflood uses port 13514 by default, so you have to adjust your tcp listener in your rsyslog config (or the port of tcpflood using the option -p).
tcpflood and the testbench
Following up, we assume that tcpflood is present in the current directory but not the system search path. The tool has many command line options. Many of them have defaults, but these defaults are mostly suitable for use inside rsyslog’s testbench. For performance testing, a proper set of options must be selected. It is suggested that tcpflood, together with its option set, is kept inside a script file for easy test reproduction at later times.
The table below lists tcpflood command line options present at time of this writing. Note that tcpflood is still not a tool meant for average user consumption and thus under heavy development based solely on the needs of the rsyslog developers. We suggest that you open the tcpflood.c source code. Right at the top, there is a comment block describing the actual options available with the version you obtained.
| -t | target address (default 127.0.0.1) |
| -p | target port (default 13514) |
| -n | number of target ports (targets are in range -p..(-p+-n-1) Note -c must also be set to at LEAST the number of -n! |
| -c | number of connections (default 1) |
| -m | number of messages to send (connection is random) |
| -i | initial message number (optional) |
| -P | PRI to be used for generated messages (default is 167). Specify the plain number without leading zeros |
| -d | amount of extra data to add to message. If present, the number itself will be added as third field, and the data bytes as forth. Add -r to randomize the amount of extra data included in the range 1..(value of -d). |
| -r | randomize amount of extra data added (-d must be > 0) |
| -s | (silent) do not show progress indicator (never done on non-tty) |
| -f | support for testing dynafiles. If given, include a dynafile ID in the range 0..(f-1) as the SECOND field, shifting all field values one field to the right. Zero (default) disables this functionality. |
| -M | the message to be sent. Disables all message format options, as only that exact same message is sent. |
| -I | read specified input file, do NOT generate own test data. The test completes when eof is reached. |
| -B | The specified file (-I) is binary. No data processing is done by tcpflood. If multiple connections are specified, data is read in chunks and spread across the connections without taking any record delemiters into account. |
| -C | when input from a file is read, this file is transmitted -C times (C like cycle, running out of meaningful option switches ;)) |
| -D | randomly drop and re-establish connections. Useful for stress-testing the TCP receiver. |
| -F | USASCII value for frame delimiter (in octet-stuffing mode), default LF |
| -R | number of times the test shall be run (very useful for gathering performance data and other repetitive things). Default: 1 |
| -S | number of seconds to sleep between different runs (-R) Default: 30 |
| -X | generate sTats data records. Default: off |
| -e | encode output in CSV (not yet everywhere supported) for performance data: each inidividual line has the runtime of one test the last line has 0 in field 1, followed by numberRuns,TotalRuntime, Average,min,max |
| -T | transport to use. Currently supported: “udp”, “tcp” (default) Note: UDP supports a single target port, only |
| -W | wait time between sending batches of messages, in microseconds (Default: 0) |
| -b | number of messages within a batch (default: 100 million) |
| -Y | use multiple threads, one per connection (which means 1 if one only connection is configured!) |
| -z | private key file for TLS mode |
| -Z | cert (public key) file for TLS mode |
| -L | loglevel to use for GnuTLS troubleshooting (0-off to 10-all, 0 default) |
Installing RSyslog 5 on RHEL 4 / 5
To have rsyslog working correctly on RHEL 4 or 5, some conditions have to be met. The method described has been tested with rsyslog 5.7.1.
First of all compile and install the dependencies.
- gnutls-2.8.6.tar.bz2
- libgcrypt-1.4.6.tar.gz
- libgpg-error-1.9.tar.gz
- libtasn1-2.2.tar.gz
After that, you can install rsyslog using the following commands:
./configure PKG_CONFIG_PATH=/usr/local/lib/pkgconfig --enable-gnutls make make install
It could happen, that the install might complain about gnutls.pc. Simply comment out the URL found near the start of the file /usr/local/lib/pkgconfig/gnutls.pc.
Credit for this find goes to Forum member Johann Reinhard (johannreinhard).
rsyslog 5.6.0 (v5-stable) released
Hi all,
We have just released rsyslog 5.6.0, the new v5-stable. This release brings all changes and enhancements of the 5.5.x series to the v5-stable branch.
rsyslog 5.6.0 (v5-stable)
Download file name: rsyslog 5.6.0 (v5-stable)
5.6.0(v5-stable)
md5sum: 62c8edad559a39ca8c124ca87908075b
Author: Rainer Gerhards (rgerhards@adiscon.com)
Version: 5.6.0 File size: 2,253,026 byte
Changelog for 5.6.0 (v5-stable)
Version 5.6.0 [V5-STABLE] (rgerhards), 2010-10-19
This release brings all changes and enhancements of the 5.5.x series to the v5-stable branch.
- bugfix: a couple of problems that imfile had on some platforms, namely Ubuntu (not their fault, but occured there)
- bugfix: imfile utilizes 32 bit to track offset. Most importantly, this problem can not experienced on Fedora 64 bit OS (which has64 bit long’s!)
How to use rate limiting in rsyslog?
This article is tested with rsyslog 5.7.1 on Fedora 13. It will not work with version of rsyslog prior to 5.7.1.
In rsyslog 5.7.1 we introduced rate limiting. This is a option for the Unix Socket Input module called imuxsock. In short, this option limits the amount of messages written into logfiles by a process, if the process tries to write huge amounts of messages in a short period of time.
If you look a bit more into the details, this new feature makes a lot of sense. Because when regular logging happens, this makes no difference. But if a process goes wild (and I bet everyone has experienced this at least once) and starts to create large bulks of log messages, this affects the whole system in general. This blocks not only your I/O, but creates a large amount of logs that usually is simply not necessary and doesn’t really hold useful information. Therefore such messages are now discarded automatically. We will describe later how you can customize these settings for this.
This article is aimed for those who want to learn a bit more about how the rate limit works or who are new to this topic. Therefore we will not only describe how to set this up or change settings, but we want to show you some ways of testing, how imuxsock works and where some caveats are lying.
Please go on to the following pages.
Changing the settings
Go back to What is imuxsock?
Before we can begin testing on how rate limiting works, we should change the default settings. By default, rate limiting will only work, if a process sends more than 200 messages in 5 seconds.To have some influence on the rate limiting we have basically two options:
$SystemLogRateLimitInterval [number] $SystemLogRateLimitBurst [number]
The SystemLogRateLimitInterval determines the amount of time that is being measured for rate limiting. By default this is set to 5 seconds. The SystemLogRateLimitBurst defines the amount of messages, that have to occur in the time limit of SystemLogRateLimitInterval, to trigger rate limiting. Here, the default is 200 messages. For creating a more effective test, we will alter the default values.
To change these settings we open the rsyslog configuration. Open the configuration with vi (please note, that we use the default configuration path):
vi /etc/rsyslog.conf
Now we need to search the right spot for the entries. Find the following:
$ModLoad imuxsock.so
This entry will load the imuxsock module.
Now insert two new lines under the ModLoad command and fill them as follows:
$SystemLogRateLimitInterval 2 $SystemLogRateLimitBurst 50
These are the option for the module with some values. This means in plain words, that rate limiting will take effect if more than 50 messages occur in 2 seconds.
To make sure, that we will see all messages that are logged, we insert another entry into the configuration. Go to the section in the rsyslog.conf that holds the “Rules”. Insert a new rule that looks like this:
*.* /var/log/everything.log
You can name the file as you want. Every log message will be written into this file for our review.
Save the configuration file and exit vi. Now we need to restart rsyslog. This is necessary because it will only load the configuration once on startup.
First try to test rate limiting
Go back to Changing the settings
For a first test of the rate limiting feature we made up our mind on how to test it. We soon came up with the idea of a small shell script that will run logger with a test message. The script looks as follows
n=1000 i=0 while [ $i -lt $n ] do logger "This is Testmessage #$i" echo "Messages: $i" i=`expr $i + 1` done
In this example, we have a pretty simple while loop. The loop will terminate, once the variable i has the size of n. In every run, i will be incremented by 1. After that a message is logged via logger and the message will be written to the terminal. You can download the script file here. Please note, that after downloading, you need to set chmod to 755 for this file.
Now run the file.
/foldername/ratelimittest
You will see a lot of lines being written to the terminal. In the current configuration, the while loop has 1000 iterations. When finished, the terminal will show the input prompt again. We can now review the log file to see if rate limiting worked.
vi /var/log/everything.log
Oct 5 17:01:57 client test: This is Testmessage #43 Oct 5 17:01:57 client test: This is Testmessage #44 Oct 5 17:01:57 client test: This is Testmessage #45 Oct 5 17:01:57 client test: This is Testmessage #46 Oct 5 17:01:57 client test: This is Testmessage #47 Oct 5 17:01:57 client test: This is Testmessage #48 Oct 5 17:01:57 client test: This is Testmessage #49 Oct 5 17:01:57 client test: This is Testmessage #50 Oct 5 17:01:57 client test: This is Testmessage #51 Oct 5 17:01:57 client test: This is Testmessage #52 Oct 5 17:01:57 client test: This is Testmessage #53 Oct 5 17:01:57 client test: This is Testmessage #54 Oct 5 17:01:57 client test: This is Testmessage #55 Oct 5 17:01:57 client test: This is Testmessage #56 Oct 5 17:01:57 client test: This is Testmessage #57 Oct 5 17:01:57 client test: This is Testmessage #58 Oct 5 17:01:57 client test: This is Testmessage #59 Oct 5 17:01:57 client test: This is Testmessage #60 Oct 5 17:01:57 client test: This is Testmessage #61
Let’s take a look at the messages around message 50. Usually, there should be a message after message 50, that some messages are not logged due to rate limiting. So either our test is not suitable because of the runtime or it isn’t recognized correctly. To check on this, we make another change to the rsyslog configuration file as we did before. Again, go to the section for imuxsock at the beginning. Now we add a third option for imuxsock.
$SystemLogUsePIDFromSystem on
With this option, the PID of the process that is sending a message to imuxsock will be added to the log. Therefore we can check if the process has run correctly. Save the config and restart rsyslog again. Now once more, let the script run and take a look at the log afterwards.
Oct 5 17:27:01 client test[6941]: This is Testmessage #41 Oct 5 17:27:01 client test[6943]: This is Testmessage #42 Oct 5 17:27:02 client test[6945]: This is Testmessage #43 Oct 5 17:27:02 client test[6947]: This is Testmessage #44 Oct 5 17:27:02 client test[6949]: This is Testmessage #45 Oct 5 17:27:02 client test[6951]: This is Testmessage #46 Oct 5 17:27:02 client test[6953]: This is Testmessage #47 Oct 5 17:27:02 client test[6955]: This is Testmessage #48 Oct 5 17:27:02 client test[6957]: This is Testmessage #49 Oct 5 17:27:02 client test[6959]: This is Testmessage #50 Oct 5 17:27:02 client test[6961]: This is Testmessage #51 Oct 5 17:27:02 client test[6963]: This is Testmessage #52 Oct 5 17:27:02 client test[6965]: This is Testmessage #53 Oct 5 17:27:02 client test[6967]: This is Testmessage #54 Oct 5 17:27:02 client test[6969]: This is Testmessage #55 Oct 5 17:27:02 client test[6971]: This is Testmessage #56 Oct 5 17:27:02 client test[6973]: This is Testmessage #57 Oct 5 17:27:02 client test[6975]: This is Testmessage #58 Oct 5 17:27:02 client test[6977]: This is Testmessage #59 Oct 5 17:27:02 client test[6979]: This is Testmessage #60
What we see now behind the username is the PID (Process ID). As we can see now, the PID is different for every log entry. That means, that a new process has been started for every message, thus rendering our test useless, because rate limiting only works if the same PID is given.
Therefore we need a specialized test tool. How to build the appropriate tool is shown on the next page.
Go on to How to build test-tools?