Search Results for: feed

rsyslog 5.9.6 (v5-beta) released

This is the first beta version of the 5.9 rsyslog branch. It primarily contains bug fixes and some enhancements over 5.9.5. Most important ones are support for inotify in imfile as well as additional  statistics counters. Note that 5.9.5 was made available in January 2012 and did not receive many bug reports. So we plan to put 5.9.6 on an expedited beta track, which hopefully will lead soon to a new v5-stable. As such, testing and feedback is most appreciated.

ChangeLog:

http://www.rsyslog.com/changelog-for-5-9-6-v5-beta/

Download:

http://www.rsyslog.com/rsyslog-5-9-6-beta/

As always, feedback is appreciated.

Best regards,
Florian Riedl

rsyslog 5.8.10 (v5-stable) released

This is primarily a bugfixing release. There were some segfaults in conjunction with $ActionQueueFileName and when the disk-queue was started with a old queue file. Our thanks go to Tomas Heinrich for the Patches. In addition there was a memory leak that has also been fixed.

ChangeLog:

http://www.rsyslog.com/changelog-for-5-8-10-v5-stable/

Download:

http://www.rsyslog.com/rsyslog-5-8-10-v5-stable/

As always, feedback is appreciated.

Best regards,

Florian Riedl

rsyslog 5.8.9 (v5-stable) released

This is primarily a maintenance release. It also provides a new tool that permits the recovery of disk queues, when the queue information file (.qi) has been lost. Thanks to Kaiwang Chen for contributing this tool.

There was an important flaw in 5.8.8 that caused disk queue content to be lost after a shutdown and restart of rsyslogd. So if you run this version, an upgrade to 5.8.9 is highly suggested.

ChangeLog:

http://www.rsyslog.com/changelog-for-5-8-9-v5-stable/

Download:

http://www.rsyslog.com/rsyslog-5-8-9-v5-stable/

As always, feedback is appreciated.

Best regards,

Tim Eifler

Receiving CEE enhanced syslog in rsyslog

We want to receive syslog messages from another system that contain Windows Events. The messages are sent in the CEE enhanced format. The syslog messages should be stored in a database to be reviewed with Adiscon LogAnalyzer.

Things to think about

For the basics, we need at least a listener for UDP or TCP, depending on what you are using. We will configure both for now. As additional modules, we will need mmjsonparse, which has been introduced in v6. And in addition the output module for a MySQL database.

To enable the modules, we need some templates.

Note, that the receiver ports you specify must match the ports on the sending machines.

Config Statements

# modules
$ModLoad imuxsock # provides support for local system logging
$ModLoad imklog   # provides kernel logging support (previously done by rklogd)
$ModLoad immark  # provides --MARK-- message capability
$ModLoad mmjsonparse
$ModLoad ommysql
$ModLoad imudp
$ModLoad imtcp
# provides UDP syslog reception
$UDPServerRun 514
# provides TCP syslog reception
$InputTCPServerRun 10514
# templates
$template database,"insert into systemevents (DeviceReportedTime, FromHost, EventLogType, EventSource, EventID, 
EventCategory, EventUser, Facility, Priority, Message) values ('%timereported:::date-rfc3339%', '%$!source%', 
'%$!nteventlogtype%', '%$!sourceproc%', '%$!id%', '%$!categoryid%', '%$!user%', '%syslogfacility%', 
'%syslogpriority%', '%$!msg:::space-cc%')",SQL
# actions
*.* :mmjsonparse:
& :ommysql:mysqlserver,database,user,password;database

How it works

First of all, we have the modules being loaded. In addition to the modules needed for local logging, we have loaded the input modules for UDP and TCP syslog.

The next part will enable the listeners. For UDP we use the default port 514. For TCP we use port 10514. Please note, that the senders MUST match the respective port.

The third step is to create a template. You can see it at as 4 lines here, but it really is a single line. mmjsonparse will take messages and process them. It will automatically detect the CEE enhanced json format an create custom properties with the name fields in the message and fill it the available content. But, to use it for a database insert, we need a custom insert statement. As you can see, the most important fields are present. These fields should already be available in the database that is used by Adiscon LogAnalyzer. We now only need to tell rsyslog, which database field will be filled with which field from the json message.

The format differences are important. Some fields will be filled with information from the syslog header, like the timestamp, facility and priority. Thus we can use the regular properties. The properties from the json message always need to start with “$!”. And for the msg property, we will additionaly use the space-cc option. This will strip line feeds from multiline messages.

Finally we have the actions. The first action “*.* :mmjsonparse:” will be applied to all messages here, though it will not be able to parse messages from the local log socket. This calls the mmjsonparse module to parse the message and fill the fields as mentioned before. The second line holds the output to mysql. We extended the chain of actions by “&” instead of a filter.

Important notes

The most crucial part is the template. If the template is not correct, the whole action chain will not work. Or it will work at least not correctly. Though, the above template should work fine with most Windows Events, it might be necessary to alter the template for other message types and database structures.

rsyslog 5.8.8 (v5-stable) released

This is a bug-fixing release. It fixes the wrong computed facility and severity in imklog and a problem with rsyslog aborting on startup if no binary to execute was configured for omprog.

ChangeLog:

http://www.rsyslog.com/changelog-for-5-8-8-v5-stable/

Download:

http://www.rsyslog.com/rsyslog-5-8-8-v5-stable/

As always, feedback is appreciated.

Best regards,

Florian Riedl

TCP syslog / RFC5424 log4j appender

As part of a training project, we created a small log4j appender supporting TCP syslog and RFC5424. Most importantly, it is capable of formatting stack traces as a single syslog messages (NOT the usual bunch of multiple malformed messages). The work is based on the syslog4j implementation, which did not work for us (our fault? ;)) and so we extended this framework. Note that the code has never been used in practice by us, so there may be some risk associated – but that should be fairly easy to asses, given that the source is pretty small.

The download of the RFC5424 syslog tcp appender contains it all: doc, jar files as well as the source.

Feedback and usage reports are appreciated, please send mail to ugerhards@adiscon.com (if you run into troubles, you can also use the same email address to discuss the problem!).

rsyslog 6.3.7 (v6-devel) released

With this release, all builtin actions support the new v6 config format. Also, the release contains much enhanced statistics counters and various bug fixes. Recommended for all users of the v6-devel branch.

ChangeLog:

http://www.rsyslog.com/changelog-for-6-3-7-v6-devel/

Download:

http://www.rsyslog.com/rsyslog-6-3-7-v6-devel/

As always, feedback is appreciated.

Best regards,
Florian Riedl

rsyslog 5.9.5 (v5-devel) released

This release brings many additional statistics counters and a couple of bug fixes. Note that the default setting of $IMUxSockRateLimitInterval was changed to 0, as rate limiting seems to have caused more trouble than it was worth. To enable it, simply set it to 200, the previous default.

ChangeLog:

http://www.rsyslog.com/changelog-for-5-9-5-v5-devel/

Download:

http://www.rsyslog.com/rsyslog-5-9-5-devel/

As always, feedback is appreciated.

Best regards,
Tim Eifler

rsyslog 5.8.7 (v5-stable) released

This is a bug-fixing release. The most important patches resolve instabilities with RFC5424 header fields and information loss when non-wellformed messages are submitted to the system log socket.

ChangeLog:

http://www.rsyslog.com/changelog-for-5-8-7-v5-stable/

Download:

http://www.rsyslog.com/rsyslog-5-8-7-v5-stable/

As always, feedback is appreciated.

Best regards,

Tim Eifler

rsyslog 6.2.0 (v6-stable) released

This is the initial stable release of rsyslog v6. It is basically the last beta version plus some more fixes. This version provides functional and performance enhancements, for example the Hadoop (HDFS) support has been considerably speeded up by supporting batched insert mode. Also, TCP transmission overhead for TLS has been dramatically improved. TCP now also supports input worker thread pools. Most importantly, rsyslog now supports log normalization via liblognorm rule bases. This permits very high performance normalization of semantically equal messages from different devices (and thus in different syntaxes).

Note that config scoping, available in the beta versions, is NOT supported by v6-stable. This was decided because it would have been functionality equivalent to the new config language upcoming in v6.3 (already available as part of the devel version). As scoping was not available in any earlier versions, introducing it in v6.2 would have added, in the long term, just another method of doing some identicaly thing via the ugly old config language. This would have lead to user confusion and more complex than necessary code. If you are interested in the cleaner config language, we strongly encourage you to have a look at rsyslog 6.3.

With the arrival of the stable v6 version, version 4 will be retired and is no longer officially supported (but support is provided under maintenance contracts, of course).

ChangeLog:

http://www.rsyslog.com/changelog-for-6-2-0-v6-stable/

Download:

http://www.rsyslog.com/rsyslog-6-2-0-v6-stable/

As always, feedback is appreciated.

Best regards,
Florian Riedl

Scroll to top