Brocade Fabric Watch Administrator's Guide - Supporting Fabric OS v5.3.0 (53-1000438-01, June 2007)

Fabric Watch Administrator’s Guide 79
53-0000438-01
Appendix
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 continuous 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.