Browse Prior Art Database

Applying Robust, Prioritized Filtering Rules To Categorized SAN Events Disclosure Number: IPCOM000028726D
Original Publication Date: 2004-May-27
Included in the Prior Art Database: 2004-May-27
Document File: 4 page(s) / 30K

Publishing Venue



One of the main purposes of SAN Management applications is to alert users about changes in the SANs that are being monitored. Users are typically made aware of these changes in the monitored SANs by changes to a graphical representation of the SAN the application might be displaying, and also by receiving events published by the application. Due to the specific nature of these events, a simple change to the SAN, such as breaking a connection between two ports, can result in a huge flood of events getting published alerting the user about diverse things such as missing switches, HBAs, LUNs, PVs, etc.. Publishing large numbers of events can lead to two problems:

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 41% of the total text.

Page 1 of 4

Applying Robust, Prioritized Filtering Rules To Categorized SAN Events

The key features of this solution are:

1) Rules are assigned a priority.
2) Rules can be very specific or very general.
3) Rules can specify conditions for suppressing events, or conditions for publishing events.
4) Events are assigned categories that filtering can be based on. These categories can be heirarchical.
5) Rules can be based on several diverse parameters supplied by the event: severity, category, entity type, unique id, etc..
6) Unspecified parameters are treated as wildcards. For example, a rule that specifies to publish events that have a severity of 'critical', but does not list parameter values for entity type or category, would cause all 'critical' events to get published regardless of the type or category of the entity involved.

The logic to incorporate event filtering consists of two components:

- An interface for establishing/modifying event filter rules. The rules can be stored in a database, kept in memory, or in a property file. - A component responsible for applying the rules to determine if the current event should be published.

The second component gets invoked after the SAN manager application has built up an event object and is ready to publish it. This component compares the information in the current event with each of the filter rules that have been established, starting with the one with the highest priority. Once a matching rule is found, that rule is used to determine whether or not to proceed with publishing the event or discarding it. This is done by examining the 'event action' field provided with each rule which will either have a value of 'suppress' or 'publish'. If no matching rule is found for a particular event, the manager should have a default policy that is followed that says to either always suppress events in this case or always publish them.

Event Objects

Events are essentially data objects that consist of several parameters such as:

- Entity type - Severity - Unique_id - State - eg. missing, new, normal - Category - This is the class of event that applies. (See next section.)

Event Categorization

One of the means of minimizing the number of rules necessary is to classify the events. An example of the heirarchy of event classes that may be used for SAN related events is as follows:

- SANEvent - Top level category. - PhysicalEvent - Used for events related to changes for physical entities such as HBAs, switches, ports, etc.. Inherits from SANEvent. - LogicalEvent - Used for events related to changes for logical entities such as LUNs, File Systems, Logical Volumes, etc.. Inherits from SANEvent. - StatusEvent - Used for events related to the status of the manager - DB problems, etc.. Inherits from SANEvent. - SANRegionEvent - Used to indicate zone, SAN, or zone set type changes. Inherits from SANEvent.


Page 2 of 4

By classifying events into general categories such as those described above, the number of rules necessary...