Changelog for 7.5.5 (v7-devel)
Version 7.5.5 [devel] 2013-10-16
- imfile: permit to monitor an unlimited number of files
- imptcp: add “defaultTZ” input parameter
- imudp: support for multiple receiver threads added
- imudp: add “dfltTZ” input config parameter
- bugfix: memory leak in mmnormalize
- bugfix: mmutf8fix did not properly handle invalid UTF-8 at END of message if the very last character sequence was too long, this was not detected
Thanks to Risto Vaarandi for reporting this problem. - mmanon: removed the check for specific “terminator characters” after last octet. As it turned out, this didn’t work in practice as there was an enormous set of potential terminator chars — so removing them was the best thing to do. Note that this may change behaviour of existing installations. Yet, we still consider this an important bugfix, that should be applied to the stable branch.
closes: http://bugzilla.adiscon.com/show_bug.cgi?id=477
Thanks to Muri Cicanor for initiating the discussion - now requires libestr 0.1.7 as early versions had a nasty bug in string comparisons
- bugfix: mmanon did not detect all IP addresses in rewrite mode
The problem occured if two IPs were close to each other and the first one was shrunk.
closes: http://bugzilla.adiscon.com/show_bug.cgi?id=485
Thanks to micah-at-riseup.net for reporting this bug - bugfix: mmanon sometimes used invalid replacement char in simple mode depending on configuration sequence, the replacement character was set to ‘s’ instead of the correct value. Most importantly, it was set to ‘s’ if simple mode was selected and no replacement char set.
closes: http://bugzilla.adiscon.com/show_bug.cgi?id=484
Thanks to micah-at-riseup.net for reporting this bug - bugfix: memory leak in mmnormalize
- bugfix: array-based ==/!= comparisions lead to invalid results
This was a regression introduced in 7.3.5 bei the PRI optimizer
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.