Situation monitoring and interval settings

You can take advantage of the architecture and efficiencies built into the design of OMEGAMON® for Storage to further reduce or avoid excessive demand on system resources.

Identify the situations that you want to monitor and how often you must monitor them. When you become familiar with the design of the software, you realize that numerous different interval settings can result in excessive demands on system resources. You know when a less-frequent interval can reduce, or increase, demand on system resources.

Take into account how the software gathers data for exception thresholds. The software uses situations to represent exceptions. Situations help you make intelligent choices on setting intervals. The software has a navigator view with leaf names such as Application Summary, Cache CU Performance, and Virtual Tape Subsystems. Leaf names link to workspaces that contain numerous columns of data gathered by a single data collector.

If you right-click the Address Space leaf, for example, you can view all of the situations associated with that leaf. All of the situations on the leaf use the same data collector. If you use the same interval setting for all of the situations on the leaf, the situations are grouped. Because the situations are grouped, one call to the data collector is sufficient to collect the data. However, if each situation has a different interval setting, the data collector is called or run for each situation on the leaf.

If you change an interval from 2 minutes to 1 minute, you increase the demand on system resources. The software groups thresholds and collects all of the data from the same table or attribute group at the same time. When you change the interval, you schedule a new data collector and double the demand on system resources. If you change a third threshold and set it to 3 minutes, you triple the demand on system resources. If you want to sample less frequently, you must ensure that you change all situations that belong to the same attribute group to a less-frequent interval.

If a leaf has four or less situations, ensure that warning and critical situations have the same interval setting. If you do, the data collector must run only one time to collect the data. With five or more active situations, there is no gain, because the collector is already running two times. All situations with the same interval setting are scheduled together. For example, if you apply four warning situations for one interval and four critical situations for another higher interval, you can reduce demand on system resources. This approach assumes that the situations have two conditions or items to evaluate, as most product-provided situations have. If you code a complex seven-condition or evaluation criteria situation, the situation will probably not be scheduled with more than one additional situation. The actual limitation is on the size of the rule.

Before you measure the impact of your changes, you must restart the Tivoli® Enterprise Monitoring Server hub. The process of combining occurs only at start up for situations that are auto-started. In fact, you have a higher demand on system resources before you restart because anything that was previously combined was uncombined when you changed it.