HP StorageWorks Fabric OS 5.x Fabric Watch Administrator Guide (AA-RVJ0B-TE, September 2005)

Fabric OS 5.x Fabric Watch administrator guide 69
B Basic Fabric Watch configuration guidelines
A default Fabric Watch configuration is available for the purpose of saving setup time. As you gain
familiarity with Advanced Fabric Watch features, they can be tailored to suit the fabric environment. The
custom settings available in Fabric Watch provide an advanced user much needed flexibility of redefining
boundary thresholds and alarm notification methods. The basic concept of Fabric Watch is to monitor the
health of an element by sampling the status, comparing the sample data, and if found outside the threshold
limits notify the user of the event using one or more selected methods. Since Fabric Watch monitors a
variety of
classes and class elements , each element with a unique trait must be evaluated prior to defining
custom thresholds to meet a specific objective. This section discusses some of the changes that one should
consider implementing to improve the overall efficiency of Fabric Watch.
Customization is recommended to achieve the following objectives.
• Selecting appropriate message delivery method for critical and non–critical events.
• Selecting appropriate thresholds and alarm levels relevant to each class element.
• Defining the appropriate Time Base event triggering based on the class element traits.
• Eliminating message delivery that has little or no practical value to the SAN administrator.
• Consolidating multiple messages, generated from a single event.
When Fabric Watch is improperly configured, a large number of error messages can be sent over a short
period of time, making it difficult to find those messages that are actually meaningful. If this happens, there
are a few simple ways to improve the configuration.
When a large number of messages are sent that are not of importance, the source of the messages can be
identified from the error message. Examining error messages for the source can identify those classes
which need to be reconfigured.
When the messages are not desired or not of importance, consider the following options for
reconfiguration.
Recheck the threshold settings. If the current thresholds are not realistic for the class and area, messages
may be sent frequently without need. For example, a high threshold for temperature monitoring set to less
than room temperature is probably incorrectly configured.
If the event setting is continuous, consider switching to triggered. A continuos event setting will cause error
messages to be sent repeatedly as long as the event conditions are met. While each message may be
meaningful, a high volume of these messages could cause other important messages to be missed.
Examine the notification settings. If you are not interested in receiving messages under certain conditions,
ensure that the notification setting for that event is set to zero. For example, you may not be interested in
knowing when the sensed temperature is between your high and low temperature settings, so setting the
InBetween notification setting to zero for this area will eliminate messages generated in this situation.