How to setup MonitorWare Agent to monitor NetApp devices using backup *.evt files

Wednesday, May 15th, 2013

This article describes how to use MonitorWare Agent to monitor NetApp devices using the backup .evt files. In this guide we describe how to setup the service. For creating the actions, please refer to the our other guides.

There are basically two methods to monitor logs of NetApp devices. The first, described here, is to monitor the .evt files that the NetApp device generates. The second method is to monitor the device via the Eventlog API. Instructions can be found here.

The NetApp device basically offers to access the .evt files via a network share. Thus the files are easily accessible through our products.

Basically, we need to create the Event Log Monitor service in MonitorWare Agent. Simply right-click on services and from the popup list, choose "Add Service" and the "Event Log Monitor".

Now disable all the currently available logs except for one. Double click on the one that is still checked. A new window opens.

In this new windows, enable the option "Read Eventlog from File". The parameters belonging to this option are now available. Insert the file and path name into the field. Alternatively, you can use the browse button to navigate to the remote location of the NetApp and choose the file like that. You could now also change the "Type of Eventlog" if necessary.

Please note, that this method is also fit to monitor multiple files. You only need to change the file name accordingly and insert wildcards to replace name values like dates. This is good for cases, when a new log file is created every day and the filename reflects the date when the file was created, like below for file like adtlog.20130206110000.evt or adtlog.20130206121314.evt.

So thats it basically. You can now choose to forward the log messages via syslog to a central log host, write them into a database or use one of the many other options that are available in MonitorWare Agent.

How to setup MonitorWare Agent to monitor NetApp devices using Eventlog API

Wednesday, May 15th, 2013

This article describes how to use MonitorWare Agent to monitor NetApp devices using the Eventlog API. In this guide we describe how to setup the service. For creating the actions, please refer to the our other guides.

There are basically two methods to monitor logs of NetApp devices. The first, described here, is to monitor the device via the Eventlog API. The second method is to monitor the device via the .evt files the device generates. Instructions can be found here.

The NetApp device basically offers to access the log storage via the Eventlog API. That makes it very easy to use our products to monitor NetApp devices.

Basically, we need to create the Event Log Monitor service in MonitorWare Agent. Simply right-click on services and from the popup list, choose "Add Service" and the "Event Log Monitor".

In the next step, enable "remote EventLog monitoring". Insert the hostname or IP of the NetApp device into the field. Verify the connection with the "Verify" button. You might need to run the MonitorWare Agent service with a account, that has both local administrative rights as well as rights to read the Eventlog of the NetApp device.

Now disable all the currently available logs except for Application, Security and System. Double click on the one that is still checked. A new window opens.

In this new windows, enable the option "Use Checksum to verify the last processed event". The parameters belonging to this option are now available. Also enable "Always search for the last processed Event using the Checksum". If these options are not enabled, polling the log messages will not work properly, because the NetApp logging system does not use a record number to identify single log messages. Repeat this step for the remaining two log types.

So thats it basically. You can now choose to forward the log messages via syslog to a central log host, write them into a database or use one of the many other options that are available in MonitorWare Agent.

AWS-SYSOPS test   ,
1Z0-804 test   ,
350-060 test   ,
220-901 test   ,
210-060 test   ,
70-534 test   ,
c2010-652 test   ,
1Z0-803 test   ,
PMP test   ,
352-001 test   ,
70-410 test   ,
350-080 dumps   ,
ICGB dumps   ,
70-461 dumps   ,
NSE4 dumps   ,
OG0-093 dumps   ,
1Z0-144 dumps   ,
70-487 dumps   ,
300-208 dumps   ,
70-462 dumps   ,
MB5-705 dumps   ,
000-104 dumps   ,
70-417 exam   ,
000-080 exam   ,
000-017 exam   ,
640-916 exam   ,
70-413 exam   ,
70-270 exam   ,
70-533 exam   ,
200-101 exam   ,
70-532 exam   ,
70-480 exam   ,
300-101 exam   ,

Forwarding NetApp Event Log Entries via Syslog

Monday, September 22nd, 2008

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.