rsyslog

High-performance log ingestion and ETL engine

rsyslog

High-performance log ingestion and ETL engine

Author : Adiscon Support

How to build the testing tools?

Adiscon SupportFAQ, sub-faq, , , , ,

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.

Go on to Second try to test rate limiting (success)

How to use debug on demand?

Adiscon SupportFAQ,

This article should show how the “debug on demand” function works in rsyslog. It has been tested and verified with rsyslog 6.1.0 (v6-Devel) on Fedora 13 (steps may vary on different OS). It is assumed, that rsyslog is already working on the system. On notes regarding the installation and configuration, please take a look at the documentation. Debug on Demand is available since version 4.5.7.

To get this option working, we need to enable it first. This is done by enabling it and specifying a path for the debug log file. Open up a terminal with root rights and use the following commands:

export RSYSLOG_DEBUG="DebugOnDemand NoStdOut"
export RSYSLOG_DEBUGLOG=/somepath/example.log

The first option enables the “debug on demand” itself without standard output. This is necessary to have it disabled when starting the service. The second option specifies the path and name of the log file.

Now we have to stop the rsyslog service, before we are ready. Use the following command:

/etc/rc.d/init.d/rsyslog stop

We have now stopped the service and need to start it again. In the current configuration we need to start rsyslog as a foreground application. Due to it being much simpler to configure it this way, rsyslog needs to be a foreground application for “debug on demand” to work instead of a background service. Start it again as foreground application with the following command:

rsyslogd -n

Open up a second terminal (again with root) so we can enable or disable the “debug on demand”. Use this command:

kill -USR1 `cat /var/run/rsyslogd.pid`

Using this command once will enable the debug mode. Using it again will disable it. Please note that you definately need “-USR1” else the rsyslog will be really killed. Further make sure to use the backticks. These are important.

That’s it basically. You can now review your “debug on demand” log files.

Preserving syslog sender over NAT

Adiscon SupportFAQ,

Question:
I have a number of syslog clients behind a NAT device. The receiver receives syslog messages that travelled over the NAT device. This leads the receiver to believe that all messages originated from the same IP address. With stock syslogd, I can not differentiate between the senders. Is there any way to record the correct sender of the message with rsyslog?

Answer:
OK, I’ve now had some real lab time. The good news in short: if you use rsyslog both on the senders as well as on the receiver, you do NOT have any problems with NAT.

To double-check (and out of curiosity), I also tried with stock syslogd. I used the ones that came with RedHat and FreeBSD. Neither of them reports the sending machine correctly, they all report the NAT address. Obviously, this is what made this thread appear, but it is a good verification for the correctness of my lab. Next, I tried rsyslogd on the sender and stock syslogd on the receiver (just RedHat this time). The machine was still incorrectly displayed as the NAT address. However, now the real machine name immediately followed the NAT address, so you could differentiate the different machines – but in a inconsistent way.

Finally, I tried to run the stock syslogds against rsyslogd. Again, the host was not properly displayed. Actually, this time the host was not displayed at all (with the default rsyslogd template). Instead, the tag showed up in the host field. So this configuration is basically unusable.

The root cause of the NAT issue with stock syslogd obviously is that it does NOT include the HOST header that should be sent as of RFC 3164. This requires the receiver to take the host from the socket, which – in a NATed environment – can only hold the mangled NAT address. Rsyslog instead includes the HOST header, so the actual host name can be taken from that (this is the way rsyslog works with the default templates).

I barely remember seeing this in code when I initially forked rsyslog from sysklogd. I have not verified it once again. I have also not tested with syslog-ng, simply because that is not my prime focus and a lab would have required too much time.

To make a long story short: If you use rsyslog on both the senders and receivers, NAT is no issue for you.

Build problems with 0.9.6

Adiscon SupportFAQ

Bennett Todd has just alerted me of some problems with the new release. In short: the build process seems not to work at all (nor does the install do).

This is actually a documentation issue. The way of compiling rsyslog has changed slightly but importantly. You need to CD into an distribution-specific subdirectory (use linux of in doubt) and then call make. Do NOT do this in the root directory of the rsyslog project. It’s documented here

http://www.rsyslog.com/Documentation-/install.html.phtml

Looks like I must find some other place to document it… Or find a
different solution (read my blog on why I ended up with this:

http://rgerhards.blogspot.com/2005/08/make-syntax-differences.html

Sorry for any hassle. Suggestions are welcome!
Rainer

How to automatically delete database contents?

Adiscon SupportFAQ,

Rsyslog supports writing to the database. Like with log files, the rsyslogd writes the data, but does not delete (or export) it. If you need the data only for a period of time, simply deleting excess data might be a workable solution.

Below are some examples how this can be done (thanks to Michael Meckelein for posting this in the forum):

You can start a script via cron job, e. g.

mysql -u database-userid -pdatabase-password -e “truncate table SystemEvents” database-name

to delete all data or like

mysql -u database-userid -pdatabase-password -e “DELETE FROM SystemEvents WHERE ReceivedAt < date_add(current_date, interval -1 day)” database-name

to delete data older than one day.

Scroll to top