From 184d8cf6d27ea1753cc78b74b6d81a8433a6d59a Mon Sep 17 00:00:00 2001 From: Marc Schiffbauer Date: Mon, 8 Feb 2010 14:20:15 +0100 Subject: improved PostgreSQL database create script, provided doc on PostgreSQL setup Signed-off-by: Rainer Gerhards --- doc/src/rsyslog-pgsql.odt | Bin 0 -> 41755 bytes 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 doc/src/rsyslog-pgsql.odt (limited to 'doc') diff --git a/doc/src/rsyslog-pgsql.odt b/doc/src/rsyslog-pgsql.odt new file mode 100644 index 00000000..5034c5fb Binary files /dev/null and b/doc/src/rsyslog-pgsql.odt differ -- cgit From c34e7d21146a3e6722bbf159a06750fdef23b4f8 Mon Sep 17 00:00:00 2001 From: Rainer Gerhards Date: Mon, 8 Feb 2010 14:30:08 +0100 Subject: integrated new PostgreSQL doc converted to html, linked, etc... --- doc/Makefile.am | 1 + doc/manual.html | 1 + doc/rsyslog_pgsql.html | 336 ++++++++++++++++++++++++++++++++++++++++++++++ doc/src/rsyslog-pgsql.odt | Bin 41755 -> 0 bytes doc/src/rsyslog_pgsql.odt | Bin 0 -> 41755 bytes 5 files changed, 338 insertions(+) create mode 100644 doc/rsyslog_pgsql.html delete mode 100644 doc/src/rsyslog-pgsql.odt create mode 100644 doc/src/rsyslog_pgsql.odt (limited to 'doc') diff --git a/doc/Makefile.am b/doc/Makefile.am index 3dfc8d3a..a1f192ee 100644 --- a/doc/Makefile.am +++ b/doc/Makefile.am @@ -19,6 +19,7 @@ html_files = \ rsyslog_conf.html \ rsyslog-example.conf \ rsyslog_mysql.html \ + rsyslog_pgsql.html \ rsyslog_packages.html \ rsyslog_high_database_rate.html \ rsyslog_php_syslog_ng.html \ diff --git a/doc/manual.html b/doc/manual.html index 785845b6..289d490b 100644 --- a/doc/manual.html +++ b/doc/manual.html @@ -55,6 +55,7 @@ generic syslog application design

using diff --git a/doc/rsyslog_pgsql.html b/doc/rsyslog_pgsql.html new file mode 100644 index 00000000..dcb9dc3a --- /dev/null +++ b/doc/rsyslog_pgsql.html @@ -0,0 +1,336 @@ + + + + + + + + + + + + + + + + + +

Writing syslog messages +to MySQL, PostgreSQL or any other supported Database

Written by Rainer +Gerhards with some additions by Marc +Schiffbauer (2008-02-28)

Abstract

In this paper, I describe +how to write syslog +messages to a MySQL +or PostgreSQL +database. Having syslog messages +in a database is often handy, especially when you intend to set up a +front-end for viewing them. This paper describes an approach with +rsyslogd, +an alternative enhanced syslog daemon natively supporting MySQL and +PostgreSQL. I describe the components needed to be installed and how +to configure them. Please note that as of this writing, rsyslog +supports a variety of databases. While this guide is still MySQL- and +PostgreSQL-focused, you can probably use it together with other ones +too. You just need to modify a few settings.

Background

In many cases, syslog data is simply +written to text files. This approach has some advantages, most +notably it is very fast and efficient. However, data stored in text +files is not readily accessible for real-time viewing and analysis. +To do that, the messages need to be in a database. There are various +ways to store syslog messages in a database. For example, some have +the syslogd write text files which are later feed via a separate +script into the database. Others have written scripts taking the data +(via a pipe) from a non-database-aware syslogd and store them as they +appear. Some others use database-aware syslogds and make them write +the data directly to the database. In this paper, I use that "direct +write" approach. I think it is superior, because the syslogd +itself knows the status of the database connection and thus can +handle it intelligently (well ... hopefully ;)). I use rsyslogd to +acomplish this, simply because I have initiated the rsyslog project +with database-awareness as one goal.

One word of caution: +while message storage in the database provides an excellent +foundation for interactive analysis, it comes at a cost. Database i/o +is considerably slower than text file i/o. As such, directly writing +to the database makes sense only if your message volume is low enough +to allow a) the syslogd, b) the network, and c) the database server +to catch up with it. Some time ago, I have written a paper on +optimizing +syslog server performance. While this paper +talks about Window-based solutions, the ideas in it are generic +enough to apply here, too. So it might be worth reading if you +anticipate medium high to high traffic. If you anticipate really high +traffic (or very large traffic spikes), you should seriously consider +forgetting about direct database writes - in my opinion, such a +situation needs either a very specialized system or a different +approach (the text-file-to-database approach might work better for +you in this case). +

Overall System Setup

In this paper, I concentrate on +the server side. If you are thinking about interactive syslog message +review, you probably want to centralize syslog. In such a scenario, +you have multiple machines (the so-called clients) send their data to +a central machine (called server in this context). While I expect +such a setup to be typical when you are interested in storing +messages in the database, I do not describe how to set it up. This is +beyond the scope of this paper. If you search a little, you will +probably find many good descriptions on how +to centralize syslog. If you do that, it might be a good idea to do +it securely, so you might also be interested in my paper on +ssl-encrypting +syslog message transfer.

No matter how the messages arrive at +the server, their processing is always the same. So you can use this +paper in combination with any description for centralized syslog +reporting.

As I already said, I use +rsyslogd on the server. It has intrinsic support for talking to the +supported databases. For obvious reasons, we also need an instance of +MySQL or PostgreSQL running. To keep us focused, the setup of the +database itself is also beyond the scope of this paper. I assume that +you have successfully installed the database and also have a +front-end at hand to work with it (for example, phpMyAdmin +or phpPgAdmin. +Please make sure that this is installed, actually working and you +have a basic understanding of how to handle it.

Setting up the system

You need to download and +install rsyslogd first. Obtain it from the rsyslog +site. Make sure that you disable stock +syslogd, otherwise you will experience some difficulties. On some +distributions (Fedora 8 and above, for example), rsyslog may +already by the default syslogd, in which case you obviously do not +need to do anything specific. For many others, there are prebuild +packages available. If you use either, please make sure that you have +the required database plugins for your database available. It usually +is a separate package and typically not +installed by default.

It is important to understand +how rsyslogd talks to the database. In rsyslogd, there is the concept +of "templates". Basically, a template is a string that +includes some replacement characters, which are called "properties" +in rsyslog. Properties are accessed via the "Property +Replacer". Simply said, you access +properties by including their name between percent signs inside the +template. For example, if the syslog message is "Test", the +template "%msg%" would be expanded to "Test". +Rsyslogd supports sending template text as a SQL statement to the +database. As such, the template must be a valid SQL statement. There +is no limit in what the statement might be, but there are some +obvious and not so obvious choices. For example, a template "drop +table xxx" is possible, but does not make an awful lot of sense. +In practice, you will always use an "insert" statement +inside the template.

An example: if you would just like to +store the msg part of the full syslog message, you have probably +created a table "syslog" with a single column "message". +In such a case, a good template would be "insert into +syslog(message) values ('%msg%')". With the example above, that +would be expanded to "insert into syslog(message) +values('Test')". This expanded string is then sent to the +database. It's that easy, no special magic. The only thing you must +ensure is that your template expands to a proper SQL statement and +that this statement matches your database design.

Does that mean you need to +create database schema yourself and also must fully understand +rsyslogd's properties? No, that's not needed. Because we anticipated +that folks are probably more interested in getting things going +instead of designing them from scratch. So we have provided a default +schema as well as build-in support for it. This schema also offers an +additional benefit: rsyslog is part of Adiscon's +MonitorWare product +line (which includes open source and closed +source members). All of these tools share the same default schema and +know how to operate on it. For this reason, the default schema is +also called the "MonitorWare Schema". If you use it, you +can simply add phpLogCon, +a GPLed syslog web interface, to your system +and have instant interactive access to your database. So there are +some benefits in using the provided schema.

The schema definition is contained in +the file "createDB.sql". It comes with the rsyslog package +and one can be found for each supported database type (in the plugins +directory). Review it to check that the database name is acceptable +for you. Be sure to leave the table and field names unmodified, +because otherwise you need to customize rsyslogd's default sql +template, which we do not do in this paper. Then, run the script with +your favorite SQL client. Double-check that the table was +successfully created.

It is important to note that the +correct database encoding must be used so that the database will +accept strings independend of the string encoding. This is an +important part because it can not be guarantied that all syslog +messages will have a defined character encoding. This is especially +true if the rsyslog-Server will collect messages from different +clients and different products. +

For example PostgreSQL may refuse to +accept messages if you would set the database encoding to “UTF8” +while a client is sending invalid byte sequences for that encoding. +

Database support in rsyslog is +integrated via loadable plugin modules. To use the database +functionality, the database plugin must be enabled in the config file +BEFORE the first database table action is used. This is done by +placing the

$ModLoad ommysql

directive at the begining of /etc/rsyslog.conf for +MySQL and

$ModLoad ompgsql

for +PostgreSQL.

For +other databases, use their plugin name (e.g. omoracle).

Next, we need to tell rsyslogd to write data to +the database. As we use the default schema, we do NOT need to define +a template for this. We can use the hardcoded one (rsyslogd handles +the proper template linking). So all we need to do e.g. for MySQL is +add a simple selector line to /etc/rsyslog.conf:

*.* +:ommysql:database-server,database-name,database-userid,database-password

Again, other databases have other selector names, +e.g. ":ompgsql:" instead of ":ommysql:". See the +output plugin's documentation for details.

In many cases, the database will run +on the local machine. In this case, you can simply use "127.0.0.1" +for database-server. This can be especially advisable, if you +do not need to expose the database to any process outside of the +local machine. In this case, you can simply bind it to 127.0.0.1, +which provides a quite secure setup. Of course, rsyslog also supports +remote database instances. In that case, use the remote server name +(e.g. mydb.example.com) or IP-address. The database-name by +default is "Syslog". If you have modified the default, use +your name here. Database-userid and -password are the +credentials used to connect to the database. As they are stored in +clear text in rsyslog.conf, that user should have only the least +possible privileges. It is sufficient to grant it INSERT privileges +to the systemevents table, only. As a side note, it is strongly +advisable to make the rsyslog.conf file readable by root only - if +you make it world-readable, everybody could obtain the password (and +eventually other vital information from it). In our example, let's +assume you have created a database user named "syslogwriter" +with a password of "topsecret" (just to say it bluntly: +such a password is NOT a good idea...). If your database is on the +local machine, your rsyslog.conf line might look like in this sample:

*.* +:ommysql:127.0.0.1,Syslog,syslogwriter,topsecret

Save rsyslog.conf, restart rsyslogd - and you +should see syslog messages being stored in the "systemevents" +table!

The example line stores every message +to the database. Especially if you have a high traffic volume, you +will probably limit the amount of messages being logged. This is easy +to accomplish: the "write database" action is just a +regular selector line. As such, you can apply normal selector-line +filtering. If, for example, you are only interested in messages from +the mail subsystem, you can use the following selector line:

mail.* :ommysql:127.0.0.1,syslog,syslogwriter,topsecret

Review the rsyslog.conf +documentation for details on selector lines and their filtering.

You have now completed +everything necessary to store syslog messages to the a database. +If you would like to try out a front-end, you might want to look at +phpLogCon, +which displays syslog data in a browser. As of this writing, +phpLogCon is not yet a powerful tool, but it's open source, so it +might be a starting point for your own solution.

On Reliability...

Rsyslogd writes syslog messages +directly to the database. This implies that the database must be +available at the time of message arrival. If the database is offline, +no space is left or something else goes wrong - rsyslogd can not +write the database record. If rsyslogd is unable to store a message, +it performs one retry. This is helpful if the database server was +restarted. In this case, the previous connection was broken but a +reconnect immediately succeeds. However, if the database is down for +an extended period of time, an immediate retry does not help.

Message loss in this scenario +can easily be prevented with rsyslog. All you need to do is run the +database writer in queued mode. This is now described in a generic +way and I do not intend to duplicate it here. So please be sure to +read "Handling +a massive syslog database insert rate with Rsyslog", +which describes the scenario and also includes configuration +examples.

Conclusion

With minimal effort, you can use +rsyslogd to write syslog messages to a database. You can even make it +absolutely fail-safe and protect it against database server downtime. +Once the messages are arrived there, you can interactively review and +analyze them. In practice, the messages are also stored in text files +for longer-term archival and the databases are cleared out after some +time (to avoid becoming too slow). If you expect an extremely high +syslog message volume, storing it in real-time to the database may +outperform your database server. In such cases, either filter out +some messages or used queued mode (which in general is recommended +with databases).

The method outlined in this paper +provides an easy to setup and maintain solution for most use cases.

Feedback Requested

I would appreciate feedback on this paper. If you +have additional ideas, comments or find bugs, please let +me know.

References and Additional Material

www.rsyslog.com + - the rsyslog site +
+
Paper + on Syslog Server Optimization +
+

Revision History

2005-08-02 * + Rainer + Gerhards * initial version created +
+
2005-08-03 * + Rainer + Gerhards * added references to demo site +
+
2007-06-13 * + Rainer + Gerhards * removed demo site - was torn down because too + expensive for usage count +
+
2008-02-21 * + Rainer + Gerhards * updated reliability section, can now be done with + on-demand disk queues
+
2008-02-28 * Rainer + Gerhards * added info on other databases, updated syntax to more + recent one +
+
2010-01-29 * Marc Schiffbauer * added some + PostgreSQL stuff, made wording more database generic, fixed some + typos
+

Copyright

+ + \ No newline at end of file diff --git a/doc/src/rsyslog-pgsql.odt b/doc/src/rsyslog-pgsql.odt deleted file mode 100644 index 5034c5fb..00000000 Binary files a/doc/src/rsyslog-pgsql.odt and /dev/null differ diff --git a/doc/src/rsyslog_pgsql.odt b/doc/src/rsyslog_pgsql.odt new file mode 100644 index 00000000..5034c5fb Binary files /dev/null and b/doc/src/rsyslog_pgsql.odt differ -- cgit From b1a118172074019c0dae9d54db9fbc2ca4824592 Mon Sep 17 00:00:00 2001 From: Rainer Gerhards Date: Tue, 9 Feb 2010 17:51:23 +0100 Subject: minor doc fix: wrong default ... that clearly showed I could not do my math ;) --- doc/rsconf1_markmessageperiod.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'doc') diff --git a/doc/rsconf1_markmessageperiod.html b/doc/rsconf1_markmessageperiod.html index 2c833339..a6486ba1 100644 --- a/doc/rsconf1_markmessageperiod.html +++ b/doc/rsconf1_markmessageperiod.html @@ -7,7 +7,7 @@

$MarkMessagePeriod

Type: specific to immark input module

Default: 1800 (20 minutes)

Default: 1200 (20 minutes)

Description:

This specifies when mark messages are to be written to output modules. The time specified is in seconds. Specifying 0 is possible and disables mark -- cgit From 76b3f2cd875dca755f4beee8dbf525c23d9730cf Mon Sep 17 00:00:00 2001 From: Rainer Gerhards Date: Wed, 10 Feb 2010 15:26:27 +0100 Subject: preparing for 4.5.8 --- doc/manual.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'doc') diff --git a/doc/manual.html b/doc/manual.html index 289d490b..f258686e 100644 --- a/doc/manual.html +++ b/doc/manual.html @@ -19,7 +19,7 @@ rsyslog support available directly from the source!

Please visit the rsyslog sponsor's page to honor the project sponsors or become one yourself! We are very grateful for any help towards the project goals.

This documentation is for version 4.5.7 (v4-beta branch) of rsyslog. +

This documentation is for version 4.5.8 (v4-beta branch) of rsyslog. Visit the rsyslog status page to obtain current version information and project status.

If you like rsyslog, you might -- cgit From f764f24baa542796776e76bb5f22fdf9d7e32f5e Mon Sep 17 00:00:00 2001 From: Rainer Gerhards Date: Wed, 17 Feb 2010 15:45:56 +0100 Subject: updated rsyslog/php-syslog-ng doc, now that phpLogCon has evolved so much --- doc/rsyslog_php_syslog_ng.html | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) (limited to 'doc') diff --git a/doc/rsyslog_php_syslog_ng.html b/doc/rsyslog_php_syslog_ng.html index bf48a1eb..ed4d72fc 100644 --- a/doc/rsyslog_php_syslog_ng.html +++ b/doc/rsyslog_php_syslog_ng.html @@ -7,8 +7,10 @@

Written by Rainer Gerhards (2005-08-04)

-
Note: it has been reported that this guide is somewhat outdated. Please -use with care.
+
Note: it has been reported that this guide is somewhat outdated. Please +use with care. Also, please note that rsyslog's "native" web frontend is +phpLogCon, which provides best integration +and a lot of extra functionality.

Abstract

In this paper, I describe how to use php-syslog-ng with @@ -116,11 +118,11 @@ those unfamiliar with syslog-ng, this configuration is probably easier to set up then switching to syslog-ng. For existing rsyslogd users, php-syslog-ng might be a nice add-on to their logging infrastructure.

Please note that the MonitorWare family (to which rsyslog belongs) also -offers a web-interface: phpLogCon. At the time of this writing, phpLogCon's code -is by far not as clean as I would like it to be. Also the user-interface is -definitely not as intutive as pp-syslog-ng. From a functionality point of view, -however, I think it already is a bit ahead. So you might -consider using it. I have set up a demo server., +offers a web-interface: phpLogCon. +From my point of view, obviously, phpLogCon is the more natural choice for a web interface +to be used together with rsyslog. It also offers superb functionality and provides, +for example,native display of Windows event log entries. +I have set up a demo server., You can have a peek at it without installing anything.

Feedback Requested
-- cgit From 605701700a8914ebaff283193756a6e57d7d575b Mon Sep 17 00:00:00 2001 From: Rainer Gerhards Date: Tue, 23 Feb 2010 14:10:38 +0100 Subject: doc update: added link to "rsyslog cookbook" --- doc/manual.html | 1 + 1 file changed, 1 insertion(+) (limited to 'doc') diff --git a/doc/manual.html b/doc/manual.html index f258686e..50dd5b0f 100644 --- a/doc/manual.html +++ b/doc/manual.html @@ -45,6 +45,7 @@ if you do not read the doc, but doing so will definitely improve your experience

backgrounder on generic syslog application design

description of rsyslog modules

+
the rsyslog "cookbook" - a set of configurations ready to use

We have some in-depth papers on
-- cgit From 8e027749b9f95a84619568c42d47c5dc78cf5b6a Mon Sep 17 00:00:00 2001 From: Rainer Gerhards Date: Wed, 24 Feb 2010 10:22:54 +0100 Subject: preparing for 4.6.0 release --- doc/manual.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'doc') diff --git a/doc/manual.html b/doc/manual.html index 50dd5b0f..0e121edf 100644 --- a/doc/manual.html +++ b/doc/manual.html @@ -19,7 +19,7 @@ rsyslog support available directly from the source!

Please visit the rsyslog sponsor's page to honor the project sponsors or become one yourself! We are very grateful for any help towards the project goals.
-
This documentation is for version 4.5.8 (v4-beta branch) of rsyslog. +
This documentation is for version 4.6.0 (v4-stable branch) of rsyslog. Visit the rsyslog status page to obtain current version information and project status.
If you like rsyslog, you might -- cgit From 0b84d47f7a244c25f63fadcec92d12ebfbe319a4 Mon Sep 17 00:00:00 2001 From: Rainer Gerhards Date: Thu, 4 Mar 2010 11:42:21 +0100 Subject: prepared 4.6.1 --- doc/manual.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'doc') diff --git a/doc/manual.html b/doc/manual.html index 0e121edf..0efe5076 100644 --- a/doc/manual.html +++ b/doc/manual.html @@ -19,7 +19,7 @@ rsyslog support available directly from the source!

Please visit the rsyslog sponsor's page to honor the project sponsors or become one yourself! We are very grateful for any help towards the project goals.
-
This documentation is for version 4.6.0 (v4-stable branch) of rsyslog. +
This documentation is for version 4.6.1 (v4-stable branch) of rsyslog. Visit the rsyslog status page to obtain current version information and project status.
If you like rsyslog, you might -- cgit From d97ad63e218112d7cd3a390854b2918407804976 Mon Sep 17 00:00:00 2001 From: Rainer Gerhards Date: Mon, 8 Mar 2010 17:56:11 +0100 Subject: added new property replacer option "date-rfc3164-buggyday" primarily to ease migration from syslog-ng. See property replacer doc for details. [backport from 5.5.3 because urgently needed by some] --- doc/property_replacer.html | 13 +++++++++++++ 1 file changed, 13 insertions(+) (limited to 'doc') diff --git a/doc/property_replacer.html b/doc/property_replacer.html index 7b604ea0..4d242a34 100644 --- a/doc/property_replacer.html +++ b/doc/property_replacer.html @@ -335,6 +335,19 @@ Especially useful for PIX. format as RFC 3164 date + +date-rfc3164-buggyday +similar to date-rfc3164, but emulates a common coding error: RFC 3164 demands +that a space is written for single-digit days. With this option, a zero is +written instead. This format seems to be used by syslog-ng and the +date-rfc3164-buggyday option can be used in migration scenarios where otherwise +lots of scripts would need to be adjusted. It is recommended not to use this +option when forwarding to remote hosts - they may treat the date as invalid +(especially when parsing strictly according to RFC 3164). +
This feature was introduced in rsyslog 4.6.2 and v4 versions above and +5.5.3 and all versions above. + + date-rfc3339 format as RFC 3339 date -- cgit From 7916735ba6890f67d49077975b0d635dc9931380 Mon Sep 17 00:00:00 2001 From: Rainer Gerhards Date: Tue, 9 Mar 2010 17:57:46 +0100 Subject: retain old $OMFileFlushOnTXEnd semantics required because due to bug the default was actually different than specified (or better said: spec was inconsistent in doc as well). --- doc/rsyslog_conf_global.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'doc') diff --git a/doc/rsyslog_conf_global.html b/doc/rsyslog_conf_global.html index 50d83a50..e7897f90 100644 --- a/doc/rsyslog_conf_global.html +++ b/doc/rsyslog_conf_global.html @@ -211,9 +211,9 @@ supported in order to be compliant to the upcoming new syslog RFC series. of the output file. The higher the number, the better the compression, but also the more CPU is required for zipping.
$OMFileIOBufferSize <size_nbr>, default 4k, size of the buffer used to writing output data. The larger the buffer, the potentially better performance is. The default of 4k is quite conservative, it is useful to go up to 64k, and 128K if you used gzip compression (then, even higher sizes may make sense)
-
$OMFileFlushOnTXEnd <[on/off]>, default on. Omfile has the +
$OMFileFlushOnTXEnd <[on/off]>, default ff. Omfile has the capability to -writes output using a buffered writer. Disk writes are only done when the buffer is +write output using a buffered writer. Disk writes are only done when the buffer is full. So if an error happens during that write, data is potentially lost. In cases where this is unacceptable, set $OMFileFlushOnTXEnd to on. Then, data is written at the end of each transaction (for pre-v5 this means after each log message) and the usual -- cgit From ba0f23182a55b26b2265d2138c707cbc7ddbb72e Mon Sep 17 00:00:00 2001 From: Rainer Gerhards Date: Wed, 17 Mar 2010 16:25:24 +0100 Subject: new feature: "." action type added to support writing files to relative pathes (this is primarily meant as a debug aid) --- doc/rsyslog_conf_actions.html | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) (limited to 'doc') diff --git a/doc/rsyslog_conf_actions.html b/doc/rsyslog_conf_actions.html index 8c4b9cfc..6020dd88 100644 --- a/doc/rsyslog_conf_actions.html +++ b/doc/rsyslog_conf_actions.html @@ -37,8 +37,15 @@ compared to the otherwise-equal config directives below:
*.=crit /var/log/critmsgs

Regular File
-
Typically messages are logged to real files. The file has to -be specified with full pathname, beginning with a slash "/''.
+
Typically messages are logged to real files. The file usually is +specified by full pathname, beginning with a slash "/". +Starting with version 4.6.2 and 5.4.1 (previous v5 version do NOT support this) +relative file names can also be specified. To do so, these must begin with a +dot. For example, use "./file-in-current-dir.log" to specify a file in the +current directory. Please note that rsyslogd usually changes its working +directory to the root, so relative file names must be tested with care (they +were introduced primarily as a debugging vehicle, but may have useful other applications +as well).

You may prefix each entry with the minus "-'' sign to omit syncing the -- cgit From d102aab886fcde914677146caf20bd68ca41bfff Mon Sep 17 00:00:00 2001 From: Rainer Gerhards Date: Thu, 25 Mar 2010 15:23:39 +0100 Subject: new feature: $OMFileAsyncWriting directive added it permits to specifiy if asynchronous writing should be done or not --- doc/rsyslog_conf_global.html | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'doc') diff --git a/doc/rsyslog_conf_global.html b/doc/rsyslog_conf_global.html index e7897f90..d5a27541 100644 --- a/doc/rsyslog_conf_global.html +++ b/doc/rsyslog_conf_global.html @@ -207,6 +207,14 @@ supported in order to be compliant to the upcoming new syslog RFC series.
$MaxOpenFiles

$ModDir

$ModLoad
+
$OMFileAsyncWriting [on/off], if turned on, the files will be written +in asynchronous mode via a separate thread. In that case, double buffers will be used so +that one buffer can be filled while the other buffer is being written. Note that in order +to enable $OMFileFlushInterval, $OMFileAsyncWriting must be set to "on". Otherwise, the flush +interval will be ignored. Also note that when $OMFileFlushOnTXEnd is "on" but +$OMFileAsyncWriting is off, output will only be written when the buffer is full. This may take +several hours, or even require a rsyslog shutdown. However, a buffer flush can be forced +in that case by sending rsyslogd a HUP signal.
$OMFileZipLevel 0..9 [default 0] - if greater 0, turns on gzip compression of the output file. The higher the number, the better the compression, but also the more CPU is required for zipping.
-- cgit From b6ce75cb6ce65a468f9551d98a641b407a4f2630 Mon Sep 17 00:00:00 2001 From: Rainer Gerhards Date: Fri, 26 Mar 2010 15:41:59 +0100 Subject: preparing for 4.6.2 --- doc/manual.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'doc') diff --git a/doc/manual.html b/doc/manual.html index 0efe5076..455a7116 100644 --- a/doc/manual.html +++ b/doc/manual.html @@ -19,7 +19,7 @@ rsyslog support available directly from the source!

Please visit the rsyslog sponsor's page to honor the project sponsors or become one yourself! We are very grateful for any help towards the project goals.
-
This documentation is for version 4.6.1 (v4-stable branch) of rsyslog. +
This documentation is for version 4.6.2 (v4-stable branch) of rsyslog. Visit the rsyslog status page to obtain current version information and project status.
If you like rsyslog, you might -- cgit