Changelog for 6.2.0 (v6-stable)
ChangeLog (from 6.1.12 to 6.2.0):
- bugfix (kind of): removed numerical part from pri-text see v6 compatibility document for reasons
- bugfix: race condition when extracting program name, APPNAME, structured data and PROCID (RFC5424 fields) could lead to invalid characters e.g. in dynamic file names or during forwarding (general malfunction of these fields in templates, mostly under heavy load)
- bugfix: imuxsock did no longer ignore message-provided timestamp, if so configured (the *default*). Lead to no longer sub-second timestamps.
closes: http://bugzilla.adiscon.com/show_bug.cgi?id=281 - bugfix: omfile returns fatal error code for things that go really wrong previously, RS_RET_RESUME was returned, which lead to a loop inside the rule engine as omfile could not really recover.
- bugfix: rsyslogd -v always said 64 atomics were not present
thanks to mono_matsuko for the patch - bugfix: potential abort after reading invalid X.509 certificate closes:
http://bugzilla.adiscon.com/show_bug.cgi?id=290
Thanks to Tomas Heinrich for the patch - $Begin, $End, $StrictScoping directives have been removed as v6.4 will provide the same functionality in a far better way. So we do not want to clutter the code.
rsyslog 6.2.0 (v6-stable)
Download file name: rsyslog 6.2.0 (stable)
rsyslog 6.2.0 (stable)
md5sum: 03e237abaa5d47f92c6e655f92f22532
Author: Rainer Gerhards (rgerhards@adiscon.com)
Version: 6.2.0 File size: 2.41 MB
Using RSyslog Windows Agent as a syslog relay
This time we want to use the RSyslog Windows Agent as a syslog relay. The article itself will be described in two larger steps. Both steps contain some substeps which will be shown in detail in one of the smaller articles. We assume, that no basic configuration is currently available.
This configuration can be used to attach several sites to a larger log network. Imagine you have a central log server at your company in your central facility. You have some branch offices around the country and their log messages should be stored in the central location as well. Now it wouldn’t be very clever to have every computer or device at these sites forward their log messages directly. It would be better to have a central machine at the site, that works as a relay. It will receive all the log messages via syslog and then again forward the messages to the central server. Cascading setups like this ensure a part of the reliability, stability and security of your infrastructure, by keeping the connection count low and lowering the amount of machines using the network.
Basically, the configuration of RSyslog Windows Agent consists of 3 parts.
1. A so-called service which generates the log data to be processed by, for example, a syslog server.
2. Rules with Filters. Filters give you the power to decide which log messages are important enough to be kept or not.
3. The action that has to be taken. In our case, forwarding the syslog messages.
Step 1: Setting up the ruleset and action.
Usually we start by creating the ruleset, rule and action. The reason lies in the configuration structure. So we will first create the mentioned items. In the end, we will have a basic rule with no particular filter and a forward via syslog action. That means, that all messages will be forwarded to a central host.
Step 2: Setting up the service.
Now we will set up the service. As we already know, we want to create a syslog server. Therefore we need the syslog server service. It will create a listener, that is listening to syslog traffic on a specific port. You can choose the protocol, like TCP or UDP as well.
That’s it, you are already finished. Easy wasn’t it? Now you should be able to receive syslog messages from different devices and forward them from only one machine to your central syslog server.
Forward Windows Eventlogs with RSyslog Windows Agent
This article will describe, how to use the RSyslog Windows Agent to forward the local Windows EventLog messages. This article will show the different steps. For this we take you to several smaller guides, that show you, how to setup each part. We assume, that no basic configuration is currently available.
A configuration like this is needed very often and basically on any Windows machine that should forward it’s logs. Therefore, this reflects the default configuration after installing the RSyslog Windows Agent. It can be used on machines in your local network or on a site to forward from the single machines to a central relay server, which then forwards all messages to your company’s central log server.
Basically, the configuration of RSyslog Windows Agent consists of 3 parts.
1. A so-called service which generates the log data to be processed by, for example, polling the Windows EventLog.
2. Rules with Filters. Filters give you the power to decide which log messages are important enough to be kept or not.
3. The action that has to be taken. In our case, forwarding the syslog messages.
Step 1: Setting up the ruleset and action.
Usually we start by creating the ruleset, rule and action. The reason lies in the configuration structure. So we will first create the mentioned items. In the end, we will have a basic rule with no particular filter and a forward via syslog action. That means, that all messages will be forwarded to a central host.
Step 2: Setting up the service.
Now we will set up the service. There is one thing to mention first. You need to know choose one of the latter links according to your operating system. This is important, or the setup might not work properly. We have 2 different versions of the EventLog Monitor. Here is a small list in which you can see, which service fits which operating systems.
1. EventLog Monitor: 2000, XP, 2003
2. EventLog Monitor V2: Vista, 2008, 7, 10
This is important. EventLog Monitor V2 will NOT work on the older operating systems. In contrary, the older EventLog Monitor will work on the newer systems, but might not work correctly, so it is advised to used the optimized EventLog Monitor V2. This is due to the massive changes that Microsoft introduced to the EventLog system with Vista.
That’s it, you are already finished. Easy wasn’t it? Now you should receive your EventLog messages on your central syslog server.
How To setup EventLogMonitor V2 Service
Note: This guide explains how to set up the EventLog Monitor Service for Windows Vista. These steps are not applicable if you are using Windows XP.
1. First, right click on “Services”, then select “Add Service” and then “Event Log Monitor V2”:
Again, you can use either the default name or any one you like. We will use the default name in this sample. Leave the “Use default settings” selected and press “Next”.
2. As we have used the default, the wizard will immediately proceed with step 3, the confirmation page. Press “Finish” to create the service. The wizard completes and returns to the configuration client.
3. Now, you will see the newly created service beneath the “Services” as part of the tree view. To check its parameters, select it:
As you can see, the service has been created with the default parameters.
Note: The “Default RuleSet” has been automatically assigned as the rule set to use. By default, the wizard will always assign the first rule set visible in the tree view to new services.
4. Finally we, bind a ruleset to this service. If you already have a ruleset, simply choose one. If not, then you will have to create one, or insert the actions you want to take in the default ruleset.
Remember, this is only an example. You can do it in any way you want.
5. The last step is to save the changes and start the service. This procedure completes the configuration of the syslog server.
The NT Service cannot dynamically read changed configurations. As such, it needs to be restarted after such changes. In our sample, the service was not yet started, so we simply need to start it. If it already runs, you need to restart it.
That’s it. This is how you create a simple Event Log Monitor V2 for Vista.
How To setup EventLogMonitor V1 Service
Attention: This Guide is for Windows XP or 2003 if you use Vista or Win7 then use EventLogMonitor V2.
1. First, right click on “Services”, then select “Add Service” and then “Event Log Monitor”:
2. Once you have done so, a new wizard starts.
If the following Popup appears, please select “Create Service”:
Again, you can use either the default name or any one you like. We will use “My Event Log Monitor” in this sample. Leave the “Use default settings” selected and press “Next”.
3. As we have used the default, the wizard will immediately proceed with step 3, the confirmation page. Press “Finish” to create the service. The wizard completes and returns to the configuration client.
4. Now, you will see the newly created service beneath the “Services” part of the tree view. To check its parameters, select it:
As you can see, the service has been created with the default parameters.
Note: The “Default RuleSet” has been automatically assigned as the rule set to use. By default, the wizard will always assign the first rule set visible in the tree view to new services. In our case, this is not correct and will be corrected soon.
5. Finally, save the change and start RSyslog Windows Agent.
That was it.
How To create a Syslog Server Service
Create a Syslog Server Service
Now we need to define a Syslog server service. A Syslog server is also sometimes called a “Syslog daemon”, “Syslogd” or “Syslog listener”. It is the process that receives incoming messages.
To define it, right click on “Services”, then select “Add Service” and the “Syslog Server”:
Once you have done so, a new wizard starts:
Again, you can use either the default name or any one you like. We will use “My Syslog Server” in this example. Leave the “Use default settings” selected and press “Next”:
As we have used the default, the wizard will immediately proceed with step 3, the confirmation page. Press “Finish” to create the service. The wizard completes and returns to the configuration client. There, you will see the newly created service beneath the “Services” part of the tree view:
Attention: All clients must use the same protocol. In my example I use TCP.
As you can see, the service has been created with the default parameters. As such, it operates as a RFC compliant standard Syslog server.
Please note that the “RuleSet 1” has been automatically assigned as the rule set to use. This is the case because i already created it and it is the only rule set. By default, the wizard will always assign the first rule set visible in the tree view to new services. If another one is to be used, you need to change it to the correct one here in the service definition.
Also, note that the wizard uses the default properties from the “Service Defaults”. Obviously, if these are changed, the default properties for new services will differ.
This procedure completes the configuration of the Syslog server.
At least Save and restart the service.
How To setup File Monitor Service
How To setup File Monitor Service
Article created 2011-12-29 by Florian Riedl.
1. First, right click on “Services”, then select “Add Service” and the “File Monitor”.
Once you have done so, a new wizard starts.
2. Again, you can use either the default name or any one you like. We will use “My FileMonitor” in this sample. Leave the “Use default settings” selected and press “Next”.
3. As we have used the default, the wizard will immediately proceed with step 3, the confirmation page. Press “Finish” to create the service. The wizard completes and returns to the configuration client.
4. Now, you will see the newly created service beneath the “Services” part of the tree view. To check its parameters, select it:
As you can see, the service has been created with the default parameters.
5. To make this Service work, we need to select a text file as source. To achieve this, click on the “Browse” button as you can see it marked in the screen above. A browsing window will open up. Move through your Files and choose one that you would like to monitor. For this example I chose a text file created by MonitorWare Agent.
6. Now we still need to set a ruleset for this service to work with. Since we have no configured ruleset available at the moment, simply use the Default Ruleset, if it’s not being used automatically.
7. Last, save the changes and then restart the application. This procedure completes the configuration of the FileMonitor Service.
The Application cannot dynamically read changed configurations. As such, it needs to be restarted after such changes.
How To setup the Forward via Syslog Action
This Guide is for the RSyslog Windows Agent.
1. First we define a new rule set. Right-click “Rules”. A pop up menu will appear. Select “Add Rule Set” from this menu. On screen, it looks as follows:
2. Then, a wizard starts. Change the name of the rule to whatever name you like. We will use “Forward syslog” in this example. The screen looks as follow:
Click “Next” to go on with the next step.
3. Select only Forward via Syslog. Do not select any other options for this sample. Also, leave the “Create a Rule for each of the following actions” setting selected. Click “Next”. You will see a confirmation page. Click “Finish” to create the rule set.
4. As you can see, the new Rule Set “Forward syslog” is present. Please expand it in the tree view until the action level of the “Forward syslog” Rule and select the “Forward syslog” action to configure.
5. Configure the “Forward via Syslog” Action
Type the IP or the Hostname of your syslog server into the Syslog Server field in the form. Then Change the protocol to “TCP (octet-count based framing”. We use TCP that we will have no traffic lost. And edit the Port to 10514. Attention RSyslog Windows Agent and rsyslog must use the same port and the same protocol.
6. Finally, make sure you press the “Save” button – otherwise your changes will not be applied. Then start the service and you are done.
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