Setting thresholds and alerts
This chapter describes the following concepts:
3.1 Defining alerts and thresholds in IBM Spectrum Control
IBM Spectrum Control provides multiple possibilities to set up alerts and thresholds to help detect errors at an early stage and alert those responsible. IBM Spectrum Control also provides various options for being notified when a specified threshold was exceeded (see 3.2, “Alert and threshold notifications” on page 82) and how to suppress alerts so that you are not alerted more often than necessary. (see 3.2.6, “Alert suppressions” on page 92).
Alerts/thresholds can be defined at different levels:
•Device level
•Application level
•General group level
3.1.1 Alerts and thresholds at device level
Refer to Figure 3-1. Alerts and thresholds can be set up for each device, individually on the device itself, or on its internal resources (1). Alerts can be set on general conditions, and thresholds can be defined for capacity and performance metrics (2). Alerts can be enabled and disabled by using the switch icon (3). The severity of alerts can be adjusted (4).
Figure 3-1 IBM Spectrum Control Alert Definition window
Performance thresholds can be defined for every performance metric that can be selected in the performance chart for the selected resource.
In addition to maximum or minimum threshold values (1), threshold ranges with different severities can be defined (2), as shown in Figure 3-2.
Figure 3-2 Performance Thresholds
Starting with IBM Spectrum Control version 5.2.11, multi-metric, multi-condition, and multi-component thresholds can be defined by using the Custom tab.
With this function, you can define up to five attributes that all need to be true to trigger a threshold violation alert, as shown in Figure 3-3. In this example, an alert is only triggered if the read response time is higher than 22 ms and the Read I/O Rate is higher than 100 ms/op for volumes that are thin provisioned.
Figure 3-3 Multimetric Alert Definition in Spectrum Control
As shown in Figure 3-4, the combination of multi-components with multi-metrics is also possible using custom alert definitions.
In this example, the alert is only triggered if the read I/O rate is in the range 1,000 - 5,000 ops/s and the read response time is higher than 20 ms/op and the Pool Activity Score (which is a synonym to Access Density) is higher than 0.7 IOPS/GiB.
Figure 3-4 Multicomponent Alert Definition in Spectrum Control
 
Note: Detailed instructions on how to set up custom alerts can be found in the IBM Spectrum Control section of IBM Knowledge Center.
3.1.2 Alerts and thresholds for applications
Volumes in the same storage system might not all have the same performance requirements or performance characteristics, especially when using SAS enclosures in a V9000. Therefore, it might be necessary to set up different thresholds for different volumes or group of volumes.
Similar grouping can be done for other resources, as listed here:
•Applications
•Data stores
•Hypervisors
•File Systems (Only file systems that are monitored through a Storage Resource Agent.)
•File sets
•Servers
•Shares
•Vaults (IBM Cloud Object Storage)
•Virtual Machines
•Volumes
•Volume Groups
There are several options on how you can add resources, such as volumes, to an application:
•Using filters to assign resources to applications
•Adding resources manually to applications, which is possible using these methods:
 – Adding resources with the command-line interface
 – Adding resources individually with the command-line interface
 – Adding resources using bulk assignment
The various options for creating applications are also described in section 5.2 of IBM Spectrum Family: IBM Spectrum Control Standard Edition, SG24-8321.
After creating applications, alert definitions can be set for the members of an application as described in 3.1.1, “Alerts and thresholds at device level” on page 72 and shown in Figure 3-5.
Figure 3-5 Alert definition at application level
Custom Alerts can also be created at an application level.
A hierarchy of applications can be built so that one or more subcomponents can be added to an application, as shown in Figure 3-6.
Figure 3-6 Application with Subcomponents
Alerts can be defined on the main applications as well and are valid for all subcomponents and their components, as shown in Figure 3-7.
Figure 3-7 Custom alert definition for Application with Subcomponents
Considerations for creating applications
Some restrictions apply on how you can add certain resources:
•VMs cannot be added directly to an application using the GUI. Instead, you must add the VM’s agentless servers1 to applications or use the CLI.
•Vaults can only be added to applications by using the GUI.
The option of using filters to assign resources to applications provides the advantage that the created application becomes self-maintaining. Whenever a volume/resource is being created that matches the defined filter criteria, the volume/resource is automatically added to the application. If filters are not used, the newly created volumes/resources need to be added manually to the application.
If multiple filters are being used to assign resources to an application, then resources that comply to at least one of the filters are added to the application. Multiple filters are combined with the OR conjunction, as shown in Figure 3-8.
Figure 3-8 Using multiple filters to assign resources to an application
Currently, backend volumes that are virtualized by an SVC or volumes used for the IFS file system within a V7000 Unified are intentionally excluded when filters are used.
3.1.3 Alerts and thresholds for general groups
Creating groups with resources others than listed for applications can be done by adding them to a general group. All kinds of resources can be added to a general group as described in the General Groups window in IBM Spectrum Control:
1. Add a resource to a general group from the page where that resource is listed. For example, to add a block storage system, go to the Block Storage Systems window, right-click a storage system, and select Add to General Group, as shown in Figure 3-9.
Figure 3-9 Adding Ports to General Group
2. Alerts/Thresholds can then be defined as for applications for the members of the general group, as shown in Figure 3-10.
Figure 3-10 General Group Alert definition for A9000 ports
3. To avoid having to specify alerts/thresholds multiple times for the same kind of storage systems, a general group can be created. See Figure 3-11 for an example for FlashSystem A9000.
Figure 3-11 Adding multiple Storage systems to a general group
4. To be able to set up alerts/thresholds on the internal resources of the storage systems, the internal resources need to be added separately to the same general group, as shown in Figure 3-12.
Figure 3-12 Adding internal resources to an existing general group
5. Now all thresholds can be specified on the various members of the general group including custom alerts for multiple components for all resources of the same kind.
In the members section of Figure 3-13 (1) you can see that two A9000 systems, 404 volumes, and 10 pools were added as members to the A9000 GG General Group.
Alert definitions can be specified for all kinds of members (2) and you can see how many alert definitions have already been configured and enabled. For instance, in Figure 3-13, one alert has been configured at the storage system level, one at port level, and one custom alert has been set up.
Figure 3-13 Alert definitions for multiple A9000 Storage Systems
General groups can be nested like applications.
3.1.4 Considerations about using applications and general groups
The significant advantage of using applications is that they can be created by using the filter functionality and are therefore self-maintaining.
Applications also have nice overview windows where capacity data and performance data are displayed, as shown in Figure 3-14.
Figure 3-14 Application Overview window
Another advantage of using applications is that they also can be used for chargeback and storage consumer reports as described in the IBM Spectrum Control section of IBM Knowledge Center.
Although you only can add a few resources to applications (see Appendix 3.1.2, “Alerts and thresholds for applications” on page 74), general groups have the advantage that all kinds of resources can be added. This capability includes complete storage systems with all their internal resources. Therefore, alerts need to be defined only once at a general group level rather than configuring alerts for each storage system individually.
Because IBM Spectrum Control already provides default alerts at a device level, it might be necessary to disable them if you create similar alerts at an application or general group level
3.2 Alert and threshold notifications
Alert violations can be seen on various windows in IBM Spectrum Control, including these locations:
•General Alert tab where all alerts can be seen
•Alert tab of each device
•Alert tab of each application
•Alert tab of each of the general groups
An individual alert is shown in Figure 3-15. It shows the actual value (1), the alert condition (2), the (internal) resource that triggered the alert (3), the storage system to which the internal resource belongs (4) and, during a performance threshold violation, the performance chart with data before and after the threshold violation (5) including the defined threshold (6). The threshold violation can be easily detected (7). The chart can be opened in a new window by clicking the Open New Window icon (8).
Figure 3-15 Threshold violation window
The affected servers can also be easily detected, as shown in Figure 3-16.
Figure 3-16 Affected Servers
Alerts can be acknowledged, exported, and removed, as shown in Figure 3-17.
Figure 3-17 Alert actions
Notifications can be configured at these different levels:
•General setting (for email only)
•Per device
•Per group
 – Per application
 – Per subcomponent
 – Per general group
 – Per subgroup
•Per individual alert
For each of the above specified levels, it is possible to define the Notification action (1), which can be any of the following actions, as shown in Figure 3-18 (2):
•Create an entry in the Windows log
•Send an email
•Send an SNMP trap
•Send a notification to Netcool/OMNIbus
•Trigger a script based on an alert
Figure 3-18 Alert configuration
3.2.1 Event notification in Windows log
If configured as shown in Figure 3-18, alert notifications are written to the Windows event log, as shown in Figure 3-19.
Figure 3-19 Alert notification in Windows log
Detailed information is available for each event logged.
3.2.2 Event notification to be sent by email
A prerequisite for having event notifications being sent by email is the configuration of the email server. To configure the email server, click Settings → Alert Notifications → Email, as shown in Figure 3-20.
Figure 3-20 Alert Notifications using email
Here the email server can be configured, including authentication credentials (optional) (1). A Global email notification recipient can be set to receive all emails (2).
The recipient for alerts can be overridden for each individual alert definition using the email notification icon (1), selecting Override notification settings (2), and specifying the recipient for this specific alert definition (3), as shown in Figure 3-21.
Figure 3-21 Override notification settings
Notification settings can also be overridden at a device or group level using the Notification Settings tab, as shown in Figure 3-22.
Figure 3-22 Notification Settings
 
Note: The event notification set at a more detailed level overrides the event notification set at a higher level within the same type. For example, the alert notification definition for an individual alert on an internal resource of a storage system overrides the alert notification definition at the storage system level. Likewise, the alert notification definition of a subcomponent overrides the alert notification definition of an application.
Security standards of the email server are automatically detected. The email server is automatically trusted, so no additional tasks are required.
When an email is sent, IBM Spectrum Control attempts to send it using various connection and encryption mechanisms, from most to least restrictive:
•Attempt Secure Sockets Layer connection from the outset with data always encrypted (usually using port 465)
•Attempt TLS encryption that can be started by STARTTLS command at SMTP level if the server supports it (usually using port 567)
•If both of the above techniques fail, attempt unsecured connection (usually using port 25)
IBM Spectrum Control now accepts all server certificates. This feature allows the administrator to connect to a restricted SMTP server without downloading and importing server certificates into the certificate store for each IBM Spectrum Control server.
The email alert notification shows the condition that was violated (1), the actual value (2), the internal resource (3), and the device to which the internal resource belongs (4). In addition, hyperlinks to the internal resource’s properties book (5) and to the alert (6) are included, as shown in Example 3-1.
Example 3-1 Email alert notification sample
Alert Read Response Time >= 3 ms/op & < 5 ms/op has been triggered.     1
 
Violation: 3.22 ms/op       2
Internal Resource: AIX_HS_090,         3
View Resource = https://vm12236.mainz.de.ibm.com:9569/srm/gui#alertResourceRedirector?parent.type=storageSystem&parent.id=65100&type=volume&id=2160730       5
Resource: A9000       4
 
View Alert = https://vm12236.mainz.de.ibm.com:9569/srm/gui#alerts?id=161367    6
3.2.3 SNMP
Alert notifications can also be sent by SNMP trap to one or two SNMP destinations, which can be configured by selecting Settings → Alert Notifications → SNMP.
A second SNMP trap receiver can be configured by using the Add SNMP Destination 2 option, as shown in Figure 3-23.
Figure 3-23 Configure SNMP trap receiver
To receive SNMP traps, the SNMP trap receiver must be configured with the appropriate Management Information Base (MIB) file.
The MIB file can be found as specified in Table 3-1.
Table 3-1 Locating the MIB file
Location of MIB file
Directory
Installation media
unzip_dirdatasnmp ivoliSRM.mib
After IBM Spectrum Control is installed
install_dirdatasnmp ivoliSRM.mib
3.2.4 Netcool/OMNIbus
Alert notifications can also be sent to a Netcool/OMNIbus server, which can be specified in Settings → Alert Notifications → Netcool/OMNIbus, as shown in Figure 3-24.
Figure 3-24 Netcool/OMNIbus configuration in IBM Spectrum Control
The Netcool/OMNIbus server must be configured to handle alert notifications sent by IBM Spectrum Control. It requires the Event Integration Facility (EIF) rule files that can be obtained from the IBM Spectrum Control server, as listed in Table 3-2.
Table 3-2 Event Integration Facility (EIF)
Rules file names
Location of rules files in IBM Spectrum Control
Copy rules files to this location in IBM Tivoli® Netcool/OMNIbus
tivoli_eif_tpc.rules
tivoli_eif_tpc_tbsm.rules
extracted_installation_image/data/omnibus
$OMNIHOME/probes/arch/
 
Reference: For more information, see IBM Knowledge Center, at Configuring Tivoli Netcool/OMNIbus alert notifications.
3.2.5 Trigger a script based on an alert
After an alert was triggered, scripts can be run from any server where a storage resource agent (SRA) is deployed (including the IBM Spectrum Control server). After clicking the Alert notification icon (1), select Run script, and then Upload script (3). The available parameters can be passed on to a script are listed (4), as shown in Figure 3-25.
Figure 3-25 Triggered Run script functionality
The script file MUST be in either of these subdirectories:
•<install_dir>IBMTPCdatascripts
•<install_dir>IBMTPCagentscripts
It might be necessary to Enable running scripts on agent on the server’s SRA, as shown in Figure 3-26.
Figure 3-26 Enable running scripts on agent
3.2.6 Alert suppressions
To avoid getting unnecessary alerts, you can proactively suppress alerts that you do not need.
Four different settings can be specified after selecting the Alert Removal icon, as shown in Figure 3-27.
Figure 3-27 Suppression Settings in IBM Spectrum Control
•Option 1: Do not suppress alerts:
All alerts / threshold violations will generate the specified notification. This setting means that if the performance data is collected every minute, the notifications are sent out every minute while the threshold violation persists.
•Option 2: Only alert once until problem clears (default setting)
The notification is triggered at the beginning of the threshold violation (1), and no notifications are sent while the threshold violation persists (2). If the threshold violation recurs (3) after it had been cleared (4), the notification will be sent out again, as shown in Figure 3-28.
Figure 3-28 Only alert once until problem clears
•Option 3: Only generate alerts every x minute(s)/hour(s)/day(s)
With option 2, no notification is sent while the problem persists. Therefore, there is no difference between (2) and (4) in the number of notifications that are sent. To get notified if the problem still persists, select this option.
Figure 3-29 shows that while the threshold violation persists, notifications are sent out every x minute(s)/hour(s)/day(s) (5).
Figure 3-29 Only generate alerts every x minute(s)/hour(s)/day(s)
•Option 4: Do not alert until condition has been violated for more than x minute(s)/hour(s)/ day(s)
Sometimes it is not necessary to be notified if a threshold gets violated just a few times (6). In this case, option 4 might be a good choice. Notifications will only be sent out if the threshold is been violated for more than x minute(s)/hour(s)/day(s) (7), as shown in Figure 3-30.
Figure 3-30 Do not alert until condition has been violated for more than x minute(s)/hour(s)/day(s)
 
Note: Additional information about how to set up alerts and thresholds is available in IBM Spectrum Family: IBM Spectrum Control Standard Edition, SG24-8321, and in the IBM Spectrum Control section of IBM Knowledge Center.
3.3 Guidelines for thresholds
The combination of alerts with thresholds in IBM Spectrum Control enables you to automate alerts and customize them for your environment. This automation can save you precious time by avoiding manual checks, and allows faster reaction to events because alerts are sent immediately after being triggered. The administrator can take appropriate actions as soon as the warning or alert is received. It is also possible to run a script based on such alerts for standardized events, completely eliminating any need for manual intervention.
However, do not underestimate the task of preparing and defining the required thresholds for your environment. The better the thresholds and alerts are set, the better the whole system works and the less manual intervention is needed here. Every system, every environment, and every setup has its unique characteristics, so there is no generic rule and predetermined values for the various metrics to monitor.
It is critical that every parameter be set based on your specific setup and needs. Also, your environment is probably not static and your settings will need to be reevaluated and adjusted over time. Changes to your environment might be required by an alternation of the existing system, such as a change of the SAN speed, or the introduction of a new storage system.
This section provides guidance on how to select the right setting for specific aspects of your environment.
3.3.1 Service level agreements
A direct source of information are the internal service level agreements (SLA) mandated in your environment. SLAs are your first source to set thresholds on the corresponding system. If there is an SLA in place that says application “gold” must have latencies better then x ms, then set the alerts close to that value, but with some tolerance. You can do so for every parameter specified in an SLA.
3.3.2 Planning and sizings
To avoid overloading a complete system, use the planning and sizing information to help you determine an upper limit for specific characteristics of your environment and set thresholds accordingly. For example, if a system is able to sustain a maximum 100,000 IOPS, set the threshold to trigger an alert at a value slightly lower than that maximum to help keep the system workload in the range that it was sized for.
 
Note: There are some metrics in Spectrum Control for which an alert cannot be set. Check in advance if a particular alert can be set or if a combination of other values can act as a workaround to reach the same goal.
3.3.3 Work with your own historical data
IBM Spectrum Control allows you to easily get a summary of the history of many metrics. That history can help you determine the appropriate value to set as the threshold for triggering alerts on those metrics, as observed in your environment. We illustrate in a brief example, based on FlashSystem 840, an approach that you can use for many other metrics.
In IBM Spectrum Control, open the Alerts Definition window for the system in scope. In our example, the Ports tab is selected with Performance metrics, as shown in Figure 3-31.
Figure 3-31 IBM Spectrum Control Alerts definition tab
For the resource and metrics that you selected, you can view the typical range in the short summary and set the threshold based on that range. The advantage here is that the user is already on the Alerts tab and knows which thresholds can be set. If you want to see a more detailed history and have more options, you can use the normal performance view of IBM Spectrum Control.
Click the Chart icon next to the metric (Port Receive Bandwidth Percentage in our example) to open a chart, as shown in Figure 3-32.
Figure 3-32 Alert Definition detailed view
In this view, the history of this single metric is shown. The time frame can be changed by selecting any of the predefined periods, such as 1 hour, 1 day, 1 week, and so on. You can also customize the time frame.
The yellow line around the 75% in the chart indicates the trigger for a warning, whereas the red one at around 85% is the trigger for an alert.
In the bottom part of the window, you can adjust the value for the warning threshold, which repositions the yellow line.
In this example, you can see that the actual values measured (green curve) are far away from the preset warning and alert thresholds. If wanted, you can adjust them to a closer level.
Make sure of the following before deciding on what value to use:
•Use at minimum a one week time frame to cover at least every weekday, including the weekend. If you have special workloads, for example at end of the month, include this time frame to cover those particular workload situations.
•Evaluate whether the alert threshold must be below the real chart (for example, cache hit ratio) line or above (for example, CPU usage).
•Evaluate whether this threshold is to secure an SLA with a client, or is it just to get a better knowledge of your system or to prepare future planning.
The history of metrics can also be viewed in IBM Spectrum Control standard charts with more details than what you get in the Alerts windows shown in Figure 3-31 on page 96 and Figure 3-32 on page 97. The standard charts provide a more granular view for single resources like a single port.
To better define the settings for thresholds and alerts, you can also combine different values. For example, when looking at latency on ports, you can also set as a condition (filter) that there must be a minimum IOPS on the same port. If there is only a small amount of IOPS on a single resource like a port, a high latency alert might not be relevant. To filter them out and avoid false alarms, set a minimum of IOPS condition along with the latency alert. Another example would be to combine some metrics for volumes with a minimum of space usage. Or you could also combine bandwidth usage in relation to I/O block size.
In summary, whether you rely on SLAs or historical values, or a combination of both, Spectrum Control gives you a lot of flexibility on how to specify alerts and thresholds. Remember to revalidate your settings whenever changes occur in your environment or based on your observations over time.
3.3.4 Device-specific metrics
As already stated, every environment has its own characteristics and properties, so it is impossible to recommend values that will fit every situation. To give some initial guidance, we included some examples, and when applicable, suggested specific values.
 
Important: Keep in mind that we are discussing examples. Before adopting any of the suggested settings, carefully review the characteristics of your environment. These examples are meant to illustrate the type of thinking that must take place when you decide on which metrics and thresholds to use. They are by no means an exhaustive list of the situations that need to be considered in your environment.
IBM FlashSystem 840/900
This section covers several important metrics for which it is useful to set warnings and alerts. This is not a complete list and these might not fit every case.
Data Rate (MiB/s) of ports
It is important to monitor what amount of data is transferred through the ports. Check that the physical bandwidth limitation is not reached. It is usually worth to combine the amount with transfer size because numerous small IOs can saturate a port faster than the bandwidth shows.
Response time (ms/op) of ports
The response time provides the average number of milliseconds that it took handle a transfer (send or receive). This time is measured for every port, but the alert is for all or at least a group of ports. Keep this fact in mind when you set the threshold. Depending on your situation, it might be worthwhile to use the general groups function to separate them.
If the response is too high, try to find the reason and fix the problem, or balance the ports if it is caused by excessive load and uneven use of ports.
Flash Health percentage of Flash modules
This is not a performance-related measurement. However, decreasing health can lead to decreased performance, and should be checked as a possible reason.
IBM FlashSystem V9000
The V9000 offers many features such as compression and Remote Mirroring. All these functions have their own metrics and should be monitored as well. This section focuses on the general performance functions.
CPU Utilization (%)
The CPU utilization is good first indicator of the overall usage of the system. The overall utilization is the primary threshold that should be set. Because one control enclosure must occasionally handle the load of the second enclosure when it goes offline (such as due to software upgrade, power failure, and so on), the CPU utilization threshold should not be set too high. A good value to start with is 60% to trigger an alert.
If this limit is reached regularly, it can be an indicator that you need to distribute the load to other control enclosures or to plan an upgrade with more or newer hardware.
Managed Disks response time (ms/op)
Because there is no usable measurement of the internal drives, the managed disks metrics are an acceptable alternative for setting an alert. A response time issue with managed disks might indicate that the internal disks are themselves experiencing a degraded response time.
 
Note: The internal Flash modules or drives have much better response times than an external NL-SAS device. Keep this fact in mind when setting alerts thresholds.
The best parameter on which to set a threshold is the response time for the MDisks. Keep in mind that different types of backend storage have different characteristics, so a grouping can be helpful here as well.
Port metrics
The port metrics on a V9000.are a very important indicator. The Fibre Channel ports are the interface for many types of workload. This is the interface for communication within the system and with its internal and back-end storage, and also, in most cases, the interface to hosts.
The IBM FlashSystem V9000 offers a huge variety of SAN-related counters that allow you to proactively monitor the environment.
Data Rate (MiB/s) of ports
This metric indicates data transferred through the ports. Check that the physical bandwidth limitation is not reached, and set the alerts lower than the physical maximum. It is valuable to combine the data rate with transfer size because IO with a small transfer size can saturate a port faster than the bandwidth indicates.
Response time (ms/op) of ports
The response gives the average number of milliseconds that it took handle a transfer (send or receive). This time is measured for every port, but the alert is for all or at least a group of ports. Have this consideration in mind when you set the threshold. Depending on your setup, it might be valuable to use the general groups function to separate them.
On the V9000, it is also important to separate the type of load. The type of load can be monitored at a node level. The node to local node traffic should see lower latencies than traffic to host remote node. With local node to node traffic such as cache mirroring, it is important to have low latencies, while a remote node at long distance will experience higher latencies. A granular setting of alerts is important here.
Error rates on ports
In general, any error in the SAN is not good, but some are unavoidable. If you monitor error rates, set the alert threshold at an acceptable but nonzero value to avoid flooding your mailbox with alerts.
The value with highest focus and lowest alert trigger level should be the Cyclic Redundancy Check (CRC) error rate. The CRC error rate should be set low. When it starts increasing, an immediate reaction is needed.
In addition, the other error rates like Link Failures, Signal Loss, and Sync Loss are signs of a broken connection. However, note that such errors can happen during a server reboot or other temporary events and not be the indication of a problem. Alternately, higher and steadily increasing error rates values can be a sign of a problem.
Another port metric, which might not be included in other SAN monitoring tools, is the Zero Buffer Credit metric. IBM Spectrum Control allows you to monitor the Zero Buffer Credit Timer (µs) or the Zero Buffer Credit Percentage (%). While the timer shows the number of microseconds for which the port has been unable to send frames due to the lack of buffer credit since the last node reset, the percentage gives the value in relation to the total load. The percentage is typically the value that you want to monitor. Both metrics are from the FlashSystem V9000 perspective, and thus indicate that the FlashSystem V9000 is not able to send data out to the SAN.
 
Important: Note that the Zero Buffer Credit metrics are not reported with 26 Gb HBAs. However, starting with VSC code V7.8.1, alternative metrics were introduced: Port Send Delay Time and Port Send Delay I/O Percentage.
Figure 3-33 shows the view in IBM Spectrum Control.
Figure 3-33 New metrics for Port Send delay to replace Zero Buffer Credit
The Port Send Delay Time and Port Send Delay I/O Percentage can be used instead of the Zero Buffer Credit, including for 8 Gb ports. If there are two types in use in the same system, only one metric is enough to monitor both.
Volume compression ratio
Because a good practice for enabling compression on a volume is when you can get a minimum of 40% compression ratio, it is worthwhile to set an alert to be triggered when that 40% threshold is not met. However, a nearly empty volume, like a newly created one, can show bad ratios initially. Therefore, it is relevant to combine the compression ratio and the used capacity. In our example in Figure 3-34, we set the minimum used capacity at 10%. This setting means that the 40% compression threshold is only taken into account for creating an alert if at least 10% of the volume are used.
Figure 3-34 Combine Compression Savings and Used Allocated Space
 
1 Agentless servers are automatically created starting with IBM Spectrum Control v5.2.15.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset