rsyslog

High-performance log ingestion and ETL engine

rsyslog

High-performance log ingestion and ETL engine

Changelog for 4.6.3 (v4-stable)

adisconteamChangelog,

Version 4.6.3 [v4-stable] (rgerhards), 2010-07-07

  • improvded testbench
  • added test with truly random data received via syslog to test robustness
  • added new configure option that permits to disable and enable an extended testbench
  • bugfix: segfault on HUP when “HUPIsRestart” was set to “on”
    thanks varmojfekoj for the patch
  • bugfix: default for $OMFileFlushOnTXEnd was wrong (“off”).
    This, in default mode, caused buffered writing to be used, what means that it looked like no output were written or partial lines. Thanks to Michael Biebl for pointing out this bug.
  • bugfix: testbench failed when not executed in UTC+1 timezone accidently, the time zone information was kept inside some to-be-checked-for responses
  • temporary bugfix replaced by permanent one for message-induced off-by-one error (potential segfault) (see 4.6.2)
    The analysis has been completed and a better fix been crafted and integrated.
  • some doc fixes; incorrect config samples could cause confusion
    thanks to Anthony Edwards for pointing the problems out

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.

How to separate log files by host name of sending device?

Adiscon SupportFAQ, ,

Question:
I have activated remote logging and receiving syslog messages from several devices. I want to write a separate log file for each device sending syslog messages. How to achieve that?

Answer:
It is pretty easy. You can use dynaFiles for it. With them, you specify a template as the file name. For each message, the filename is re-generated and the output written to the respective file. Read the config file doc for details, but it basically is:

$template DynaFile,”/var/log/system-%HOSTNAME%.log”
*.* -?DynaFile

Changelog for 5.5.5 (devel)

adisconteamChangelog, ,

Version 5.5.5 [DEVEL] (rgerhards), 2010-05-20

  • added new cancel-reduced action thread termination method
    We now manage to cancel threads that block inside a retry loop to terminate without the need to cancel the thread. Avoiding cancellation helps keep the system complexity minimal and thus provides for better stability.
    This also solves some issues with improper shutdown when inside an action retry loop.

rsyslog 5.5.5 (devel) released

adisconteamNews, Release Announcement, ,

Hi all,

We have just released rsyslog 5.5.5, a member of the devel branch. This is a bug-fixing release which contains a single fix that solves a potential hang condition on system shutdown when infinite action retries are configured for an asynchronous action using a queue in disk-assisted mode and the action was suspended. This is probably not a very common case, but a configuration recommended by our doc samples. If you do not use such a configuration, there is no need to update at this time. See Changelog for more details.

ChangeLog:

http://www.rsyslog.com/article461/

Download:

http://www.rsyslog.com/Downloads-req-viewdownloaddetails-lid-204.phtml

As always, feedback is appreciated.

Best regards,
Tom Bergfeld

Scroll to top