MonitorWare Agent 7.3 Released
Release Date: 2011-04-05
Build-IDs: Service 7.3.401, Client 7.2.0.1326
Bugfixes |
|
You can download Free Trial Version of MonitorWare Agent.
Year: 2011
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:
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 ####“.
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:
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.
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.
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.
Right-click on RuleSets in the left hand list. A context menu will appear. Click on Add RuleSet
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”.
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
When you expand the treeview now, you will find a rule named “Forward Syslog” with an attached action of the same name.
Now click on the action “Forward Syslog. You can see the default values now.
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.
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.
Click on “EventLog Monitor V2” first. The Services Wizard will open. Simply click on Finish for now. Repeat this again for the File Monitor.
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
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
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.
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.
Right-click on RuleSets in the left hand list. A context menu will appear. Click on Add RuleSet
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”.
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
When you expand the treeview now, you will find a rule named “Forward Syslog” with an attached action of the same name.
Now click on the action “Forward Syslog. You can see the default values now.
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.
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.
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”.
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.
Centralized logging in a hybrid environment (Windows/Linux) – Step 1
Step 1 – Setting up the central log server:
The central log server is the most important part of our central log storage and thus will be configured as the first part. And due to all the things it needs to do, it has the most work of course. When selecting your machine to install the central log server on, please keep in mind, that you need quite a good machine for larger networks. If you have a very large environment, it might be a good idea to use multiple servers for this scenario with a load balancer and a separate database server. But in this guide, we will have it all on one machine.
Prerequisites:
The following should be installed and working:
- Windows Server operating system (Windows Server 2008)
- Database Server (MSSQL)
- IIS Webservice
- MonitorWare Agent Professional Server (V7.2)
The list holds the things necessarily needed. In the brackets is schon which we will use in this example. Please note, that this will work with other versions as well, especially with MonitorWare Agent.
As mentioned before, MonitorWare Agent will have multiple purposes. It should receive syslog via TCP and UDP, monitor the local EventLog and textbased logfiles as well as writing everything into a database and sending email messages in case of error and critical messages occuring.
Step 1.1
First of all, we will set up the processing rules and actions. We will start this way due to the design of MonitorWare Agent. Since the Services need to be bound to a ruleset upon creation, we will start this way, so the ruleset is there already when creating the service.
When starting MonitorWare Agent the first time, you will see on the lefthand side our overview of “Configured Services” and “Rulesets”. Right now, there shouldn’t be any entries here.
Right click on “Rulesets”. A context-menu will open.
Choose “Add Ruleset”. The ruleset wizard will open. On this first screen, we can choose the name of the ruleset.
After choosing a name (in this example “Storage & Alert”), click on “Next”. Here we can set, what we will need. Leave the marker for “Create a Rule for each of the following actions” and choose “Send Email” and “Database Logging”.
You can now click on Finish. You will now see a new ruleset in the treeview on the left hand side. If you expand this view completely, you can see the two rules that have been created and the actions that are in there. You should have a rule “Database Logging” and a rule “Send Email”.
Step 1.2
We will now start with configuring the action for “Database Logging”. Expand the branch called “Database Logging” completely. Under actions you will find the “Database Logging” action. When you click it, you will see the configuration window.
Click on the button “Data Source (ODBC)”. This will open the ODBC Data Source Administrator.
Go to System DSN and click “Add…”.
Select SQL Server from the list and click “Finish”.
Choose a name for the datasource and a description. In this case we choose MyMWDB as name. As server choose the name of the server where the database is. In our example we use localhost. Now click on “Next”.
Select “SQL Server Authentication” and type in your MSSQL Login ID and Password. If you have Windows NT authentication like in our case, leave it as is. Click on “Next”.
Select “Change the default Database to:” and choose your new created Database, in our example we use “MyMWDB” which we created beforehand. Click on “Next”.
Leave all at default settings and click “Finish”, a test Window will appear:
Click on “Test Data Source”, normally the following Window should be displayed:
If not, go back and check your Settings, if yes, Click “OK” and exit the System-DSN Wizard.
Now we are back in MonitorWare Agent. Insert the DSN for your database, User-ID and Password.
After that, click the “Create Database” button. We still need the tables that the log messages will be stored in. After clicking the button, a small window will open. Insert the DSN, User-ID, Password and choose the type of database you are using, in our case MS SQL. By clicking on the “Create” Button, the tables needed for the default database format of the MonitorWare Products will be created. After that, close the window.
Since we want to log all messages into the database, there is no need to set up any filters.
Step 1.3
In the next step, we want to set up the Send Email rule. But since we only want error log messages, we need to set some filters. Click on the Filter Conditions. You will see the overview over the filters for this rule.
Right now, the view is empty except for a AND operator. Double-click it to change it into a OR operator.
Right-click on the OR operator. A context menu will open. Go to Add Filter -> Syslog -> Priority.
Click on the filter setting and change the property value to “Error (3)”.
Again click on Add Filter -> EventLog Monitor V2 -> Event Severity.
Click on the second filter setting and change the property value to “[ERR]”.
We are now finished with the filter settings. The filter will accept all log messages that are either of syslog proiority error or critical or Windows Event severity error. The OR operator ensures, that every of these cases will be accepted. When the messages are approved of fitting into the filter, the action will process them.
Click on the “Send Email” action now. You will see the configuration window on the right pane. Currently, there are only the default values in there.
We need to change some settings here, like the Mailserver, Sender and Recipient, the subject and the Mail Priority. If necessary for your mail server, you need to change the authentification settings at the bottom as well. in our example we need SMTP Authentication for that. If you want, you could even enable the backup mail server.
Now we have all actions fully configured. It is now time to setup the configured services.
Step 1.4
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 2 Syslog Receiver, 1 EventLog Monitor and 1 File Monitor.
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 3 services of them.
Click on “Syslog Server” first. The Services Wizard will open. Simply click on Finish for now. Repeat this again for Syslog Server, EventLogMonitor V2 and File Monitor.
In the end, you should have a list with 4 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”. This was mostly to distinct the two Syslog Servers.
Step 1.5
Settings for Syslog Server UDP
We can leave the “Syslog Server UDP” on default settings. It is already listening to UDP on port 514. The rest of the default settings is just fine.
Step 1.6
Settings for Syslog Server TCP
We will now go to the “Syslog Server TCP” now. Here we need to change several settings. Change the protocol type to TCP and the Listener Port to 10514. Further, we need to enable the option “Messages are separated by the following sequence” in the TCP options. It should look like this now:
Step 1.7
Settings for Event Log Monitor V2
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 1.8
Settings for File Monitor
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 1 Finished
We have now finished the configuration for our central server. It will now be able to receive syslog either via TCP (port 10514) or UDP (port 514), monitor the local Event Log as well as the IIS logfiles. Once more click the “Save” button to save the configuration (if not done already) and start the service. All log messages will now be stored into the database as they arrive/occur. Further, administrators will be alerted via email once an error occurs.
Centralized logging in a hybrid environment (Windows/Linux)
Centralized logging in a hybrid environment (Windows/Linux)
Created 2011-03-11 by Florian Riedl
This article will describe how to setup centralized logging in a hybrid environment. Basically, we will have various major steps, that show different configuration of several clients, which forward their log data to a central loghost. There, everything will be stored into a database and processed further for alerting.
To describe the situation basically, we want all machines on the network send their log data to a central syslog server (if possible). For the central log server we take a windows machine running MonitorWare Agent (www.mwagent.com). Here we can receive syslog, monitor local log files and the Windows EventLog. Data shall be stored into a database and several email alerts shall be configured. The other steps describe the configuration of simple Windows workstations and servers, as well as Linux servers.
For TCP transmission we will use port 514 (default) for UDP and port 10514 for TCP. We want to use TCP mainly, because it ensures the transmission of the syslog messages. This is due to UDP being connectionless and thus it can occur (and will) that messages get lost.
The Client machines in this example consist of several different types of machines. We have regular Windows Workstations. Here we will use EventReporter (www.eventreporter.com). In addition to our central server, we have some other Windows Servers which will get MonitorWare Agent as well and some Linux machines which have rsyslog (www.rsyslog.com) installed. These machines will send their log messages via TCP syslog to the central server.
Additionally to these clients, we will mention some other devices and appliances (just roughly), like firewalls, switches and routers.
Step 1:
This is the first and biggest step. We will configure the central server first. The reason is simple. If this is already running, we can setup the clients and it will directly start logging everything. We assume, this is a Windows Server where MonitorWare Agent is installed. The central log server shall provide the following functionality:
- syslog receiver with TCP (for devices that can send TCP syslog)
- syslog receiver with UDP (for devices that can only send UDP syslog)
- monitor the local Windows EventLog
- monitor local textfile-logs
- store all log messages into a database
- send email alerts to an admin on error or critical log messages
Step 2:
In step 2 we will set up the regular Windows clients. These are usually the workstations the people work on. We will use EventReporter here. It can pull all log messages from the Windows EventLog and forward them via TCP syslog. Thus the following functionality is mandatory:
- monitor the local Windows EventLog
- forward all log data via TCP syslog
Step 3:
Now we will configure the other Windows servers. Again, we will use MonitorWare Agent because it has the most functionality. We need the following functions to be setup here:
- monitor the local Windows EventLog
- monitor local textfile-logs
- forward all log data via TCP syslog
Step 4:
Now we get to the Linux servers. Here we need to use a completely different product – rsyslog. For a first-time user, this might look a bit strange. The configuration we want to have here needs the following:
- monitor local log messages
- monitor local textfile-logs
- forward all log data via TCP syslog
Step 5:
This is rather just a note on other devices and appliances that are not yet covered. Often devices (like routers, firewalls or switches) have the possibility to send log data to a syslog server. Usually, this only works via UDP and some machines are even capable of sending logs via TCP. Since there is such a huge mass of different systems and devices, we cannot give correct steps for everything. Please refer to the user manual that came with the device or contact the manufacturer for information about how to configure the devices for sending syslog.
If you already know how to configure it, let it send it’s log messages to the central server on port 514 for UDP or (if possible) port 10514 for TCP.
Conclusion
We now have a setup that stores all the log data that machines on the network will generate to a central database for storage. Most of the clients on the network send their log data securely via TCP to the central log storage. Some machines were rather quick to set up, others needed more effort. Usually the effort rises with the amount of features that will be used. Thus we thought of this setup to be quite simple.
If you have any remarks or ideas of improvement for this guide, please let us know and send an email to info@adiscon.com.
2011-02-28 MonitorWare Agent 7.2b released
Adiscon is proud to announce the 7.2b release of MonitorWare Agent. This is a bugfixing release.
This release only consists of bugfixes:
- Fixed an issue with percent characters in EventLog Monitor V1 and V2.
- Fixed an RFC 2822 compatibility issue with hours which could cause problems displaying the correct time in some mailclients.
- Corrected support for the OutputEncoding Option in ODBC and OLEDB Action related to character fields.
- Fixed encoding detection for UTF8 encoded Syslog messages, where the BOM starts after the RFC 5424 Syslogheader.
For more details read the version history
Version 7.2b is a free download. Customers with existing 6.x keys can contact our Sales department for upgrade prices. If you have a valid Upgrade Insurance ID, you can request a free new key by sending your Upgrade Insurance ID to sales@adiscon.com. Please note that the download enables the free 30-day trial version if used without a key – so you can right now go ahead and evaluate it.
How can I get rid of control characters and linefeeds?
How can I get rid of control characters and linefeeds?
Created 2011-02-17 by Florian Riedl
Some syslog sources create strange message formats. In many cases, this is of no concern. In other cases, this can disturb reviewing logs. For example, if you are using the InterActive SyslogViewer, control characters in the message create strange placeholder characters (usually this looks like a box, because Windows cannot display those control characters. This is disturbing the view of course and makes it hard to read the log message correctly. This can happen with devices like firewalls or something similar, but with Windows Events as well. Here is an example of the InterActive SyslogViewer struggling with tab characters in the log message:
In this case, we want to remove the control characters from the messages. Therefore we have to use the property replacer on the message property. With the property replacer, we can easily do that. Basically, we want to replace a control character with a space. In the best case, we now have a space where the control character was, but usually a control character has already a space before and/or behind it. But we do not want to have multiple spaces in the middle of a line, so we need to compress them as well.
Now that we have made the decission about what we have to do, we can create the property replacer command. We take the property for the message:
%msg%
This is just the property, but not the property replacer yet. The property replacer looks basically like this:
%msg:::%
Usually, this is used to substract a substring from a string with FromPos and ToPos. Not in this case, but here is a short description anyway. After the first colon comes the FromPos parameter and after the second colon comes ToPos. Now after the third colon, this is important for us now, come the options. Since we need to replace the control characters we need the option spacecc and for compressing space we use compressspace. The property replacer string should look like this now:
%msg:::spacecc,compressspace%
As you can see, multiple options are comma separated.
But where do we use this property replacer now? You can use it in nearly every action that is available. Here is an example of a “Forward via Syslog” Action.
In the field Message Format you can see the property %msg%. This needs to be replaced by our property replacer. In the end, it should look like this:
Now, all the control characters like tabs or linefeeds will be replaced by a space and multiple spaces will be compressed to a single space.
For more information about properties and the property replacer, please refer to the manual at the chapter for Event Properties in the Reference section.
MonitorWare Agent sending to the Microsoft Message Queue
Created 2011-02-03 by Florian Riedl
With version 8.0 of MonitorWare Agent we introduced a new action called “Send MSQueue”. This action allows MonitorWare Agent Professional and Enterprise to forward the received messages to the Microsoft Message Queue. This action is also available in EventReporter Professional (v12.0) and WinSyslog Professional and Enterprise (v11.0).
To get this new functionality working, you need to do some work in advance. Basically, you need to have the Microsoft Message Queue functionality installed on both the system you want to use MonitorWare Agent on, as well as the system where you want to have the messages being forwarded to. If both systems are the same, the process is can be shortened a bit. But our assumption is, that this is not the case.
Step 1
The server which should receive the messages from the message queue needs the most attention here. We will show how to configure it with the example of a Windows 2008 server. These steps should be similar for a Windows 2003 Server as well.
Go to the Server Manager. On the left hand side, you find everything, that is necessary for the server. Go to “Features”. Then click in the right pane on “Add Features”.
You will get a list of features you can install. Right now, we are only interested in the Message Queueing feature. Mark it to be installed. You could expand the view, but for now the default options are sufficient (depending on your needs you might want to install some of the other options). When you have marked Message Queuing, click on “Next”.
You will be shown the Features to be installed. The screenshot shows only the Message-Queuing Service, since this is the only feature we want to install right now. Click on “Install”.
The feature will be installed now. When the results are shown, it should say that the installation was successful. Click on “Close” now.
In your Server-Manager you should now find Message Queuing und Features. Expand the view completely. You will see the different queues now.
Most interesting to us are the privat queues. It will hold the received messages later. But for that, we need to create a queue first. Right-click on the private queues. In the context menu go to “New” and then on “privat queue”. A window pops up, where we can define a name for it. Choose a name and click on “Ok”.
You can see the newly created queue named test on the screenshot. By expanding the view further, you will find more sub-folders like queued messages and journal messages. We will later find the messages in queued messages.
That’s it for now. The server is now ready to receive messages for the message queue.
Step 2
Now we take care of the client setup. We need to setup the message queue feature here as well. In this example we show how to do that on a Windows XP machine. The process should be similar on a Windows Vista or Windows 7 machine.
Go into the Control Panel and open “Add or Remove Programs”. Click on the “Add/Remove Windows Components” on the left side. The Windows Components Wizard will open and it will show you a list of additional programs and services. Scroll down until you find the entry “Message Queuing”.
Mark it for installation and click “Next”. The components for Message Queuing will now be installed. When it is finished, the installation wizard will tell you, that you have successfully completed the installation. Click on “Finish”. You can close the “Add or Remove Programs” window as well.
That was pretty quick. We do not have to do any extra configuration here. We just needed to install these components for the API to be available, so MonitorWare Agent can use it.
Step 3
We can now configure MonitorWare Agent to send to the Message Queue. We assume, that a basic configuration for MonitorWare Agent is already available and it is configured as a syslog receiver with a ready ruleset.
Therefore we just need to create the action. It is called “Send MSQueue”. Right click on “Actions”. A menu will open. Move the mouse to “Add Action” and the list of available actions will appear. Click on “Send MSQueue”, you will find it in the middle of the list.
The setup wizard will occur. Simply click on “Next” and then on “Finish”. You can now see the “Send MSQueue” action with its default values.
We need to change at least the “Server Computername / IP” field and the “Queuename” field. These need to be changed for the scenario to work. The rest can stay as is. Though you might want to change at least the “Queue Message Label” as this will always be the same then. You can change it, by using the properties available in MonitorWare Agent. The same goes for the field “Queue Message Body”, which can be completely customized with properties and you own content. By default it holds the message of the Syslog Message or Windows Event.
We need to change the adress field, which is on the top, to the IP of the machine we want to send to. Hostnames currently do not work yet. The “Queuename” must be set as well. This is needed for the queue that should be filled with messages. You can see on the image below, how this should look like.
You can get the path yourself by going to your queues on the server. Right click on the queue you want the path of and click on “Properties”. A window with the properties will open. In the field “Label” is the path to the queue. This should be copied and pasted into MonitorWare Agent.
Final Thoughts
This is the easiest way to set up MonitorWare Agent to work with the Microsoft Message Queue. More information on the Message Queue is available at the Microsoft website.
Please note: the MonitorWare Agent Service must be started with some account credentials that have administrative privileges on the local machine as well as on the remote server, that shall receive the messages. You might need to set this manually in the control panel for “Services”.
Massive use of memory when using TCP
Massive use of memory when using TCP
Article created 2011-02-01 by Florian Riedl.
Due to some testing we found, that in some cases MonitorWare Agent uses a lot of memory. This will happen, when MonitorWare Agent is configured as a syslog receiver and is listening to TCP. Additionally, this only occurs, when there are large message bursts, that are continously sent.
We realized it, when MonitorWare Agent used up all free memory and even the page file and didn’t stop to allocate memory blocks. First we thought this was a real bug – the memory would be allocated, but not be purged after it was used. But that was not the problem. Further testing proved, that the memory would be free again after a while.
It turned out, that the real reason was a configuration issue in MonitorWare Agent. With the default values for receiving syslog over TCP, the service would not recognize the line separators of the syslog messages, thus “thinking” it would get a single message only and thus allocating more and more memory for this “huge” message. This would happen when receiving large bursts of message and the buffer for receiving syslog messages would be full.
The solution is pretty simple, yet effective. In the configuration client you need to activate a setting for the syslog server. Just activate “Messages are separated by the following sequence” in the TCP Options. With this activated, MonitorWare Agent can properly recognize line breaks. Thus, it will only allocate memory for the real messages in the queue.
This option will be activated by default in the next release of MonitorWare Agent (8.0).