Forwarding NT Event Logs to a Syslog Server

Step-By-Step Guides

Article created 2003-04-30 by Rainer Gerhards.
Last Updated 2005-08-16 by Timm Herget.

Forwarding NT Event Logs to a Syslog Server

In this scenario, an event log monitor is used to forward all events written to the NT Event Log to a syslog server. This can either be another instance of MonitorWare or any standard syslog server, for example on a UNIX platform. The data will be forwarded in the EventReporter compatible format, as the processes running on the syslog server require that format (this is just an assumption).

This is a scenario often used together with UNIX based management solutions. The event log monitor is used here to forward events into a central repository, where it will be analyzed using pre-existing procedures.

Please note that if the data is to be forwarded to another instance of a MonitorWare Agent, we highly recommend using the SETP protocol instead of syslog – but this is beyond the scope of this scenario here.

Step 1 – Defining a Rule Set for Syslog Forwarding

The rule set specifies what action to carry out. You might be tempted to define the service first, but starting with the rule set makes things easier as it already is present when the service will be defined later and needs to be bound to a rule set.

To 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:

Then, a wizard starts. Change the name of the rule set to whatever name you like. We will use “Forward To Syslog Server” in this example. The screen looks as follows:

Click “Next”. A new wizard page appears:

There, select “Forward 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”.

This is just a confirmation page. Click “Finish” to create the rule set.

The wizard closes and the client shows a newly created rule set.

As you can see, the “Forward To Syslog Server” rule set is now present. Please expand it in the tree view until you have the following screen contents:

As you can see, we have a “Forward Syslog” action configured. We will review the settings just for your information. Click on “Filter Conditions”:

As you can see, no filter conditions are selected. This means that the all information units (the event log information) will be matched by these filter conditions. As such, the rules for the “Forward Syslog” action will always be carried out.

Now let us check the “Forward Syslog” action itself. Please select it in the tree view:

As you can see, some useful defaults are already there. It forwards syslog messages via the standard UDP protocol to the standard port of 514. These values are specified by the syslog standard and most syslog servers will expect them. Only change them if you definitely know that the syslog server is configured to use other values. If in doubt, use the default ones.

However, there are also some things that need to be completed and changed for this scenario.

Obviously, the syslog server to receive the message needs to be specified. You can use either a system name or IP address. In our sample, we will use the IP address, because this is faster and more reliable as it does not depend on DNS name resolution. Our target syslog server is on address 10.0.0.1.

Next, we will uncheck the “Add Syslog Source when forwarding…” options. This option is useful when messages are to be forwarded to the WinSyslog Interactive Syslog Server for instant review. If forwarded to a “real” syslog server, it typically is not useful and might influence the receiving syslog server’s capability to correctly check the message contents.

The “Use XML to Report” option is left unchecked because in this scenario there are pre-existing scripts on the syslog server that expect EventReporter legacy format. The XML option is not compatible with that format.

After the changes, the dialog looks as follows:

After doing so, you will notice the yellow text on top of the window. It tells you that the configuration changes have not yet been applied. To do so, press “save”.

Now you have a workable rule set for forwarding event monitor data to the syslog server.

Step 2 – Create an Event Log Monitor Service

Now we need to define an “event log monitor” service. It is the process that monitors the Windows event log for new entries and creates information units as soon as a new entry is found. These information units are then passed to the rule set which in turn forwards them to the syslog server configured in step 1.

To define the event log monitor, right click on “Services”, then select “Add Service” and the “Event Log Monitor”:

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 Event Log Monitor” in this sample. 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:

To check its parameters, select it:

As you can see, the service has been created with the default parameters. As such, it monitors all event logs that are present on the system. It also has some protection against overruns of the receiving system or intermediary routers. It monitors the event log in a 60 second interval (sleep time of 60.000 milliseconds), which is the recommended value for typical installations.

Please note that the “Forward To Syslog Server” rule set has been automatically assigned as the rule set to use. This is the case because we 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 that is not the intended rule set, you need to change it to the correct one here in the service definition.

Also, please 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.

There is one change we need to make to the service properties: that is the “Use Legacy Format” option. As specified in the scenario, some pre-existing scripts at the syslog server expect the EventReporter legacy format. As such, we need to check that option:

Finally, we review the log specific advanced properties. As a sample, we will go over the application log advanced properties. To do so, click the “Advanced” button:

Most importantly, we can select the syslog facility that is to be used for the generated information units here. In our sample, we leave it as local. We also leave the “Report Truncated Log” option checked. This option will generate a warning message if the respective Windows log is truncated, for example by operator request. If that happens during day-to-day operations in you environment, you might want to uncheck it.

Click OK to return to the main property sheet.

This procedure completes the configuration of the event log monitor.

Step 3 – (Re-)Start the MonitorWare Agent Service

MonitorWare Agent 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.

Service control can be done with both the respective operating system capabilities (like service manager MMC) or with the configuration client. These are shown in the red surrounded area in the following screen shot:

The buttons resemble Windows service manager – start, stop and restart. In this sample, stop and restart are grayed out because the service is not running.

After service restarts, the new definitions are active and MonitorWare Agent will forward all events from the Windows event log to the configured syslog server. Please note that on the first run, all already existing events will be forwarded. Therefore, this might take a little while. On all successive service start, only new events will be forwarded.

Forwarding NT Event Logs to a Syslog Server

Step-By-Step Guides

Article created 2003-04-30 by Rainer Gerhards.
Last Updated 2005-08-16 by Timm Herget.

Forwarding NT Event Logs to a Syslog Server

Step 1 – Defining a Rule Set for Syslog Forwarding

To 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:

Then, a wizard starts. Change the name of the rule set to whatever name you like. We will use “Forward To Syslog Server” in this example. The screen looks as follows:

Click “Next”. A new wizard page appears:

There, select “Forward 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”.

This is just a confirmation page. Click “Finish” to create the rule set.

The wizard closes and the client shows a newly created rule set.

As you can see, the “Forward To Syslog Server” rule set is now present. Please expand it in the tree view until you have the following screen contents:

As you can see, we have a “Forward Syslog” action configured. We will review the settings just for your information. Click on “Filter Conditions”:

Now let us check the “Forward Syslog” action itself. Please select it in the tree view:

However, there are also some things that need to be completed and changed for this scenario.

After the changes, the dialog looks as follows:

After doing so, you will notice the yellow text on top of the window. It tells you that the configuration changes have not yet been applied. To do so, press “save”.

Now you have a workable rule set for forwarding event monitor data to the syslog server.

Step 2 – Create an Event Log Monitor Service

To define the event log monitor, right click on “Services”, then select “Add Service” and the “Event Log Monitor”:

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 Event Log Monitor” in this sample. Leave the “Use default settings” selected and press “Next”:

To check its parameters, select it:

Also, please 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.

Finally, we review the log specific advanced properties. As a sample, we will go over the application log advanced properties. To do so, click the “Advanced” button:

Click OK to return to the main property sheet.

This procedure completes the configuration of the event log monitor.

Step 3 – (Re-)Start the MonitorWare Agent Service

The buttons resemble Windows service manager – start, stop and restart. In this sample, stop and restart are grayed out because the service is not running.

How can I make Event ID part of the actual Syslog message while forwarding to a Syslog Server?

Created 2004-06-24 by Tamsila-Q-Siddique.

We are using MonitorWare Agent / EventReporter to forward Windows Event logs to a Syslog Server. The resulting syslog message doesn’t have the Event IDs in them. How can we make Event ID part of the actual Syslog message?

One of the proposed solution would be to forward the Event Log messages using SETP Server. The resulting message would have the Event IDs in them. Click here to know the difference between SETP and Syslog!

But there are other ways to include the Event ID even without using SETP (which is obviously not an option if you would like to send to a non-Adiscon backend). So you can do one of the following:

Use XML Format – This is the best recommended option. With XML format, you get everything about this event and you get it in a well-structured way. It includes all of the properties described in our Event Properties reference. To enable XML format, simply check “Use XML to Report” in the “Forward Syslog” Action.
Use Custom Format – In the “Forward Syslog” action, you can specify your own custom format in the “Message Format” text box. By default it is set to %msg%, but you can include whatever you like. Use the “Insert” link to do this (or simply type it)! Be sure to read the Property Replacer” documentation to see the full power. This option is a good one, especially if you intend to parse the data… because *you* can exactly specify what you would like to see.
Use MoniLog Format – This is our former legacy format. It includes a bunch of useful information, but it has a number of anomalies, which might hit you in few cases when parsing. We do not recommend it, but if you would like to use it, you can select the “Insert” link in the “Forward Syslog” action properties. Then, select “Replace with MoniLog Format”. It will generate a custom format of the type given below. Again, we do not recommend this, but it is a way.## %severity% %timereported:::uxTimeStamp%: %source%/%sourceproc% (%id%) – “%msg%” ##
Change Event Log Monitor Settings – You could also change the Event Log Monitor itself to generate the legacy format. Then, you do not need to change the “Forward Syslog” action’s settings. The big drawback is that now the Event Log Monitor does emit an old format, which is not meant to be processed by any other MonitorWare product. If you just use the product as a back-end for your own front-end, this is not an issue. Anyhow, we still recommend to go for approach #3 instead of this. If you absolutely want to do it this way, this is how it is done:
Go to the Event Log Monitor properties. Click on the “Advanced Options” button. Check the “Use Legacy Format” checkbox. This will enable some other checkboxes. Review the options to see which of these you want.

We have provided the options at hand. We *strongly* recommend to go for either option 1 or 2. If you choose option 3 or 4, you can receive a parsing error from time to time. However this has been solved after introducing the newer formats.

As a general hint, you may want to take into account that Windows Event Log messages can become rather lenghty. They often go over the syslog RFC size of 1024 bytes. If you run a non-Adiscon Syslog Server, you need to ensure it can receive such large messages, because otherwise some information might be missing (with option 2, you can customize what you would like to be missing in such cases – by limiting the size of %msg% via the property replacer).

Forwarding IIS Logs to a central File

Created 2004-04-02 by Timm Herget and Rainer Gerhards.

I would like to centralize IIS log files to a central log server. The files on that central server should be in the exact same format they are on the IIS machines.

This can be done with MonitorWare Agent 2.0 and above. Let’s look into the theory first: If you would like to forward IIS log files AND have them in the same format at the receiving machine, you need to make some special settings.

First of all, please note that the file monitor, when set to “W3C log files”, is optimized to extract the properties from each log line, not to forward the log literally. If you would like to forward them literally, you need to make sure that the format is set to “Standard”, which will disable all W3C-log specific handling (that would otherwise disturb the result). The syslog tag is not needed here, so it should be totally removed.

We must ensure that the send syslog action does not alter this message content. As such, we must make sure that the “Add Syslog Source when Forwarding” setting is NOT activated.

Unfortunately, that will not eliminate the tag as such from the syslog message, but we can handle this with the property replacer. As of RFC 3164, the syslog tag will be present in the so-generated message. In fact, the message will be “: <ORIGINAL line W3C>” with <ORIGINAL line W3C> literally being the line taken from the W3C log. Effectively, we end up with two extra characters (“: “) at the beginning of the line. Thankfully, we can eliminate these with the property replacer (it is capable of providing substrings of event properties). The message is in the “msg” property. So “%msg:3%” is everything from the third character position up until the end of the line (end position is not specified and so “end of line” is the default). To use the property replacer, we must just the “Write to File” action with “Custom” file format. Then, we can enter an arbriatary string that shall be written to the file. In our case, we use “%msg:3%%$CRLF%”: this instructs the write to file action to first write the original file line and then a Windows newline sequence. The later is needed because it was stripped out by the file monitor.

This looks in the dialogs as follows:

1. Sender : Forward Via Syslog Settings

The “Add Syslog Source when …”-Checkbox MUST be unchecked.

Figure 1: Forward Syslog Action Settings

2. Sender : File Monitor Service Settings

Please note that the “Syslog Tag Value” Field MUST be empty (not even a space in it).

Figure 2: File Monitor Service Settings

3. Recipient: Syslog Listener Settings

Please note that the “Enable RFC 3164 Parsing” MUST be checked

Figure 3: Syslog Listener Service Settings

4. Recipient: Write to File Action Settings

The “File Path Name” Directory must be available, MonitorWare Agent will not create it if its not present.

The “File Format” MUST be set to “Custom”. The following custom line format MUST be used:

%msg:3%%$CRLF%

Figure 4: Write to File Action Settings

With the above settings the recipient MonitorWare Agent will successfully generate exact the same logfiles as the original ones are.

Sample Configurations

We have created some registry files for both the sender and the recipient server. If you download them, simply import them into the registry on the machine in question (if you system is a default-install, double-clicking the file is sufficient to do this). Be sure that the MonitorWare Agent client is closed while you do this. Please note that the sample configurations MUST be customized in order to make them work for you.

Sample configuration for MonitorWare Agent 2.0

Please note: samples may not work with versions other than the one specified in the download link!

Configurations for Forwarding the Events

Created 2003-04-04 by Wajih-ur-Rehman.

I have MonitorWare Agents running on various Windows Machines/Servers. I want to forward all the Windows Event Log messages to the central MonitorWare Agent. What configurations should i make?

For all the Window machines, which are forwarding the data to the central server, following should be the configurations for MonitorWare Agents running on them:

Right click on “Services” node and add “Event Log Monitor Service”. A new node will be added under the Services node. Click on this newly added node and change the settings according to your requirements.
When you install MonitorWare Agent, it creates one RuleSet automatically. Right click on it, go to Rules and add a new Rule. You will see a new Rule under the Rule Set.
When you expand this newly created Rule, you will see two nodes under it. One is “Filter Condition” (by default, “No Filter” is selected.) and the other is “Actions”.
Right click on Actions, and add “Send SETP” action. (You can also send via Syslog but SETP is recommended)
You will see a new node under the newly created node. Click on it and set the settings. Note that if you are interested in only specific events to be sent to the central server, you can define a Filter condition as well. With the current settings (no filter) all the events will be sent to the central server.
Go back to the Service that you created in Step 1 and make sure that the RuleSet under which you have defined your own Rule in step 2 is attached to this service. In other words, if you go to the properties of Event Log Monitor Service that you created in step 1, you will see a combo box at the bottom “Rule Set to use”. Make sure that the The Rule Set under which you have defined your own rule in step 2 is selected over there.

1V0-601 exam   ,
350-029 Study Guides   ,
AWS-SYSOPS exam   ,
EX300 exam   ,
70-487 test   ,
350-080 certification   ,
1Z0-144 pdf   ,
MB2-704 Study Guides   ,
HP0-S42 certification   ,
1Z0-061 pdf   ,
MB5-705 test   ,
70-488 dumps ,
VCP550 dumps ,
400-051 certification ,
ITILFND exam   ,
70-534 exam   ,
400-051 pdf   ,
70-486 exam   ,
300-135 certification   ,
300-206 dumps   ,
HP0-S42 dumps   ,
JN0-102 Exam   ,
70-463 dumps   ,
c2010-657 certification   ,
350-060 pdf ,
300-209 exam   ,
000-080 exam   ,
1V0-601 dumps   ,
9L0-012 test   ,
000-017 dumps   ,
70-346 exam ,
300-101 dumps   ,
1z0-808 Exam   ,
210-060 test ,
ICGB test ,
070-461 test   ,
300-135 exam   ,
MB6-703 pdf   ,
3002 test   ,
210-060 exam   ,
70-462 exam   ,
SY0-401 test   ,
70-534 exam ,
1Y0-201 pdf ,
N10-006 certification   ,
70-347 exam   ,
70-413 exam ,
AWS-SYSOPS test   ,
JK0-022 exam   ,