imrelp

rsyslog 7.5.0 (v7-devel) released

This release opens the new 7.5 development branch. Most importantly, this version provides TLS protection for RELP (note that librelp 1.1.1 is required).

More information can be found in this blogpost: http://blog.gerhards.net/2013/06/new-rsyslog-devel-branch-75.html

ChangeLog:

http://www.rsyslog.com/changelog-for-7-5-0-v7-devel/

Download:

http://www.rsyslog.com/rsyslog-7-5-0-v7-devel/

As always, feedback is appreciated.

Best regards,
Florian Riedl

TLS secured syslog via RELP

This article will show you, how to use simple tls encryption with the RELP protocol for sending and receiving syslog messages.

We basically need two machines, both running at least rsyslog 7.3.16. In addition to rsyslog, we also need the most current version of librelp.

General information

When installing rsyslog, make sure to enable the RELP functionality by issuing the correct commands for the configure. The configure command should look like this:

./configure --prefix=/usr --enable-relp

This is the most basic command for our example. Please note, that you might need to enable other modules as well if you plan to use them.

Before you start to configure rsyslog on either machine, make sure you have librelp already installed. You might need to additionaly install the gnutls package.

Client Config

The configuration for the client is relatively simple.  Basically, we can use as inputs whatever we like and simply use RELP with TLS encryption for forwarding the messages. The configuration could look like this:

module(load="imuxsock")
module(load="imudp")
module(load="omrelp")

input(type="imudp" port="514")

action(type="omrelp" target="192.168.233.144" port="2514" tls="on")

As you can see, we first load our modules. That is a generic step. We also load the output module “omrelp” which enables us later to forward messages via RELP.

In the second stage we configure our input. This example has the ability to receive syslog via imudp on port 514.

And the final step is our action. We use omrelp to forward all log messages to our central server via port 2514. Please note the option tls=”on” which directs the module to encrypt all messages via TLS.

Server Config

The server configuration looks a bit different and is one step more complicated.

module(load="imuxsock")
module(load="imrelp" ruleset="relp")

input(type="imrelp" port="2514" tls="on")

ruleset(name="relp") {
action(type="omfile" file="/var/log/relptls")
}

Again, we first configure the modules. Contrary to the Client configuration, we load “imrelp” and create the input with it in the second step.

The input with imrelp must listen to the same port, that the client sends its messages to. Also we must enable the TLS option as well. The reason might seem obvious, because without the option enabled, imrelp will push only garbage messages into the processing system. So we need TLS enabled to decrypt the messages. Please note, that I also bound the input to a ruleset.

The ruleset and action are again very basic. The ruleset (which is bound to the input) ensures, that only the messages that are received via RELP are processend by the enclosed actions. This is much easier, than creating filters to determine the source of the message (not only from a setup point of view, but also in regards of processing speed). The action in the ruleset will then write all messages that run into the ruleset into a single file. Please note: for imrelp, you can only bind the module to a ruleset. In consequence, all created listeners of this type are bound to this single ruleset.

 

Changelog for 6.5.0 (v6-devel)

Version 6.5.0  [devel] 2012-08-28

  • imrelp now supports non-cancel thread termination
    (but now requires at least librelp 1.0.1)
  • implemented freeCnf() module interface
    This was actually not present in older versions, even though some modules already used it. The implementation was now done, and not in 6.3/6.4 because the resulting memory leak was ultra-slim and the new interface handling has some potential to seriously break things. Not the kind of thing you want to add in late beta state, if avoidable.
  • added –enable-debugless configure option for very high demanding envs
    This actually at compile time disables a lot of debug code, resulting in some speedup (but serious loss of debugging capabilities)
  • added new 0mq plugins (via czmq lib)
    Thanks to David Kelly for contributing these modules
  • bugfix: omhdfs did no longer compile
  • bugfix: SystemLogSocketAnnotate did not work correctly
    Thanks to Miloslav Trmač for the patch
  • $SystemLogParseTrusted config file option
    Thanks to Milan Bartos for the patch
  • added template config directive
  • added new uuid message property
    Thanks to Jérôme Renard for the idea and patches.
    Note: patches were released under ASL 2.0, see
    http://bugzilla.adiscon.com/show_bug.cgi?id=353

rsyslog statistics counter

Rsyslog supports statistic counters via the impstats module. It is important to know that impstats and friends only provides an infrastructure where core components and plugins can register statistics counter. This FAQ entry tries to describe all counters available, but please keep in mind that there may exist that we  do not know about.

When interpreting rsyslog statistics, please keep in mind that statistics records are processed as regular syslog messages. As such, the statistics messages themselves increment counters when they are emitted via the regular syslog stream, which is the default (and so counters keep slowly increasing even if there is absolutely no other traffic). Also keep in mind that a busy rsyslog system is very dynamic. Most importantly, this means that the counters may not be 100% consistent, but some slight differences may exist. Avoiding such inconsistencies would be possible only at the price of a very tight locking discipline, which would cause serious performance bottlenecks. Thus, this is not done. Finally, though extremely unlikely, some counters may experience an overflow and restart at 0 for that reasons. However, most counters are 64-bit, so this is extremely unlikely. Those which are not 64 bit are typically taken from some internal data structure that uses lower bits for performance reasons and guards against overflow.

The listing starts with the core component or plugin that creates the counters and than specifies various counters that exist for the sub-entities. The listing below is extended as new counters are added. Some counters probably do not exist in older releases of rsyslog.

Below you can find all available core components and plugins. Please note that every core component or plugin are linked to a information site.

Queue
Actions

PLUGINS

Scroll to top