MonitorWare Agent 14.4 Released

Release Date: 2023-06-21

Build-IDs: Service 14.4.0.556, Client 14.4.0.1645

Bugfixes

    • Syslog Action: Fixed a very rare case where an Action could try to open **TCP connections** to the same target **multiple times simultaneously**. The handling has been hardened to avoid concurrent connection establishment retries for the same Action.
    • Syslog Action: Fixed error handling when **the** connection fails and Syslog Caching is enabled. If a syslog backup server is enabled, the action will now retry the primary server correctly again after syslog caching has been activated.
    • EventLog Monitor V2: Fixed an issue in XML-Stream Processing that could cause failure in processing an EventLog Message.
    • Send Email: Fixed an issue handling server multiline replies. Some mailservers return multiline replies when additional protocol data is to be returned. In some cases, these additional protocol data **were** not detected correctly, causing the Action to fail.
    • LogRotate: Corrected error reporting when the feature is not available **due to** licensing.
    • Network Core: **Enhanced stability** during closing connections.

You can download Free Trial Version of MonitorWare Agent.

MonitorWare Agent 12.0 Released (Build-IDs: Service 12.0.0.515, Client 12.0.0.1590)

Release Date: 2018-04-11

Build-IDs: Service 12.0.0.515, Client 12.0.0.1590

Features

  • File Monitor: Added new options “Process rest of file as one message” and Read  Filebuffer size for better regex message separator handling.
  • Syslog Action: Added support for multiple syslog servers (Load balancing)
  • Syslog Action: Backup Syslog Server is now tried on connect as well. Before, the backup server was only used when an existing connection to the primary server interrupted.
  • SNMP Trap Receiver: Added new option to include SNMP OID Description in the output message.
  • Core Engine: Enhanced debug output for network errors.
  • LogNorm Action: Updated action to support liblognorm v2 rulebases.

Bugfixes

  • Property Engine: Fixed daylight handling when using RFC3339 string conversion. Daylight was incorrectly always applied.
  • Property Engine: Fixed dynamic properties conversion when using xml output. This bug caused some properties to be missing when sending them by SETP protocol or using Syslog Cache mode.
  • Configuration reload: Fixed missing SNMP Mibtree after configuration reload.

You can download Free Trial Version of MonitorWare Agent.

MonitorWare Agent 11.2 Released (Build-IDs: Service 11.2.0.502, Client 11.2.0.1580)

MonitorWare Agent 11.2 Released

Build-IDs: Service 11.2.0.502, Client 11.2.0.1580

Features

  • Syslog Action: Added support to overwrite Syslog Priority/Facility
  • SNMP Trap Receiver: Added support to print OCTET STRINGS with format hints. Format hints are now properly used using internal NET-SNMP functions. Support for encoding detection does not work for those SNMP Variables.
  • File Action: Added option to control the Filehandle timeout when using dynamic filenames.
  • Property Engine: Added two new property replacer options “toipv4address” and “toipv6address” to resolve a property into a valid IPv4 or IPv6 Address.
  • Filter Engine: Implemented a new regular expressions compare operation.
    More details on how to use REGEX can be found in the new documentation.
  • Configuration Reload: Added new options to add a random delay between configuration checks. The delay is limited to 60 seconds as it will also delay the service control manager communication.

Bugfixes

  • SNMP Monitor: Fixed internal crash when using multiple SNMP Monitor Services.
  • Syslog Action: Fixed bug in Syslog Cache processing when saved messages were larger than 4096 bytes.
  • File Action: Fixed closing filehandles on very busy systems.
  • Filter Engine: Fixed Extended IP Filtering when using lower or greater compare operation.
  • Normalize Action: Removed incorrect NULL Byte at the end of the INPUT String.
  • File Configuration: Fixed reading Filter values containing backslashes.
    They weren’t removed properly in filter values.

You can download Free Trial Version of MonitorWare Agent.

MonitorWare Agent 10.2 Released (Build-IDs: Service 10.2.466, Client 10.2.0.1559)

MonitorWare Agent 10.2 Released

Build-IDs: Service 10.2.466, Client 10.2.0.1559

Features

  • Components:
    • Updated NET-SNMP 5.6.2.1 and OpenSSL 1.0.2e.
  • Engine:
    • Enabled support to parse MIBs with labels that contain underscores.
    • When using TLS Mode x509/Name, permitted peers will also checked against the certificate Subject Alternative Name (SAN) now.
  • DB Monitor:
    • Added option “Write LastDBIndex at frequent intervals” to support saving the LastDBIndex while processing data records. By default the LastIDIndex is only written after all database records have been processed. LastDBIndex can now be a 64Bit number (Was limited to 32Bit before).
  • EventLog Monitor V2:
    • Added new Option “Wait time after action failure” which specifies the wait time after an action error occurred. Without the wait time, the subscription would immediately hit again. It is most likely that the action failure was caused by network problems, so a wait time of (default value) 15 seconds is a reasonable default.
  • File Monitor:
    • Added regular expressions support for Message Separators. Also added Options to prepend or append message separators to the message.  When using regex message separators, it might be necessary to include the message separator into the message.
  • Syslog Action:
    • Added wait time doubling option for the Diskqueue feature. When enabled, the configured wait time will be doubled until the doubling limit is reached.
    • Added random wait time delay option for the Diskqueue feature. When enabled, a random wait time (up to the configured maximum) will be added to the configured wait time.
    • Added Overrun prevention delay option for the Diskqueue feature. When enabled, the action will sleep for the configured delay between each syslog message.
  • Services TestMode:
    • Added a testmode for Services, currently EventLog Monitor V1 & V2 and File Monitor are supported. When enabling the testmode for a certain service, it will process it’s Events/Files over and over again. So only use this setting for testing purpose.
  • File Based Configuration:
    • Added support for file includes. The feature can be enabled by setting one or both options in the Client Options called “Create individual configuration files for Services” and “Create individual configuration files for RuleSets”. When enabled, the configuration client will split Services and/or Rulesets into separated files. The main configuration file will include these files by a pattern. The Service itself is able to read includes within includes up to a depth level to 10. When using custom (hand written) configuration with includes, the configuration client will only be able to read them. However the client will not be able to maintain (Save) the custom configuration structure.
  • Command line:
    • Added handler for CTRL+C when running the Service in console mode

Bugfixes

  • EventLog Monitor V2:
    • When using the subscription method (Default), Events could get lost when an action failed to process. Action error handling has been corrected now and works similar like in EventLog Monitor V1.
  • DB Monitor:
    • Fixed loading/saving LastDBIndex value when Service runs in fileconfig mode.
  • Syslog Server:
    • Fixed a problem receiving RFC3195RAW messages.
    • Fixed message timeout handling when no message separator was enabled in Syslog TCP mode.
  • File Action:
    • When using Custom Format, a trailing NULL Byte was written into the file. This was considered a bug, so the NULL Byte is not written anymore.
  • Syslog Action:
    • Fixed an issue when diskqueue files were corrupt. Now corrupted entries are skipped properly.
    • In some cases when the Action was in diskqueue mode, it could happen that the internal retry failed. Cached syslog messages wouldn’t be sent until the service restart.
  • SSL/TLS:
    • Actions with support for SSL/TLS (like Send Syslog Action) could fail to send messages if the recipient closed the connection during meantime. The handling of closed connections has been hardened now when TLS/SSL is enabled.
  • Command line:
    • Fixed handling when using more than one command line option
  • File Based Configuration:
    • Fixed a bug reading general options from File configuration.
    • Fixed an issue reading and writing into correct data directories when using custom locations.
    • Fixed an issue detecting if data state files need to be reloaded.
    • Fixed problem reading of Rule and ActionCount properly introduced due changes in the configuration client of build 456.
    • Better error handling when configfile is missing or not accessible.
  • Configuration client:
    • When deleting an item in a datagrid, the Confirm/reset Button become clickable now to save or reset the changes.
    • Added missing password encryption checkbox in DB Monitor configuration.
    • Added missing LastDBIndex in DB Monitor configuration.
    • Fixed timestamp for “EventLog Legacy Format” INSERT
    • Fixed invisible encryption checkbox for password fields (Like ODBC Action)
    • Fixed an issue of unwanted LastRecord saving when changing eventlog channels settings.
    • The little “Save” Button has been changed to a “Confirm” which is more precisely.
    • Corrected Min/Max values for General->Queue Limit Setting.
    • Removed invisible click areas for all checkboxes and radio buttons.
    • Fixed loading of “Processed Files” in File Monitor when running in file config format.
    • Changed error handling when exporting configuration in file format.
    • Fixed incorrect trimming of spaces at the end of text variables (problem only affected file based configurations)

You can download Free Trial Version of MonitorWare Agent.

MonitorWare Agent 10.1 Released (Build-IDs: Service 10.1.453, Client 10.1.1538)

MonitorWare Agent 10.1 Released

Build-IDs: Service 10.1.453, Client 10.1.1538

Features

  • All internal errors are now logged into the EventLog when “Event Warnings” are enabled in general options.
  • Added Rule Date Conditions. By default a rule will always be processed. It can be set to only process messages generated since the installation or custom date.
  • Syslog Server: Added new Option to save original source into custom property when using “Take Source system from Syslog message” option.
  • SNMP Trap Receiver: Added option for resolving Snmp OID in short format (Last Portion only).
  • Added new service called “Passive SyslogListener”: This is basically a TCP Listener who sends cached syslog messages (Fille by a Syslog Queue Action) to any client that connects.
  • Added new action called “Syslog Queue Action”: This is a diskbased queue action who stores syslog formatted message into queuefiles. Syslog Queues can be processed and cleared by the Passive SyslogListener only.
  • File Monitor: Files are now opened with FILE_SHARE_DELETE flag which enables other applications to del

Bugfixes

  • SSL Connections: Fixed an issue not using custom configured certificates when TLS anon mod was used.
  • FileConfig Mode: Fixed a bug loading filters properly. Also added support for reloading data variables automatically.
  • Core Engine: Fixed an internal processing bug caused when rebuilding Messages from cache files.
  • Syslog Server: RFC 5424 header parsing fixed, a timestamp can be a NILVALUE now.
  • Syslog Server: Fixed bug ignoring “Take Source system from Syslog message” option when UDP was used.

You can download Free Trial Version of MonitorWare Agent.

Creating a simple Syslog Server

Last updated 2016-08-26 by Jan Gerhards, using Winsyslog 13.2.

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.

Step 1 – Defining a Rule Set for File Logging

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 “RuleSets”. 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:

After that, select “Add a Rule for each of these Actions”. You should then be able to change settings in the before greyed-out area. There, select “File Logging” (subitem of “Storing Actions”). Your screen should now look like this:

After that, click “OK” and the wizard will close. The client will now show 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” action configured. We will review the settings just for your information. Click on “Filters”:

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 for all messages.

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” 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 (meaning the name of the generated file will be MonitorWare-*date*, i.e. “MonitorWare-2016-08-26.log”). It will include all information items in the file (you can select the information items that will be in the file by scrolling down and ticking the boxes).

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, please remember to save your changes. To do so press “Save” (upper left corner).

Now you have a useable rule set for logging incoming messages to a text file.

Step 2 – 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 configuration pane opens.

Also, you will see a newly created service beneath the “Services” part of the tree. View and can rename it if you want (in this example, we will name it “My Syslog Server”). After this, press save.

Your screen should now look like this:

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. If another one is to be used, you can change it to another ruleset here (you might have to scroll down to view the option):

This procedure completes the configuration of the Syslog server.

Step 3 – (Re-) Start the Service

The 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 or with the configuration client. These are highlighted in the screenshot below:

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 the application is ready to accept and store incoming messages.

Step 4 – Configure your Syslog-Enabled Devices

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.

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.

Centralized logging in a hybrid environment (Windows/Linux) – Step 4

Step 4 – Setting up the Linux Clients

We still need to implement the Linux clients into our logging network. This could be Linux workstations or servers. Currently, rsyslog is already shipped with many Linux Distributions as the default syslog daemon already. Though, often a rather old version is installed (mostly v3), this will be sufficient for our current goals.

For our example we will use a Fedora system and alter the configuration accordingly. In the end, rsyslog should use the logs, that are logged locally and forward them via TCP to the central log server.

Please note: The example has been made with Fedora 13. Some steps may vary with other Linux distributions. Since there are so many possibilities, we cannot list them all. So we only concentrate on one version.

Step 4.1:

First of all, we need a terminal or command line and go into root mode with su. We do not need the root rights desperately, but it is a bit easier to achieve our goals.

Step 4.2

We need to alter the configuration accordingly. We will use the vi text-editor to do so. If you are not familiar with vi, you should consider getting some knowledge first with the vi man page.

You can find the default configuration file in

/etc/rsyslog.conf

This configuration file will be loaded once rsyslog is started.

Open the configuration file by the following command:

vi /etc/rsyslog.conf

Your terminal should look like this:

centralized_monitoring_4001

Step 4.3

Under the header “#### MODULES ####” you can see the loaded modules. The ones we need are already loaded. For sending syslog, we do not need a extra module to be loaded. Basically, the imuxsock.so is listening to the local log socket and imklog.so provides the support for kernel logging. More is currently not needed.

When going further down in the configuration, we see parts that are called UDP and TCP syslog reception. They are uncommented. We don’t need them, so we leave them that way. As you can see, there is the command to load a module (introduced my $ModLoad) and then a specific command that is given to the module which tells it to run as a syslog server on a specific port.

Step 4.4

When scrolling further down in the configuration file, we will find the header “#### RULES ####“.

centralized_monitoring_4002

Here, some rules are defined about which logs are stored in which location. These rules have a basic format. Basically, this looks like this:

facility.severity storage_location

The facility roughly determines, what has generated the log message. The severity tells you, how urgent the message is. And the storage location determines, where to store the logs. In the default config, there are several rules for some important log files. They will all be stored in the folder /var/log.

We need to add another rule for forwarding all log messages via TCP syslog. For now, go to the last of the rules and insert the following:

*.* @@central_server:10514

This rule means that all messages, no matter the facility or severity, will be forwarded via TCP to the central server on port 10514. We need to choose port 10514, since our central server will listen to TCP syslog on this port.

In the configuration file, this should look like this:

centralized_monitoring_4003

You can now save and quit vi.

Step 4.5

Now that we have altered our configuration according to our needs (which hasn’t been too much), we still have one more thing to do. We need to restart the service.

Now that we are back on the command line, we can easily use the following command:

service rsyslog restart

This will tell the rsyslog service to stop and start again. Thus, the configuration will be loaded with the changes we made.

centralized_monitoring_4004

Step 4 – finished

We are now finished with setting up rsyslog correctly. It will take all the logs it receives and forwards them to our central log server via TCP on port 10514. In addition to that, the default log rules still exist and will log messages to the local harddrive.

Though, there could be many more scenarios and configurations. We decided to keep it simple for a basic setup.

<< Go back to the main page

Centralized logging in a hybrid environment (Windows/Linux) – Step 3

Step 3 – Setting up the other Windows Servers

We already have the central server and the regular Windows clients set up. We now need to set up the other Windows servers. We assume, that we have other Windows 2008 Servers. On these servers we want to monitor the local Event Log and textfile-based log files. The log messages shall be transferred to the central server via TCP again.

To achieve this, we need MonitorWare Agent installed on those servers. This is simply because it is able to monitor textfiles in addition to the regular Event Log. In addition to MonitorWare Agent, we need nothing to be installed. Since we want to monitor textfile-based log files, we assume there is an IIS running.

Step 3.1

First, we will set up the ruleset. By doing this, we can create the services and they will automatically bound to the ruleset.

centralized_monitoring_1002

Right-click on RuleSets in the left hand list. A context menu will appear. Click on Add RuleSet

centralized_monitoring_3001

The RuleSet Wizard will appear now. You can give your ruleset a name of course. We will use TCP Forwarding for this example. After that, click on “Next”.

centralized_monitoring_3002

On the second page of the wizard we can specify what actions we want. Since we only want the log messages to be forwarded via syslog, check the box next to “Forward Syslog”. After that, click “Finish” to create the ruleset and action.

Step 3.2

centralized_monitoring_3003

When you expand the treeview now, you will find a rule named “Forward Syslog” with an attached action of the same name.

centralized_monitoring_3004

Now click on the action “Forward Syslog. You can see the default values now.

centralized_monitoring_3005

We need to change some of those settings now. First of all we need to enter the IP or hostname of our central server into the field “Syslog Server”. After that, change the port to 10514, since our central server will listen to syslog on this port. And we need to change the protocol type. Change is to TCP (persistent connection). That is all for now. Click on the Save button on the top so we can go on configuring the Service itself.

Step 3.3

Currently, when clicking on Configured Services you will not see a thing. But we will configure the services now. Without them, MonitorWare Agent is not able to get any log messages. We will setup 1 EventLog Monitor and 1 File Monitor.

centralized_monitoring_3009

When right clicking on Configured Services a context-menu will open. By moving your cursor to “Add Service” you can see a list of Services, that may be configured. The list seems pretty long, but we basically need 2 services of them.

centralized_monitoring_3006

Click on “EventLog Monitor V2” first. The Services Wizard will open. Simply click on Finish for now. Repeat this again for the File Monitor.

centralized_monitoring_3010

In the end, you should have a list with 2 Services. For our example I renamed the services by doing a right-click on the Service name I wanted to change and the choosing “Rename Service”.

Step 3.4

Settings for Event Log Monitor V2

centralized_monitoring_3007

The Event Log Monitor V2 needs no additional setup. Again the default values are ok. If you want specific Event categories not to be stored, you can disable the options. But the basic format is sufficient.

Step 3.5

Settings for File Monitor

centralized_monitoring_3008

The File Monitor needs some additional settings. First, enable the option “Allow Directories or read multiple files”. You will see, that the use of wildcards will be automatically enabled and some other options completely being disabled.

Then we need to set the source files. For our example, we want to monitor the IIS logfiles. At the top of the File Monitor configuration you can see the option “File and path name”. There is a Browse button right next to it. Click it.

A windows explorer window will open, where you can choose the file you want to monitor. Navigate to the path C:\inetpub\logs\LogFiles\W3SVC1\. This is the location where the log files are stored. Please note, that the file location could be different when using another version of IIS. Choose the first file in the list. (Note: Daily Internet Information Server log files are  named  “u_exyymmdd.log”, with yy being the 2 digit year, mm the month and  dd the  day of month. To generate the same name with file monitor, use  the  following name “u_ex%y%m%d.log”.)
Set the Logfile Type to “W3C WebServer Logfile”.

Please note, that this step can be easily adapted for other log files (e.g. DHCP log files) as well.

Step 3 – finished

We have now finished setting up the other server. You only need to Save the configuration and start the Service with the “Play” button at the top of the Configuration Client. MonitorWare Agent will pull the logs from the Event Log and the text files and forward them via TCP syslog to our central log server.

<< Go back to the main page

Centralized logging in a hybrid environment (Windows/Linux) – Step 2

Step 2 – Setting up the Windows Clients

Setting up the Windows Clients is rather easy. To do this, we only need to have EventReporter installed. EventReporter will be configured to pull the Windows Event Logs and forward them to our central syslog server via TCP syslog. Our example system will be Windows XP.

When you open the Configuration Client, you will see the configuration tree on the left. Most important are the part “Configured Services” and “Rulesets”. Right now, both have no content. But we will change that now.

Step 2.1

As a first step, we will set up the ruleset again.

centralized_monitoring_2001

Right-click on RuleSets in the left hand list. A context menu will appear. Click on Add RuleSet

centralized_monitoring_2002

The RuleSet Wizard will appear now. You can give your ruleset a name of course. We will use TCP Forwarding for this example. After that, click on “Next”.

centralized_monitoring_2003

On the second page of the wizard we can specify what actions we want. Since we only want the log messages to be forwarded via syslog, check the box next to “Forward Syslog”. After that, click “Finish” to create the ruleset and action.

Step 2.2

centralized_monitoring_2004

When you expand the treeview now, you will find a rule named “Forward Syslog” with an attached action of the same name.

centralized_monitoring_2005

Now click on the action “Forward Syslog. You can see the default values now.

centralized_monitoring_2006

We need to change some of those settings now. First of all we need to enter the IP or hostname of our central server into the field “Syslog Server”. After that, change the port to 10514, since our central server will listen to syslog on this port. And we need to change the protocol type. Change is to TCP (persistent connection). That is all for now. Click on the Save button on the top so we can go on configuring the Service itself.

Step 2.3

We need to configure our service now. Right-click on “Configured Services” in the configuration tree on the left to pop up a context menu.

centralized_monitoring_2007

When you go to “Add Service” you will see the list of available Services. The list is a lot smaller than in MonitorWare Agent. We need the regular Event Log Monitor in this case.

Note: If you are using Windows Vista, 7 or Server 2008 you might consider using the Event Log Monitor V2, since it is optimized for the new EventLog that has been introduced with Windows Vista.

centralized_monitoring_2008

When you have clicked on Event Log Monitor in the list, a wizard will open. Since we will not do any configuration now, just click on “Finish”.

centralized_monitoring_2009

When clicking on Event Log Monitor in the configuration tree you will see the default options. We can leave these settings as they are. Probably you might want to change the preferred language or the sleep time. As you can see at the bottom, the service is already assigned to our ruleset we created earlier. Newly created services will automatically be assigned to the first ruleset in the list.

Step 2 is finished

Basically, that is it. Save the configuration and then start the service with the button that looks like the “Play” symbol. EventReporter will then start to pull Events from the Windows Event Log and forward them via TCP syslog to your central server.

<< Go back to the main page