Search Results for: error 0

Newbie guide to rsyslog

Written by Jan Gerhards

Here are some different guides for people, who never worked with rsyslog. First I’ll explain, how to install rsyslog. Besides, I will explain how to install some packages, which you will need to install rsyslog. There are two important ones and some minor ones. After that, I will show how to do some easy configurations. Questions like how can I configure a module? Or How can I configure the input? Will be answered. In the example I will configure rsyslog to receive messages, filter them for one specific IP and store only the messages in a file. In the end I’ll explain something about easy rulesets. In my example I will try the same like I did with the configuration, but I will work with rulesets.

Before you begin

Please note, there are many ways to distribute rsyslog. But, make sure that the platform you build rsyslog on is the same platform as where it should be used. You cannot build rsyslog on CentOS and use it on Ubuntu. The differences between the platforms are just to big. The same applies to different versions of the same platform. When building on a older platform and using it on a newer version, this may work, but with restrictions. Whereas building on a newer version and using it on a older version will probably not work at all. So, if you build rsyslog from Source and want to use it on another machine, make sure the platform is the same.

Preliminary actions

There are generally two very often needed packages, that you have to install before rsyslog: libestr and libee. These can be downloaded here:

Libestr:       http://libestr.adiscon.com/download/

Libee:         http://www.libee.org/download/

Both are being installed the same, so here is only one step-by-step instruction.

  1. Download the file
    Just download libestr or libee and “cd” into the folder, where you want them.
  2. “tar xzf” the file
    after you “cd” to the folder, where the file is, type “tar xzf -name of file”. Your command line should look like this:

     tar xzf -name of file-
  3. “Cd” into the new folder
    “cd” into the made directory. It will have the same name like the downloaded file. Your command line should look like this:

     cd -name of file-
  4. Run “./configure configure –libdir=/usr/lib –includedir=/usr/include”
    After you “cd” into that file, just run ” ./configure –libdir=/usr/lib –includedir=/usr/include”. Your command line should look like this:

     ./configure --libdir=/usr/lib --includedir=/usr/include
  5. Type “sudo make”
    Just type this and let the Computer work. Your command line should look like this:

     sudo make
  6. Type “sudo make install”
    This is the last step. Like with “sudo make”, just let the computer work. Your command line should look like this

     sudo make install
  7. The package should work now
    Congratulation! You have installed the package! If it doesn’t work properly, you should check if you followed every step right and if you have, contact the support.

There might also be some other packages like libjson0-dev, uuid-dev, bison, flex, libz-dev or python-docutils. These you’ll have to install before installing rsyslog, too. This guide was made on Ubuntu, so if you use any other system, they might be named differently. You can install them with the command

sudo apt-get install -package name-

After you got all the packages, you can install rsyslog. Here is a How to for installing rsyslog.

 

How to install rsyslog

In this guide is explained how to install rsyslog with the download from the homepage.

 

  1. Download rsyslog
    You can download rsyslog from the rsyslog webpage at http://www.rsyslog.com/download/
  2. “tar xzf” the file
    Open a terminal.  Then you “cd” to where you want the file and then type “tar xzf -name of downloaded file”. Your command line should look like this:

    tar xzf -name of downloaded file-
  3. “cd” into the new folder
    Then “cd” into the made directory. The new directory will have the same name like the downloaded file. Your command line should look like this:

     cd -name of file-
  4. Type “./configure –prefix=/usr”
    You just need to run “./configure –prefix=/usr”. There might be an Error that you need to install some packages to precede with installing. For two specific packages I’ve explained how to install them, because you will need them often. Your command line should look like this:

    ./configure --prefix=/usr
  5. Run “sudo make”
    it’s easy, just run “sudo make” and let the computer work. Your command line should look like this:

     sudo make
  6. Run “sudo make install”
    Just like “sudo make”. Type it, press enter and let the Computer work. Again, there might be some missing packages. Just install them. Your command line should look like this:

     sudo make install
  7. Rsyslog should now be installed
    Congratulation! You have installed rsyslog! You can check the version of rsyslog by typing: “rsyslogd -v”.
    If it doesn’t work properly, you should check if you followed every step right and if you have, contact the support.

 

Now after you installed rsyslog, you have to configure it. How to do this is explained here.

 

Configure rsyslog

In this part I’ll explain some basic configuration steps for rsyslog. We configure rsyslog to recive UDP messages, to filter them depending on the IP of the host and to store them in a file.

  1. How to configure the module
    The module has to be configured first. The general line for this configuration is: “module (load=”im-type of protocol-”). So in our example, where we want UDP, it will look like this:

    Module (load=”imudp”)
  2. How to configure the input for rsyslog
    For the input, you have to give two different information to rsyslog. The first information needed is the protocol type of the input; in my example again UDP. Like in the first line there is an “im-” in front of the protocol-type. The other information is to configure a port for rsyslog, in my example 514. These two information are together in only one line. The line is: “Input (type=”-protocol of input-“port=”-number of port-“). This means for my example, the line has to be

    Input (type=”imudp” port=”514”)
  3. How to configure a filter for fromhost-IPs and store them in a file
    A filter always has, like a normal conditional sentence, an “if…then” part. If you want to configure it to do something with all notes from a specific IP, between “if” and “then” will be the property “$fromhost-ip ==”-IP, you want to filter-”. After this stays a “then” and after the “then” follows an action in brackets, which I will explain later. In my example I want only the notes from the host with the IP 172.19.1.135. So the line will be

    If $fromhost-ip == “172.19.1.135” then {

    After this we have to tell the computer, what to do if that case is given. In this example we want him to store these messages in the file “/var/log/network1.log”. This is an action with the type “omfile”. To configure the file where to store the messages, the action is “action (type=”omfile” File=”-filename-“). So in this example, it will look like this:

    Action (type=”omfile” file=”/var/log/network1.log”)
    }

 

All the lines together now are

Module (load=“imudp“)

Input (type=”imudp” port=”514”)
If $fromhost-ip == “172.19.1.135“ then {
Action (type=”omfile” File=”/var/log/network1.log”)
}

All in all it means: The input for rsyslog will listen to syslog via UDP on port 514. If the IP from the Computer, which sends the messages, is 172.19.1.135, then the action in the brackets will get activated for these. In the action the messages will be stored in the file /var/log/network1.log.

 

Rsyslog and rulesets

Rulesets are a bit more complicated. A ruleset is a set of rules, as the name implies. These are bound to an input. This works by adding an option to the input, namely “ruleset=”-rulesetname-“”. For example, if I want to bind a ruleset “rs1” to a input the line will look like this:

Input (type=”imudp” port=”514” ruleset=”rs1”)

But you still have to define, what the ruleset should do. In this guide I will limit myself to explain, how to create a ruleset, which has one action: to store all the messages in a file. In my example I want to store the messages in the file /var/log/network1.log”.

You define a ruleset like the normal configuration. To define it, you first name it with ruleset (name=”-rulesetname-“). After this you write what it does, in my example the action action (type=”omfile” file=”/var/log/network1.log”). This action you write in these curly brackets: {}.

So my full example looks like this

Module (load=”imudp”)

Input (type=”imudp” port=”514” ruleset=”rs1”)

Ruleset (name=”rs1”) {
Action (type=”omfile” file=”/var/log/network1.log”)
}

In that second example for configurations you can see, how to store all messages from the input into a file by using a ruleset. A rulesset can consist of multiple rules, but without binding it to the input it is useless. It can be bound to an input multiple times or even other rulesets can be called.

 

Final Conclusion

In this guide I explained how to install rsyslog, how to configure it and how to use rulesets. After you read this guide you are able to do exactly this: you can install rsyslog, configure it and have basic knowlege about rulesets. If you want to learn more about rsyslog, how to configure it or about rulesets, you can find information in the other guides or in the documentation.

Changelog for 7.3.12 (v7-devel)

Version 7.3.12  [devel] 2013-04-25

  • added doc for omelasticsearch
    Thanks to Radu Gheorghe for the doc contribution.
  • omelasticsearch: _id field support for bulk operations
    closes: http://bugzilla.adiscon.com/show_bug.cgi?id=392
    Thanks to Jérôme Renard for the idea and patches.
  • max number of templates for plugin use has been increased to five
  • platform compatibility enhancement: solve compile issue with libgcrypt
    do not use GCRY_CIPHER_MODE_AESWRAP where not available
  • fix compile on Solaris
    Thanks to Martin Carpenter for the patch.
  • bugfix: off-by-one error in handling local FQDN name (regression)
    A remporary buffer was allocated one byte too small. Did only affect startup, not actual operations. Came up during routine tests, and can have no effect once the engine runs. Bug was introduced in 7.3.11.
  • bugfix: build problems on Solaris
    closes: http://bugzilla.adiscon.com/show_bug.cgi?id=436
  • bugfix: block size limit was not properly honored
  • bugfix: potential segfault in guardtime signature provider
    it could segfault if an error was reported by the GuardTime API, because an invalid free could happen then

Changelog for 7.3.9 (v7-devel)

Version 7.3.9 [devel] 2013-03-27

  • support for signing logs added
  • imudp: now supports user-selectable inputname
  • omlibdbi: now supports transaction interface
    if recent enough lbdbi is present
  • imuxsock: add ability to NOT create/delete sockets during startup and
    shutdown
    closes: http://bugzilla.adiscon.com/show_bug.cgi?id=259
  • imfile: errors persisting state file are now reported
    closes: http://bugzilla.adiscon.com/show_bug.cgi?id=292
  • imfile: now detects file change when rsyslog was inactive
    Previosly, this case could not be detected, so if a file was overwritten
    or rotated away while rsyslog was stopped, some data was missing. This
    is now detected and the new file being forwarded right from the
    beginning.
    closes: http://bugzilla.adiscon.com/show_bug.cgi?id=228
  • updated systemd files to match current systemd source
  • bugfix: imudp scheduling parameters did affect main thread, not imudp
    closes: http://bugzilla.adiscon.com/show_bug.cgi?id=409
  • bugfix: build problem on platforms without GLOB_NOMAGIC
  • bugfix: build problems on non-Linux platforms
  • bugfix: stdout/stderr were not closed on forking
    but were closed when running in the forground – this was just reversed
    of what it should be. This is a regression of a recent change.

Changelog for 7.3.7 (v7-devel)

Version 7.3.7  [devel] 2013-03-12

  • add support for anonymizing IPv4 addresses
  • add support for writing to the Linux Journal (omjournal)
  • imuxsock: add capability to ignore messages from ourselves
    This helps prevent message routing loops, and is vital to have if omjournal is used together with traditional syslog.
  • field() function now supports a string as field delimiter
  • added ability to configure debug system via rsyslog.conf
  • bugfix: imuxsock segfault when system log socket was used
  • bugfix: mmjsonparse segfault if new-style config was used
  • bugfix: script == comparison did not work properly on JSON objects
  • bugfix: field() function did never return “***FIELD NOT FOUND***”
    instead it returned “***ERROR in field() FUNCTION***” in that case

Changelog for 7.2.6 (v7-stable)

Version 7.2.6  [v7-stable] 2013-03-05

  • slightly improved config parser error messages when invalid escapes happen
  • bugfix: include files got included in the wrong order
    closes: http://bugzilla.adiscon.com/show_bug.cgi?id=411
    This happens if an $IncludeConfig directive was done on multiple files (e.g. the distro default of $IncludeConfig /etc/rsyslog.d/*.conf). In that case, the order of include file processing is reversed, which could lead to all sorts of problems.
    Thanks to Nathan Stratton Treadway for his great analysis of the problem, which made bug fixing really easy.
  • bugfix: omelasticsearch failed when authentication data was provided … at least in most cases it emitted an error message:
    “snprintf failed when trying to build auth string”
    Thanks to Joerg Heinemann for alerting us.
    closes: http://bugzilla.adiscon.com/show_bug.cgi?id=404
  • bugfix: some property-based filter were incorrectly parsed
    This usually lead to a syntax error on startup and rsyslogd not actually starting up. The problem was the regex, which did not care for double quote characters to follow in the action part – unfortunately something that can frequently happen with v6+ format. An example:
    :programname, isequal, “as” {action(type=”omfile” …) }
    Here, the part
    :programname, isequal, “as” {action(type=”omfile”
    was treated as the property filter, and the rest as action part. Obviously, this did not work out. Unfortunately, such situations usually resulted in very hard to understand error messages.

How can I check the config?

We have often seen the case, that someone has rsyslog running and makes changes to the configuration. And usually, after making the changes, rsyslog gets restarted, but the changed config is invalid. rsyslog has a function to check the configuration for validity. This can be done very easily by invoking this command:

rsyslogd -N1

(Note that rsyslogd may not be in your search path – then it usually is found in /sbin/rsyslogd)

This tells rsyslog to do a config check. It does NOT run in regular mode, but just check configuration file correctness. This option is meant to verify a config file. To do so, run rsyslogd interactively in foreground, specifying -f <config-file> and -N level. The level argument modifies behaviour. Currently, 0 is the same as not specifying the -N option at all (so this makes limited sense) and 1 actually activates the code.

This configuration check will only check the configuration for integrity like syntax. Additionaly, the modules will be loaded to make sure that they work properly. On the downside, since the engine will not be loaded, errors with permissions or alike cannot be checked. These will occur only when running rsyslog normally.

The verdict for this option is, that it is quite useful for a first check if the changes were correct, without running the configuration in live mode. This might help to prevent that rsyslog gets restarted with a basically wrong configuration and thus rendering rsyslog useless, because it might not work or not work properly.

Changelog for 7.3.6 (v7-devel)

Version 7.3.6 [devel] 2013-01-28

  • greatly improved speed of large-array [N]EQ RainerScript comparisons
    Thanks to David Lang for a related discussion that inspired the idea
    to do this with a much simpler (yet sufficient) approach than orignally
    planned for.
  • greatly improved speed of DNS cache for large cache sizes
  • general performance improvements
  • omfile: added stats counters for dynafile caches
  • omfile: improved async writing, finally enabled full async write
    also fixed a couple of smaller issues along that way
  • impstats: added ability to write stats records to local file
    and avoid going through the syslog log stream. syslog logging can now
    also be turned off (see doc for details).
  • bugfix: imklog issued wrong facility in error messages
    …what could lead to problems in other parts of the code
  • fix compile problem in imklog
  • added capability to output thread-id-to-function debug info
    This is a useful debug aid, but nothing of concern for regular users.

Filter optimization with arrays

If you are using a lot of filters and templates in rsyslog, this can not only be affecting the performance drastically, but it is also a hassle to set up all the different actions and templates. It is always worthy to check, if there isn’t a shortcut somewhere, which might not only save you time for creating the configuration, but also make it much simpler in the end to keep track of all the actions.

In our example, we have several programnames. The log messages should be sorted by programname and then be stored in a specific file and be sorted by host. After storing the log messages, the message should be discarded, so it won’t be processed by the following filters, thus saving otherwise wasted processing time. This example is applicable to rsyslog v7.2.x and above.

Here are some sample config lines.

## apache_access
template(name="DailyPerHost_apache_access" type="string" string="/syslog/%FROMHOST%/apache_access.log")
:programname, isequal, "apache_access" { action(type="omfile" DynaFile="DailyPerHost_apache_access") stop }

## apache_error
template(name="DailyPerHost_apache_error" type="string" string="/syslog/%FROMHOST%/apache_error.log")
:programname, isequal, "apache_error" { action(type="omfile" DynaFile="DailyPerHost_apache_error") stop }
## mysql
template(name="DailyPerHost_mysql" type="string" string="/syslog/%FROMHOST%/mysql.log")
:programname, isequal, "mysql" { action(type="omfile" DynaFile="DailyPerHost_mysql") stop }

## php
template(name="DailyPerHost_php" type="string" string="/syslog/%FROMHOST%/php.log")
:programname, isequal, "php" { action(type="omfile" DynaFile="DailyPerHost_php") stop }

These are some basic services, which are often run together. Please note, that these are just a few examples. As you can see here, the template is created first. It is given a name, type and format. Templates of type string are usually used for file names. Here the log messages get stored in the folder /syslog a subfolder for the host where the message occured and then a filename which reflects the type of message that occured.

The second line holds the actions. First you see the property based filter (programname) and the condition. After that the actions get chained with the curly braces. The log messages where the filter evaluates to true get stored in a file. The filename and path is generated dynamically with the DynaFile parameter. Through this, the above written template will be used to generate the path and filename. The second action is represented by stop. Please note that this is case sensitive. Basically, stop means to stop the message processing. No further processing of the message will take place.

If we look closely at the sample config lines, we see, that the filter condition is basically always the same. It will always filter the programname property for a certain value. This is a predestinated case for using an array for simplification. We can use the property programname in the file template as well and filter an array of values. This will greatly save the overhead for all the seperate filter, not only in the configuration, but also in processing the messages.

template(name="DailyPerHost_app" type="string" string="/syslog/%FROMHOST%/%programname%.log")
if $programname == ["apache_access",
                    "apache_error",
                    "mysql",
                    "php"]
                then {
                action(type="omfile" DynaFile="DailyPerHost_app")
                stop
                }

Again, we first create the template. Please note the difference in the filename where the hardcoded text has been replaced by the property programname. In the next lines, we see the filter and the array of values. This is just to reflect the example. Virtually, the array can have near-infinite values. The filter is also a common if/then construct. After the then we see our chain of commands. First the action which writes the log messages into a file where the filename is created by the above template and then a stop as second action.

This case is applicable in many forms. It is also most useful if you are filtering and the discarding a lot of messages with very common filter settings. You could use it to filter for an array of property values and even chain comparison operations.

Changelog for 7.2.5 (v7-stable)

Version 7.2.5  [v7-stable] 2013-01-08

  • build system cleanup (thanks to Michael Biebl for this!)
  • bugfix: omelasticsearch did not properly compile on some platforms due to missing libmath. Thanks to Michael Biebl for the fix
  • bugfix: invalid DST handling under Solaris
    Thanks to Scott Severtson for the patch.
  • bugfix: on termination, actions were incorrectly called
    The problem was that incomplete fiter evaluation was done *during the shutdown phase*. This affected only the LAST batches being processed. No problem existed during the regular run. Could usually only happen on very busy systems, which were still busy during shutdown.
  • bugfix: very large memory consumption (and probably out of memory) when FromPos was specified in template, but ToPos not.
    Thanks to Radu Gheorghe for alerting us of this bug.
  • bugfix: timeval2syslogTime cause problems on some platforms due to invalid assumption on structure data types.
    closes: http://bugzilla.adiscon.com/show_bug.cgi?id=394
    Thanks to David Hill for the patch [under ASL2.0 as per email conversation 2013-01-03].
  • bugfix: compile errors in im3195
    Thanks to Martin Körper for the patch
  • bugfix: doGetFileCreateMode() had invalid validity check ;)
    Thanks to Chandler Latour for the patch.
  • bugfix: mmjsonparse errornously returned action error when no CEE cookie was present.

Changelog for 7.3.5 (v7-devel)

Version 7.3.5 [devel] 2012-12-19

  • ommysql: addded batching/transaction support
  • enhanced script optimizer to optimize common PRI-based comparisons
    These constructs are especially used in SUSE default config files,
    but also by many users (as they are more readable than the equivalent
    PRI-based filter).
  • omudpspoof: add support for new config system
  • omudpspoof: add support for packets larger than 1472 bytes
    On Ethernet, they need to be transmitted in multiple fragments. While
    it is known that fragmentation can cause issues, it is the best choice
    to be made in that case. Also improved debug output.
  • bugfix: omudpspoof failed depending on the execution environment
    The v7 engine closes fds, and closed some of libnet’s fds as well, what
    lead to problems (unfortunately, at least some libnet versions do not
    report a proper error state but still “success”…). The order of libnet
    calls has been adjusted to by in sync with what the core engine does.
  • bugfix: segfault on imuxsock startup if system log socket is used
    and no ratelimiting supported. Happens only during initial config
    read phase, once this is over, everything works stable.
  • bugfix: mmnormalize build problems
  • bugfix: mmnormalize could abort rsyslog if config parameter was in error
  • bugfix: no error message for invalid string template parameters
    rather a malformed template was generated, and error information emitted
    at runtime. However, this could be quite confusing. Note that with this
    “bugfix” user experience changes: formerly, rsyslog and the affected
    actions properly started up, but the actions did not produce proper
    data. Now, there are startup error messages and the actions are NOT
    executed (due to missing template due to template error).
  • bugfix[minor]: invalid error code when mmnormalize could not access rulebase
  • bugfix(kind of): script optimizer did not work for complex boolean expressions
  • doc bugfix: corrections and improvements in mmnormalize html doc page
  • bugfix: some message properties could be garbled due to race condition
    This happened only on very high volume systems, if the same message was
    being processed by two different actions. This was a regression caused
    by the new config processor, which did no longer properly enable msg
    locking in multithreaded cases. The bugfix is actually a refactoring of
    the msg locking code – we no longer do unlocked operations, as the use
    case for it has mostly gone away. It is potentially possible only at
    very low-end systems, and there the small additional overhead of doing
    the locking does not really hurt. Instead, the removal of that
    capability can actually slightly improve performance in common cases,
    as the code path is smaller and requires slightly less memory writes.
    That probably outperforms the extra locking overhead (which in the
    low-end case always happens in user space, without need for kernel
    support as we can always directly aquire the lock – there is no
    contention at all).
  • build system cleanup (thanks to Michael Biebl for this!)
  • bugfix: omelasticsearch did not properly compile on some platforms
    due to missing libmath. Thanks to Michael Biebl for the fix.
Scroll to top