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
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:
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
firstname.lastname@example.org for assistance.
We are glad to help.