How to setup File logging in MonitorWare Agent to consolidate Webserver logs and view them in phpLogCon

How to setup File logging in MonitorWare Agent to consolidate Webserver logs and view them in phpLogCon.

Article created 2008-10-05 by Andre Lorbach.

This article will help you to setup an environment where you can store weblogs from your webserver at a central place using MonitorWare Agent, and view and search them using phpLogCon.

You can download a preconfigured configuration from this link and import that into your own system. The configuration sample contains comments for better understanding. MonitorWare Agent Client can import the XML/REG configuration file via the “Computer Menu”.

1. Requirements
1.1 About the requirements
1.2 Installing and configuring WAMP
1.3 Installing MYSQL ODBC Connector
2. Installing and configuring MonitorWare Agent
2.1 Download and Install MonitorWare Agent
2.2 Setup Processing RuleSet
2.2.1 Setup Database Logging
2.2.2 Create the Database Action in MonitorWare Agent
2.3.1 Setup File Logging
2.4 Add File Monitor Service(s)
2.5 Starting MonitorWare Agent and verifying the configuration
3. Install and Setup phpLogCon
3.1 Download and copy phpLogCon to the right location
3.2 Install and configure phpLogCon
Final Thoughts

1. Requirements

1.1 About the requirements

If you already have a web server with PHP support and MYSQL Server running, you can skip step 1.1 and 1.2.

This can be done with Internet Information Server, but this article focuses on using Apache to do the job. There is another article underway which describes IIS.

So in order to setup phpLogCon later, you will need a web server with PHP support and a MYSQL Server with an administration interface. For these tasks, we recommend the following open source applications:

Apache Webserver
PHP
MYSQL (optionally)
phpMyAdmin (optionally)

You can install and configure all these applications separately, but it is much easier to get WAMP for Windows. WAMP means Apache, MYSQL, PHP on Windows and combines all applications with a default configuration. This results in a system which can be used out of the box. So you do not need to worry about the Apache or MYSQL configuration, you just install WAMP first.

Download the latest WAMP Version from here:
http://www.en.wampserver.com/

1.2 Installing and configuring WAMP

After you downloaded WAMP, start the installation and follow the instructions.
Make sure you do not have a web server or MYSQL Server already installed because this could result in conflicts. Most often Microsoft ISS is already installed on the Windows platform. If so, there is no need to install WAMP, but you still need MySQL and php for IIS. This is described in another guide.

I will use the default installation location in this article which is C:\wamp.

Once the Installation is finished, a new Icon appears in Windows Icon tray. Click it, and choose “Localhost” from the menu to verify if the installation was performed successfully. If it was, you should see a web site looking like the one on the right.

To check if your MYSQL is running, click on the phpMyAdmin Menu button in the WAMP Menu, and login with the username “root” and no password – if you are asked for a login.

1.3 Installing MYSQL ODBC Connector

If you intend to store messages in MYSQL database, you need to install the MYSQL ODBC Connector. Otherwise you can skip this step.

MonitorWare Agent will need a MYSQL ODBC driver in a later step in order to write into the MYSQL database. These drivers have to be downloaded and installed separately from here:
http://dev.mysql.com/downloads/connector

If your Windows System is a x64 version, it is important to install the x64 Version of the MySQL Connector driver. As the WinSyslog Service runs as a 64bit application itself, it will need the connector to be 64bit as well.

2. Installing and configuring MonitorWare Agent

2.1 Download and Install MonitorWare Agent

So if you have not done so already, go to www.mwagent.com and download the latest MonitorWare Agent Version. It is always recommended to use the latest Version of MonitorWare Agent. Once the download has completed, go ahead and install it. Depending on your system, a system restart may be needed (but it usually is not)

2.2 Setup Processing RuleSet

Start MonitorWare Agent Client, and skip the First Startup Wizard.

Add a new RuleSet and call it “Store Logdata”.

2.2.1 Setup Database Logging

If you want to store messages inside MYSQL, follow this step.

Click on your WAMP Icon, and open the phpMyAdmin. Now Create a new database called “mwagent”.

Once done, select the newly created database, switch to the “SQL” tab and copy the SQL statements from the textbox below.

CREATE TABLE SystemEvents ( ID int unsigned not null auto_increment primary key, CustomerID bigint, ReceivedAt datetime NULL, DeviceReportedTime datetime NULL, Facility smallint NULL, Priority smallint NULL, FromHost varchar(60) NULL, Message text, NTSeverity int NULL, Importance int NULL, EventSource varchar(60), EventUser varchar(60) NULL, EventCategory int NULL, EventID int NULL, EventBinaryData text NULL, MaxAvailable int NULL, CurrUsage int NULL, MinUsage int NULL, MaxUsage int NULL, InfoUnitID int NULL , SysLogTag varchar(60), EventLogType varchar(60), GenericFileName VarChar(60), SystemID int NULL ); CREATE TABLE SystemEventsProperties ( ID int unsigned not null auto_increment primary key, SystemEventID int NULL , ParamName varchar(255) NULL , ParamValue text NULL )

Now insert the copied commands into the SQL field. Then Click “GO”, you should see “Your SQL query has been executed successfully” after that as well as two new tables on the left list called systemevents and systemeventsproperties.

2.2.2 Create the Database Action in MonitorWare Agent

Get back to the MonitorWare Agent Client and create a new Rule in your self-created RuleSet called “Database”. Then add a new “Write to Database” Action, and name it “MYSQL ODBC”. After creating this action, you should automatically be taken to the actions properties.

Click on the “Data Sources (ODBC)” button to open the System ODBC Administrator. Click on the “System DSN” Tab and add a new Datasource, select “MySQL ODBC 5.1 Driver” as driver. It is important to add a System DSN rather then a User DSN, because User DSN’s are not usable by the MonitorWare Agent Service (this is a Windows design restriction).

Name the new datasource “mwagent” and use “localhost” as Server, “root” as username and no password. Then you are able to select the database which we created before called “mwagent”.

Check the database logging action again, it should look like the one in the screenshot.

2.3.1 Setup File Logging

If you want to consolidate your webserver logfiles in one large logfile, proceed with this step. Otherwise you can skip this step.

Create a new rule called “File Logging” and add a “Write to File” Action.
Select Custom Line Format, use the following (use copy&paste to enter it):%timegenerated:::localtime%,%timereported:::localtime%,%source%,%syslogfacility%,%syslogpriority%,%syslogtag%: %msg%%$CRLF%

2.4 Add File Monitor Service(s)

First of all find the exact location of the webserver logfiles you want to monitor. In this example, I use the access.log from my local wamp installation located at C:\wamp\logs.

Now add a file monitor service. Inside that service, configure the correct file and path name of the file to be monitored. If you would like to read multiple files, you can enable the property replacer inside the filename.

Be sure to specify the log file type to “W3C WebServer Logfile”. This is important so that the contents can properly be interpreted.

It may also be a good idea to set a syslog tag name that matches the filename (or the function of the file name, e.g. “online-shop”). By doing so, you can easily filter inside phpLogCon.

2.5 Starting MonitorWare Agent and verifying the configuration

From the MonitorWare Agent configuration point of view, everything is setup now. So kindly start the MonitorWare Agent Service and wait a few moments, so that the data can be processed.

If you are using file logging, you should see that the logs folder on C:\ has been created and contains a WebServer.log file. If not, something went wrong. In this case please check the Windows Application EventLog for possible error reports from MonitorWare Agent.

If you are logging into a database, switch back to phpMyAdmin and browse through the systemevents table. You should see at least one data record in this table now, like in the screenshot sample. If not, something went wrong, in this case please check the Windows Application Event Log for possible error reports from MonitorWare Agent.

3. Install and Setup phpLogCon

3.1 Download and copy phpLogCon to the right location

If you are using MonitorWare Agent 8.3 or higher, a proper version of phpLogCon can be found in the MonitorWare Agent installation folder. If you are using an older Version of MonitorWare Agent, I recommend to download the latest stable or beta build from here: http://www.phplogcon.org/downloads
In this article I will use phpLogCon Version 2.5.13.

To unpack the install set, you need a program capable of processing tar.gz files. Most ZIP programs support this. If you do not have one, you can find WinRAR by following the link (we have no affiliation with the makers of WinRAR, but have found it to be a useful tool – use at your own risk).

Open windows explorer and go to the www folder of your Apache web server, which is the folder where you can place html/php files. By default this will be “C:\wamp\www” if you have installed WAMP into the default installation folder. Create a new folder called phplogcon there.

If you downloaded and unpacked phpLogCon, and copy or move the content of the src folder into the C:\wamp\www\phplogcon folder. If you have MonitorWare 8.3 or higher, you can use and copy the contents of the phpLogCon folder of your MonitorWare installation.

The explorer window should look like in the screenshot now.

3.2 Install and configure phpLogCon

Open this link to start the phpLogCon installation: http://localhost/phplogcon/

If you do not see a page like in the screenshot, something went wrong in the steps before, please check them in this case.

Otherwise click on the text-link “here” on phpLogCon’s error page to start its installation routine.

Follow the installation steps of phpLogCon.

I recommend to “Enable User Database” in Step 3, as this will give you an advanced admin control panel. The User Database requires a MYSQL database to work, you can use the same one as you are using for MonitorWare Agent.

If you are using MYSQL to store log messages and you have reached Step 7, switch the source type to “MYSQL Native” and name the Source “WebLogStore DB” Use “mwagent” as Database Name and “root” as Database User. Leave the other configuration variables as they are, see the screenshot for how it should look like. Then click on the Next button to finish the installation.

After you finished the Installation of phpLogCon, you need to login and switch to the sources admin and configure the source “WebLogStore DB” there.

– In field “Message Parsers” add apache2 if you are using combined log format. Add apach2common if you are using common log format.

If you are using file logging and you have reached Strep 7, switch the source type to “Diskfile” and name the Source “WebLogStore FILE” Use “C:/logs/WebServer.log” as syslog file. Leave the other configuration variables as they are, see the screenshot for how it should look like. Then click on the Next button to finish the installation.

After you finished the Installation of phpLogCon, you need to login and switch to the sources admin and configure the source “WebLogStore FILE” there.

– In field “Message Parsers” add apache2 if you are using combined log format. Add apach2common if you are using common log format.

After clicking on the “Finish” link, you should see a working phpLogCon installation. If you do not see any data, there may be no data in your database yet. Otherwise you will see an error code and message from phpLogCon.

Final Thoughts

I hope this article will help you installing and configuring phpLogCon and MonitorWare Agent. If you have problems or question related to this article, don’t hesitate to contact me or our support by email.

Please note that while this setup works, it is not very secure. At a minimum, it is recommended to set proper passwords for the databases (instead of using a password-less root account). Please review the relevant documentation on how to do that.

Forwarding NetApp Event Log Entries via Syslog

Article created 2008-09-22 by Rainer Gerhards

NetApp devices provide diagnostic information via an Windows Event Log like interface. This enables their messages to be browsed by Windows Event viewer and and be automatically processed by tools like EventReporter and MonitorWare Agent.

It goes without saying that there are ample benefits from this capability. For example, instant alerting can be enabled by simply reading the NetApp event logs, checking for some conditions and alerting (for example via email) if something unusual is logged. Another big benefit is that by converting the NetApp Event Logs into syslog, they can be forwarded to a central loghost and thus easily be integrated into a centralized logging and alerting system.

There are two ways to access the NetApp logs. First of all, NetApp exposes them as files which obey the event log file format. These files are dynamically re-written and as such considered to be “live”. Adiscon products support this mode since long and are used with great success in that mode (there exists another article on how to do that).

Secondly, NetApp also provides an emulation of the Windows event log API. Under that emulation, a NetApp devices “looks and feels” just like another Windows machine offering its event log. Well … mostly. There are a couple of subtle differences, with the most important one being that the event log record number is not incremented on NetApp devices. This record number is associated with each event log record. Native Windows always increments this number (up to a very high max value, where it then wraps). The NetApp emulation does not use such a unique record number. Instead, the API always exposes a fixed number of most recent records, but always uses the same recrord number for them. So while the data is being rolled as new records come in, the record number stays the same. Thus, for example, if new data comes in, the data for record number 312 is moved to record number 311 and 312 receives the data from record 313. Under this implementation, event log record numbers do no longer identify a given event log entry.

Adiscon products are optimized for highest throughput and least demand on system ressources. One way to do that is to utilize the uniqueness of record numbers. This optimization leads to problems on NetApp. Namely, new records are never forwarded, because no new record numbers are seen (which leads EventReporter and MonitorWare Agent to beliefe there are no new records). The cure, however, is simple. First of all, checksum verification for the last processed event must be turned on in the configuration of the event log monitor in question. This ensure that an internal checksum is generated as a unique identifier for an event log record. Secondly, the event log monitor must be instructed to always search for new events based on that checksum. This will enable the monitor to properly detect new events. This configuration can be seen in the screenshot below:

Event Log Monitor settings for NetApp

Please note that while we turn off some optimizations with these settings, performance is still quite good. Most importantly, typical NetApp event logs are relatively small as the contain only a small subset of recent records. This makes reading through them quite painless. Secondly, we still apply a lot of other optimizations, especially when comparing to other tools which blindly try to re-do everything always. Users are still advised to use a sensible sleep value for the event log monitor (the default should be fine), as without the optimizations additional i/o overhead is unavoidable.

Should you have problems implementing this configuration, please contact support@adiscon.com for assistance. We are glad to help.

How to monitor and forward message tracking logfiles from Microsoft Exchange Server using MonitorWare Agent

How to monitor and forward message tracking logfiles from Microsoft Exchange Server using MonitorWare Agent.

Article created 2008-05-09 by Andre Lorbach.

This article will guide you in how to monitor and forward message tracking logfiles from Microsoft Exchange Server using syslog over tcp. As receiver you have the choice of using different applications like WinSyslog, MonitorWare Agent or even open source projects like rsyslog.

You can download a preconfigured configuration from here, which you can import on your target system. The configuration sample will have comments for better understanding. The MonitorWare Agent client can import the XML/REG configuration file by using the “Computer Menu”.

If message tracking is enabled in Exchange Server, the logfiles are created daily by default and contain informations about each message which is routed through the Exchange server. Depending on the workload of your server, you may need to delete the logfiles from time to time to save harddisk space. But you need a backup of these logfiles in case you need to review them. This is where MonitorWare Agent comes into play. The File Monitor of MonitorWare Agent can be easily used to forward the message tracking logfiles to a syslog repository.

1. Exchange Server preparations
1.1 Enabling Message tracking logging in Exchange Server
2. Installing and Configuring MonitorWare Agent
2.1 Download and Install MonitorWare Agent
2.2 Setup up basic MonitorWare Agent configuration
2.3 Configure the Foward Syslog Action.
Final Thoughts

1. Exchange Server preparations

1.1 Enabling Message tracking logging in Exchange Server

If already enabled, you can skip this step.

To enable message tracking logging, kindly check the “Enable message tracking” option.

Optionally you can select “Remove log files” option and define how old the logfiles have to be in order to get deleted. You may also change the log file directory, may be to another hard disk, in order to save the space on the main hard disk.

If enabled, Exchange Server creates one message tracking logfile per day. As you can see in the date modified column, Exchange Server is using UTC and not localtitme to create the logfiles. My testmachine is running with European central time which is GMT+1 and GMT+2 daylight saving time (which is currently set).

2. Installing and Configuring MonitorWare Agent

2.1 Download and Install MonitorWare Agent

So if you haven’t done so already, go to www.mwagent.com and download the latest MonitorWare Agent version. It is always recommended to use the latest Version of MonitorWare Agent. Once the download is done, go ahead and install it. You may have to restart after installation, this depends on your system.

2.2 Setup up basic MonitorWare Agent configuration

Start the MonitorWare Agent client and skip the wizard on startup. First we create new “File Monitor” service and name it “Exchange File Monitor”.

Then use the browse button to select the directory which contains the message tracking logfiles. Kindly select one of the logfiles and replace its name with this string: %Y%m%d.log

This will automatically match the logfiles each day, %Y will match the year, %m the month and %d the current day.

It is also important to select UTC as Timemode for the filename, as I already mentioned in step 1.1, the Exchange server used UTC (GMT) to create the logfiles.

Now click on the Advanced Options, and the following dialog will appear. In this dialog, enable the option “ignore empty lines”. The message tracking logfiles sometimes contain empty lines between the logfiles, so this option will remove them automatically.

Make sure that you use only “\n” as message separation sequence, as the typical Windows “\r\n” is not used in the message tracking logfiles.

2.3 Configure the Foward Syslog Action.

The last step is to configure the forward syslog action, first create a new Rule and name it ForwardSyslog. Then create a new Forward Syslog Action and call it Repository for example. You also see a InterActive Action in the sample screenshot here, this is a helper action which forwards to the local InterActive Syslogviewer, which is also installed with MonitorWare Agent by default.

As I wrote in the beginning of this article, there are several syslog products available which can be used as receiver. On Windows, we recommend to use WinSyslog or MonitorWare Agent. On Unix based systems, we recommend to use rsyslog, which is open source of course ;)! Rsyslog is available on many plattforms and integrated in many package systems.

All these syslog products are able to receive syslog message over tcp and also in a persistent connection.

Final Thoughts

I hope this article will help you solving your tasks and shows you the potential of MonitorWare Agent, and what you can archive with it. Feel free to email me for recommendations or questions.

Database Formats

These sample here implement the MonitorWare Common Database Format in widely used database systems. Attention Sybase users: the “Message” name is reserved in your database system and cannot be used as a field name. It needs to be changed, otherwise the table create will fail. Be sure to also change it in to client database field name configuration.

JET (MS Access) Sample
Microsoft SQL Server Sample
MySQL

JET (MS Access) Sample -A sample JET (Microsoft Access) database file is included in the MonitorWare Agent, EventReporter and WinSyslog install set. It conforms to the MonitorWare Common Database format. It is in Microsoft Access 97 format to enhance compatibility. It can be converted to any more current format without any problems. In fact, we recommend using the most current format supported by your system because it offers the best performance. To convert it, please use Microsoft Access.

Microsoft SQL Server Sample – If you would like to create the default database on Microsoft SQL server, please use the following script:

CREATE TABLE.SystemEvents
(
ID int IDENTITY (1, 1) NOT NULL,
CustomerID bigint,
ReceivedAt datetime NULL,
DeviceReportedTime datetime NULL,
Facility smallint NULL,
Priority smallint NULL,
FromHost nvarchar (60) NULL,
Message text,
NTSeverity int NULL,
Importance int NULL,
EventSource nvarchar (60),
EventUser nvarchar (60) NULL,
EventCategory int NULL,
EventID int NULL,
EventBinaryData text NULL,
MaxAvailable int NULL,
CurrUsage int NULL,
MinUsage int NULL,
MaxUsage int NULL,
InfoUnitID int NULL ,
SysLogTag varchar(60),
EventLogType varchar(60),
GenericFileName VarChar(60),
SystemID int NULL,
Checksum int NULL
)
CREATE TABLE.SystemEventsProperties
(
ID int IDENTITY (1, 1) NOT NULL ,
SystemEventID int NULL ,
ParamName varchar (255) NULL ,
ParamValue varchar(255) NULL
)

MySQL Sample – If you would like to create the default database on MySQL, please use the following script:

CREATE TABLE SystemEvents
(
ID int unsigned not null auto_increment primary key,
CustomerID bigint,
ReceivedAt datetime NULL,
DeviceReportedTime datetime NULL,
Facility smallint NULL,
Priority smallint NULL,
FromHost varchar(60) NULL,
Message text,
NTSeverity int NULL,
Importance int NULL,
EventSource varchar(60),
EventUser varchar(60) NULL,
EventCategory int NULL,
EventID int NULL,
EventBinaryData text NULL,
MaxAvailable int NULL,
CurrUsage int NULL,
MinUsage int NULL,
MaxUsage int NULL,
InfoUnitID int NULL ,
SysLogTag varchar(60),
EventLogType varchar(60),
GenericFileName VarChar(60),
SystemID int NULL,
Checksum int NULL
)
CREATE TABLE SystemEventsProperties
(
ID int unsigned not null auto_increment primary key,
SystemEventID int NULL ,
ParamName varchar(255) NULL ,
ParamValue varchar(255) NULL
)

This script should also be easily adaptable to other database systems like Oracle.

When porting the script to other database systems, please note that “nvarchar” is essentially “varchar”. The difference is that data is stored in Unicode which allows storage of non-ANSI characters. Typically, it can be replaced with “varchar” or an equivalent data type without any problems.

2008-03-31 MonitorWare Agent 5.2 Final Released

MonitorWare Agent 5.2 Released

Grossrinderfeld, 2008-03-31

Adiscon is proud to announce the 5.2 release of MonitorWare Agent. This is a maintenance release including new features and bugfixes. The most important changes are:

InterActive SyslogViewer – We are introducing a new tool for Realtime Syslog viewing called “Interactive SyslogViewer”. This application is written in Microsoft .Net which means, the .Net Framework will also be installed with the setup.
New Service “SNMP Monitor” – This new Service can monitor SNMP Devices using the SNMP Get Method. There are many snmp capable devices out there which can be monitored with this new service.
SMTP SSL support for the Send Email Action – This means you can use a secured connection to SMTP Servers. Note that the common default port for SMTP over SSL is 465. If you enable SSL Support and use a normal SMTP Server, the email delivery will fail.
Queue Manager – This feature enables the Agent to cache items in its internal queue on disk using a fixed data file. Warning(!), this feature will slow down processing speed depending on your hard disk speed. This feature can give you an additional level of failover support.
File Monitor – Added full support for UTF Textfiles which means we now support UTF8, UTF16 and normal ASCII text files.
Filter Engine – A new Extended Property type for number based properties is available now, so you can filter for custom properties as numbers.
General SNMP Change – Updated all NET-SNMP MIBS which are shipped with MWAgent, and also introduced custom enterprise MIBS for Monitorware Agent. These Mibs will now be used by default in the SendSNMP Action, to generate useful traps.

For more details read the version history

Version 5.2 is a free download, but requires a version 5 key. Customers with existing 4.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.

2008-03-31 MonitorWare Agent 5.2 Final (Build Service 5.2.348/Client 5.1.1196)

MonitorWare Agent 5.2 Released

Build-IDs: Service 5.2.348, Client 5.2.1196

New Additions

InterActive SyslogViewer
With this release, we are introducing a new tool for Realtime Syslog viewing called “Interactive SyslogViewer”. This application is written in Microsoft .Net which means, the .Net Framework will also be installed with the setup. Continue reading “2008-03-31 MonitorWare Agent 5.2 Final (Build Service 5.2.348/Client 5.1.1196)”

How to send EventLog entries as SNMP Traps with MonitorWare Agent

How to send EventLog entries as SNMP Traps with MonitorWare Agent.

Article created 2008-03-06 by Andre Lorbach.

This article will guide you to use MonitorWare Agent to generate SNMP Traps from EventLog entries and send them to your SNMP management software. This article also requires at least MonitorWare Agent 5.2 or higher, and the custom ADISCON mibs which are included since MonitorWare Agent 5.2.

You can download a preconfigured configuration from here, which you can import on your target system. The configuration sample will have comments for better understanding. The MonitorWare Agent Client can import the XML/REG configuration file by using the “Computer Menu”.
To obtain the most recent custom ADISCON mib files, download these two files und put them into your mibs directory of your MonitorWare Agent installation.
ADISCON-MIB.txt
ADISCON-MONITORWARE-MIB.txt

1. Configuring MonitorWare Agent
1.1 Download and Install MonitorWare Agent
1.2 Setup a EventLog Monitor in MonitorWare Agent
2. Configuring the SNMP Trap
2.1 Create SNMP Trap Action
2.2 Filtering for EventLog severity (Optional)
2.3 Start sending SNMP Trap

1. Configuring MonitorWare Agent

1.1 Download and Install MonitorWare Agent

So if you haven’t done so already, go to www.mwagent.com and download the latest MonitorWare Agent Version. It is always recommended to use the latest Version of MonitorWare Agent. Once the Download is done, go ahead and install it. You may have to restart after installation, this depends on your System.

1.2 Setup a EventLog Monitor in MonitorWare Agent

Start the MonitorWare Agent Client and skip the wizard on startup.

Then add a new EventLog Monitor called “Main EventLog Monitor”. I have set the Sleep time to 5 seconds, for testing purposes. But you can also set this value to 5 seconds in production, it won’t have much impact on the Servers performance.

You also might unselect EventLog Types you do not want to monitor, for this article I will allow all EventLog Types.

2. Configuring the SNMP Trap

2.1 Create SNMP Trap Action

Now add a new Rule under your Default RuleSet called SendTrap. Then add a Send SNMPTrap Action. The default values will already generate a generic “monitorwaretrap”, which is fine for most cases. But we are going to configure our own trap properties.

So you have noticed that the Trap OID and the variable OID’s are represented numeric. Once you click on the Browser Button, the Client will automatically load and display the installed mibs. You can configure the Configuration Client to automatically load the mibs during each startup in the Client Options.

So as you can see you have a few trap OID’s available, in this article we will use the eventmontrap OID which is “.1.3.6.1.4.1.19406.1.2.3”, or in human readable form “ADISCON-MONITORWARE-MIB::eventmontrap”. You can actually define the one or the other form as OID, both will work but the textual representation only if you have the ADISCON Mibs installed. The the numeric representation is always the saver way to configure the OID’s.

Now what you don’t see in the mib browser is the list of variables which are connected with the SNMP Trap. For the eventmontrap, we need a few snmp variables:

genMsg,
genSource,
eventlogEventID,
eventlogEventType,
eventlogEventSource,
eventlogEventSeverity,
eventlogEventCategoryID,
eventlogEventCategoryName,
eventlogEventUser

Start removing the default configured variable, and add our own ones (as in the list above). Add one variable, and use the Mib Browser to select the suitable OID’s and also the correct variable values (See the screenshot for more).

2.2 Filtering for EventLog severity (Optional)

With our current setup, you would send one SNMP Trap for each incoming Syslog messages. But you may not want this, so you can optionally add some filters to reduce the number of outgoing SNMP Traps.

For example you can add a Syslog Severity (Priority) filter, so that only EventLog entries with error messages will be send as trap to your SNMP Manager.

2.3 Start sending SNMP Trap

Now you are ready to start the MonitorWare Agent, note that you properly will get a lot of SNMP Events during the first run.

To show you how the result looks like, here is the output of snmptrapd on a linux machine. There are many SNMP Manager utilities out there, you can even receive SNMP Traps with MonitorWare Agent itself if you like.

2008-03-07 15:18:31 172.16.0.122 [UDP: [172.16.0.122]:1119]:
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (742090390) 85 days, 21:21:43.90 SNMPv2-MIB::snmpTrapOID.0 = OID: SNMPv2-SMI::enterprises.19406.1.2.1 SNMPv2-SMI::enterprises.19406.1.1.2.1 = STRING: “MWAgent: This is a Test no. 1” SNMPv2-SMI::enterprises.19406.1.1.2.2 = INTEGER: 3 SNMPv2-SMI::enterprises.19406.1.1.2.3 = INTEGER: 16

When you receive the trap with MonitorWare Agent, the message output will look like this:

MonitorWare: source=”172.16.0.122″ community=”public” version=”Ver2″ variables: snmp_var_1 = ‘DISMAN-EVENT-MIB::sysUpTimeInstance: ‘Timeticks: (741870389) 85 days, 20:45:03.89” , snmp_var_2 = ‘SNMPv2-MIB::snmpTrapOID.0: ‘OID: ADISCON-MONITORWARE-MIB::syslogtrap” , snmp_var_3 = ‘ADISCON-MONITORWARE-MIB::syslogMsg: ‘STRING: “MWAgent: This is a Test Error MEssage no. 1″” , snmp_var_4 = ‘ADISCON-MONITORWARE-MIB::syslogSeverity: ‘INTEGER: error(3)” , snmp_var_5 = ‘ADISCON-MONITORWARE-MIB::syslogFacility: ‘INTEGER: local0(16)”

As you can see eventlogEventCategoryID and eventlogEventCategoryName are missing. Most EventLog entries do not have a Event Category assigned, so these variables are not added into the SNMP Trap.

Final Thoughts

I hope this article will help you solving your tasks or shows you the potential of MonitorWare Agent, and what you can archive with it. Feel free to email me for recommendations or questions. Of course, the outlined actions are only samples and you may do other things with them.

How to send generic SNMP Traps with MonitorWare Agent

How to send generic SNMP Traps with MonitorWare Agent.

Article created 2008-03-06 by Andre Lorbach.

This article will guide you to use MonitorWare Agent to generate generic SNMP Traps and send them to your SNMP management software. It is also possible to use WinSyslog instead of MonitorWare Agent in some cases, however this article will target the more powerful MonitorWare Agent. This article also requires at least MonitorWare Agent 5.2 or higher, and the custom ADISCON mibs which are included since MonitorWare Agent 5.2.

You can download a preconfigured configuration from here, which you can import on your target system. The configuration sample will have comments for better understanding. The MonitorWare Agent Client can import the XML/REG configuration file by using the “Computer Menu”.
To obtain the most recent custom ADISCON mib files, download these two files und put them into your mibs directory of your MonitorWare Agent installation.
ADISCON-MIB.txt
ADISCON-MONITORWARE-MIB.txt

As you know MonitorWare Agent has many different input sources (services) from which we can generate useful traps. In this article, I will show you how to generate a SNMP Trap from a received Syslog message, so we are going to use the Syslog Service.

1. Configuring MonitorWare Agent
1.1 Download and Install MonitorWare Agent
1.2 Setup a Syslog Server in MonitorWare Agent
2. Configuring the SNMP Trap
2.1 Create SNMP Trap Action
2.2 Filtering Syslog messages (Optional)
2.3 Sending a test SNMP Trap

1. Configuring MonitorWare Agent

1.1 Download and Install MonitorWare Agent

1.2 Setup a Syslog Server in MonitorWare Agent

Start the MonitorWare Agent Client and skip the wizard on startup.

Then add a new Syslog Service called “Main Syslog Server”. We use default values here, Port 514 UDP. Leave the other Options as they are.

2. Configuring the SNMP Trap

2.1 Create SNMP Trap Action

First add a new Rule under your Default RuleSet called SendTrap. Then add a Send SNMPTrap Action. The default values will already generate a generic “monitorwaretrap”, which is fine for most cases. But we are going to configure our own trap properties.

So as you can see you have a few trap OID’s available, in this article we will use the syslogtrap OID which is “.1.3.6.1.4.1.19406.1.2.1”, or in human readable form “ADISCON-MONITORWARE-MIB::syslogtrap”. You can actually define the one or the other form as OID, both will work but the textual representation only if you have the ADISCON Mibs installed.

Now what you don’t see in the mib browser is the list of variables which are connected with the SNMP Trap. For the syslogtrap, we need syslogMsg, syslogSeverity and syslogFacility.

So we are going to remove the default configured variable, and add our own ones, for the message, syslog severity and syslog facility. Kindly add 3 new variables, you use the Mib Browser to select the suitable OID’s and also the correct variable values (See the screenshot for more).

2.2 Filtering Syslog messages (Optional)

With our current setup, you would send one SNMP Trap for each incoming Syslog messages. But you may not want this, so you can optionally add some filters to reduce the number of outgoing SNMP Traps.

For example you can add a Syslog Severity (Priority) filter, so that only syslog error messages will be send as trap to your SNMP Manager.

2.3 Sending a test SNMP Trap

The easiest way to create a SNMP Trap for testing now is use the “Send Syslog Test Message” from the Configuration Client tools menu. If you configured filters, don’t forget to set the correct syslog facility and priority.

2008-03-07 15:18:31 172.16.0.122 [UDP: [172.16.0.122]:1119]:
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (742090390) 85 days, 21:21:43.90 SNMPv2-MIB::snmpTrapOID.0 = OID: SNMPv2-SMI::enterprises.19406.1.2.1 SNMPv2-SMI::enterprises.19406.1.1.2.1 = STRING: “MWAgent: This is a Test no. 1″ SNMPv2-SMI::enterprises.19406.1.1.2.2 = INTEGER: 3 SNMPv2-SMI::enterprises.19406.1.1.2.3 = INTEGER: 16

When you receive the trap with MonitorWare Agent, the message output will look like this:

Final Thoughts

How to get MonitorWare Agent 4.4 working on Windows NT4?

Created 2008-02-28 by Andre Lorbach

The last official version of MWAgent which is supported on Windows NT4 is version 3.1 Build 292.

Due to customer requests, we have created a special build of MonitorWare Agent version 4.4a which will also work on Windows NT4. However this will definitely be the last official build which will work on NT4. The newer versions of MWAgent are using features which are only available on Windows 2000 or higher. Please note that the installer used for MonitorWare Agent 4.4 can not be run under NT4. As such, the setup procedure is a bit clumpsy.

Follow these instructions to get MWAgent 4.4 build 333 working on Windows NT4.

Download and install MonitorWare Agent 3.1 from here:
http://www.mwagent.com/download
Download and unpack the special NT4 Version of MonitorWare Agent 4.4 build 333 from here:
http://download.adiscon.com/mwagent4.4-nt4build.zip
If you haven’t yet, install the Active Directory Extension for Windows NT 4.0, either by download or using the dclient.exe from the package.
Copy the unpacked files over your existing Installation.
Configure and start the MonitorWare Agent.

If any problems occur, feel free to send us an email to support@adiscon.com.

Monitor a SNMP Device using MonitorWare Agent

Article created 2008-02-26 by Andre Lorbach.

This article will help you to monitor SNMP capable devices using the new SNMP Monitor Service of MonitorWare Agent. There are many devices out there which support SNMP, and can also be queried for information’s using SNMP GET. We will use SNMP GET to monitor a device, if we get a respond, the device is most likely running. If we do not get a response, the device may be offline or is powered off. We will use the Send Email Action to generate Alert Emails in case of that a monitored device is not responding anymore.

You can download a preconfigured configuration from here, which you can import on your target system. The configuration sample will have comments for better understanding. The MonitorWare Agent Client can import the XML/REG configuration file by using the “Computer Menu”.

As I said earlier there are many devices out there which do support SNMP like printers, routers, managed switches, linux / windows server and so on. In this article I will show you how to setup the SNMP Monitor Service to monitor a HP LaserJet 4000 laser printer.

1. SNMP Device (Printer) Setup
1.1 Configuring the Printer
2. Configuring MonitorWare Agent
2.1 Download and Install MonitorWare Agent
2.2 Setup Basics in MonitorWare Agent
2.3 Create a Forwarding Rule for the InterActive SyslogViewer (Optional!)
2.4 Create an Email alert
2.5 Configure Filters for the Email Alert
Final Thoughts

1. SNMP Device (Printer) Setup

1.1 Configuring the Printer

As far as I know this printer does not need any special setting to have SNMP support enabled. So by default SNMP is enabled, and it is possible to overwrite the used snmp community name. However for this article I will not modify this setting.

The only thing we will need for this device is it’s IP Address which is 172.16.0.15.

2. Configuring MonitorWare Agent

2.1 Download and Install MonitorWare Agent

2.2 Setup Basics in MonitorWare Agent

Start the MonitorWare Agent Client and skip the wizard on startup. First we create new “SNMP Monitor” Service by right clicking the Configured Services node and going to the Add Service menu.

Insert the IP of the device you want to monitor in the remote host field. You can leave the default values for the other configuration options, they will work fine for most devices.

The Query OID I use in this sample will query the system name of the device. However there are several other variables you pick for monitoring such as:

.1.3.6.1.2.1.1.6 (i.o.d.i.mgmt.mib-2.system.sysLocation)
.1.3.6.1.2.1.1.5 (i.o.d.i.mgmt.mib-2.system.sysName)
.1.3.6.1.2.1.1.4 (i.o.d.i.mgmt.mib-2.system.sysContact)
.1.3.6.1.2.1.1.3 (i.o.d.i.mgmt.mib-2.system.sysUpTime)
.1.3.6.1.2.1.1.2 (i.o.d.i.mgmt.mib-2.system.sysObjectID)
.1.3.6.1.2.1.1.1 (i.o.d.i.mgmt.mib-2.system.sysDescr)

Other OID’s might also be available, it depends on device you are monitoring. There is also a Instance subidentifier option available. I recommend to leave this value to 0, it is only useful if you want to query a OID which contains multiple data.

2.3 Create a Forwarding Rule for the InterActive SyslogViewer (Optional!)

This is an optional step, only useful for testing and debugging the SNMP Monitor. You can disable the Action of this rule later if you want. As we are using the UDP protocol to forward syslog messages locally, it doesn’t really matter.

So first of all create a new Rule called “FwSyslog” and add a new Forward Syslog Action. The Syslog Server is 127.0.0.1 and the syslog port is 10514. See the screenshot for more details.

2.4 Create an Email alert

The best option to get alerted is by email. So we create another rule called EmailAlert and add a Forward Email Action. Please fill Sender, Recipient and Mailserver configuration yourself.

Use the following text as mail subject:
SNMP Monitor Check for ‘%source%’ failed

Use the following text as message format:
SNMP Monitor Check failed for ‘%source%’ SNMP Community: %snmp_community% SNMP Checked OID: %snmp_checkoid% SNMP Status: %snmp_status% Complete Message: %msg%

2.5 Configure Filters for the Email Alert

We were not finished yet ;). We need to configure some filters, otherwise you would get one Email for each SNMP Monitor check, even if successfully.

So add a new Custom Property filter, with the property name “%snmp_status%”. Use the compare operation “not equal” and Property Valur of “0”. So this means the Actions in this rule will be fired whenever the status is not 0, and every status which is not 0 means there was an error.

To avoid email flooding, set the Minimum WaitTime to 600 seconds. This means it doesn’t matter how failures are generated, in 10 minutes there will only be one email alert.