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