Log Consolidator and Alerter
Adiscon is proud to announce the release of MonitorWare Agent 3.1. The
new version is basically a maintenance release, but also contains some new
features and enhancements: Continue reading “2005-09-14 MonitorWare Agent 3.1 Released”
Build-IDs: Service 3.1.292, Client 3.1.889
New Minor Additions |
|
Article created 2003-02-24 by Rainer Gerhards.
Last Updated 2011-05-25 by Tom Bergfeld.
Starting with EventReporter 8.3 and MonitorWare Agent 4.3 two different event log monitor services are provided. They are called “Event Log Monitor” (V1) and “Event Log Monitor V2”. In short, the V2 version is recommended for Windows Vista (and above, e.g. Longhorn Server) while the other version is for previous releases of Windows (NT, 2000, 2003, XP). Please find more information about the different EventLogMonitors at Which Event Log Monitor to use.
There is also a guide How To setup EventLogMonitor V2 Service.
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 1: 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.
Note 2: If you want to generate reports (using Monilog) on the data via this service i.e. EventLogMonitor, then you have to press the “Configure for Monilog” button and make the settings as shown in the screen-shot.
Note 3: If you want to generate reports (using MonitorWare Console) on the data via this service i.e. EventLogMonitor, then you have to uncheck the “Use Legacy Format” option. This is recommended. If you don’t uncheck this option then meaningful reports aren’t generated (i.e. reports are not properly consolidated by MonitorWare Console).
5. Now you must differentiate between clients and central hub server. In clients use the “Forward ” RuleSet we have created in Step 2, select it as rule set to use. In central hub server select the “Database Logging” RuleSet we have created in Step 3. Leave all other settings in their default.
Clients:
Central hub server:
6. Finally, save the change and start MonitorWareAgent. This procedure completes the configuration of the syslog server.
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.
With step 5 the client machines configuration has finished. All the next steps are only concerned with the central hub server.
Article created 2003-04-30 by Rainer Gerhards.
Last Updated 2005-08-16 by Timm Herget.
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.
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:
![](/common/stepbystep/forwarding-nt-eventlogs-to-syslog-mwa12/forwar3.jpg")
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.
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.
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.
Article created 2003-04-30 by Rainer Gerhards.
Last Updated 2005-08-16 by Timm Herget.
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.
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.
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.
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.
Created 2005-08-02 by Timm Herget
What are the settings that I would have to make such that the log file is generated in a format that is acceptable to Monilog?
There are a few things that have to be set in order to generate a log file that would be read by Monilog for Reporting purposes
1. Event Log Monitor Setting
The following checkboxes should be checked for Event Log Monitor Service. This must be done by clicking the “Advanced Options” tab. The rest of the “base options” should be leaved at default settings:
Figure 1: Event Log Monitor Service Settings
2. Forward Via Syslog Settings
In Forward via Syslog Action, you would see a “Message Format” option. From the “Insert” menu entry select “Replace with Monilog Format“. Please Note: It is very important that you uncheck the “Add Syslog Source when forwarding to other Syslog servers” Option. Your settings should be like this:
Figure 2: Forward Via Syslog Action Settings
3. Syslog Listener Settings
Please note that the “Enable RFC 3164 Parsing” should be checked
Figure 3: Syslog Listener Service Settings
4. Write to File Action Settings
Please note that you should leave all settings at the default settings for “FileLogging Action”. If you changed anything in your default options, please adapt your settings to those who are shown on the following screenshot:
Figure 4: Write to File Action Settings
With the above mentioned settings, Monilog will successfully generate the report on the log file that has been generated.
Created 2005-06-23 by Hamid Ali Raja
The CPU monitor of MonitorWare Agent uses the Windows WMI System to query the CPU and memory related information from system. On Windows 2000, there is a known Windows Management Instrumentation (WMI) bug that reports continuously 98% of CPU usage. In this case you will need to install a Microsoft Hotfix to solve the issue.
You can get more details about this WMI bug and hotfix from the following link:
Created 2005-06-14 by Hamid Ali Raja
Last Updated 2006-04-27 by Timm Herget
How can I export my settings to a registry file?
To export your settings to a registry file, please do the steps described below.
Please note that you do NOT use the binary registryfile export-option!
Go to Computer menu and click Export Settings to Registry-file.
After step 1, you are shown a window as shown below to name and save your Registry file at your desired location. Please choose your file name and location where you want to save it.
If you have some zipping software installed, right click on the saved file and zip it, as shown below:
Send us the zipped file.
Note: You may be reluctant to send the registry file because of security reasons. We recommend you to review the contents of the registry file with notepad or any other text editor for security purposes.
Article created 2005-05-17 by Hamid Ali Raja.
In this scenario, a simple Syslog server will be created. No other services are configured. The Syslog server will operate as a standard Syslog server on the default port of 514/UDP. All incoming data will be written to a single text file.
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 will be already present when the service is 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 “Write Syslog Log File” in this example. The screen looks as follows:
Click”Next”. A new wizard page appears:
There,select file logging. Do not select any other options for this example. 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 “Write Syslog Log File” 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 “File Logging” action configured. We will review the settings just for your information. Click on “Filter Conditions”:
As you can see, none of the filter conditions are enabled. This means that the all information units (incoming messages) will be matched by these filter conditions. As such, the rules for the “File Logging” action will always be carried out.
Please note that this also means that all Syslog priorities and facilities will be written to the same file.
Now let us check the “File Logging” action itself. Please select it in the tree view:
As you can see, it has been created with the default parameters. Each day, a file will be created in the C:\temp directory and its base name will be MonitorWare. It will include all information items in the file.
If you would like to store it into a separate directory or change the file name, here is the place to do it. Important: please make sure the directory you specify exists! If it does not yet exist, please create it before you start the service. If the directory does not exist, the service is not able to store any files.
In our example, we would like to save it to “c:\logfiles” with a base name of “Syslog”. Therefore, we change these properties:
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 logging incoming messages to a text file.
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:
To check its parameters, select it:
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 “Write Syslog Log File” 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 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.
Application cannot dynamically read changed configurations. As such, it needs to be restarted after such changes. In our example, the service was not yet started, so we simply need to start it. If it’s already running, 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 example, stop and restart are grayed out because the service is not running.
After service restart, the new definitions are active and application is ready to accept and store incoming messages.
Even though application is now ready, it can only receive messages if some devices send them. Remember, Syslog is a protocol where the server is passively waiting for incoming messages. As long as no device sends message, the Syslog server will not log anything.
Since there are a large variety of devices, we unfortunately cannot provide device specific instructions. However, almost all devices need to be configured with their specific configuration tool. Typically, only two settings need to be made: one to activate Syslog messages at all and one with the Syslog server IP address or name.
For some devices, we have step-by-step guides. Please read “Sample Syslog Device Configurations” for further details.
Remember: the computer running application now acts as a Syslog server. As such, you need to find out its IP address or name and supply it to the device as the Syslog server. Please note that not all devices can operate with computer names. Use the IP address, if in doubt.
A major update to this article was done on 2005-05-04 by Rainer Gerhards.
A mass rollout in the scope of this topic is any case where the product is rolled out to more than 5 to 10 machines and this rollout is to be automatted. This is described first in this article. A special case may also be where remote offices shall receive exact same copies of the product (and configuration settings) but where some minimal operator intervention is acceptable. This is described in the second half of this article.
The common thing among mass rollouts is that the effort required to set up the files for unattended distribution of the configuration file and poduct executable is less than doing the tasks manually. For less than 5 systems, it is often more economical to repeat the configuration on each machine – but this depends on the number of rules and their complexity. Please note that you can also export and re-import configuration settings, so a hybrid solution may be the best when a lower number of machines is to be installed (normal interactive setup plus import of pre-created configuration settings).
Before considering a mass rollout, be sure to read “The MonitorWare Agent Service“. This covers necessary background information and most importantly the command line switches.
The basic idea behind a mass rollout is to create the intended configuration on a master (or baseline) system. This system holds the complete configuration that is later to be applied to all other systems. Once that is system is fully configured, the configuration will be transferred to all others.
The actual transfer is done with simple operating system tools. The complete configuration is stored in the the registry. Thus, it can be exported to a file. This can be done with the client. In the menu, select “Computer”, then select “Export Settings to Registry File”. A new dialog comes up where the file name can be specified. Once this is done, the specified file contains an exact snapshot of that machine’s configuration.
This snapshot can then be copied to all other machines and put into their registries with the help of regedit.exe.
An example batch file to install the product and configuration on the “other” servers might be:
copy \\server\share\mwagent.exe c:\some-local-dir copy \\server\share\libeay32.dll c:\some-local-dir copy \\server\share\ssleay32.dll c:\some-local-dir copy \\server\share\mwagent.pem c:\some-local-dir cd \some-local-dir mwagent –i regedit \\server\share\configParms.reg
The file “configParams.reg” would be the registry file that had been exported with the configuration client.
Of course, the batch file could also operate off a CD – a good example for DMZ systems which might not have Windows networking connectivity to a home server.
Please note that the above batch file fully installs the product – there is no need to run the setup program at all. All that is needed to distribute the service is the mwagent.exe and its two helper dlls, which are the core service. For a locked-down environment, this also means there is no need to allow incoming connections over Windows RPC or NETBIOS for an engine only install.
Please also note that, in the example above, “c:\some-local-dir” actually is the directory where the product is being installed. The “mwagent -i” does not copy any files – it assumes they are already at their final location. All “mwagent -i” does is to create the necessary entries in the system registry so the MonitorWare Agent is a registered system service.
You can use engine-only install also if you would like to distribute a standadized installation to subsidary administrators. Here, the goal is not have everything done fully automatic, but to ensure that each local administrator can set up a consistent environment with minimal effort.
You can use the following procedure to do this:
Important: The directory created in step 6 actually is the program directory. Do not delete this directory or the files contained in it once you are finished. If you would do, this would disable the product (no program files would be left on the system).
If you need to update an engine-only installation, you will probably only upgrade the master installation and then distribute the new exe files and configuration in the same way you distributed the original version. Please note that it is not necessary to uninstall the application first for an upgrade – at least not as long as the local install directory remains the same. It is, however, vital to stop the service, as otherwise the files can not be overwritten.