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) |
How to build the testing tools?
This article has been tested with rsyslog 5.7.1 on Fedora 13. It is part of the article “How to use rate limiting?”
Go back to First try to test rate limiting (fail)
When building a configuration for rsyslog, you will sometimes stumble upon the question, if your setup really works. To prove this in your environment is very complicated in most cases. For this we have made some test tools, which help you test your configuration. The main reason for us to create these tools was for testing new features and try out scenarios. But in the end we deliver them with every release. We will describe the way how to create and use the testing tools with the example of the tool syslog_caller. This tool creates a bunch of messages for the local loghost.
First you need to navigate to your rsyslog folder. From there you need to go to the subfolder tests. The path could look like this:
/home/username/rsyslog/tests/
We need to “make” the tests first before we can use it.
# make syslog_caller
The make process gives you some output. It looks like this:
CC syslog_caller.or CCLD syslog_caller
After that, we are ready to use the test-tool. Use the following command:
./syslog_caller
This will generate 500 messages by default. You can change the default values with some switches. The switches are usually documented in the .c file of the tool. In this case, when using the following:
./syslog_caller -m 10000
will generate 10000 messages. With the test tools, you can do some stress-testing for your rsyslog installation. A good way to proof, if your configuration is working correctly.