IBM Tivoli Monitoring > Version 6.3 Fix Pack 2 > Installation Guides > Installation Guide > Performance tuning

IBM Tivoli Monitoring, Version 6.3 Fix Pack 2

Optimizing situations

Situations are conditions that you want to monitor on managed systems. Each situation contains a name, a predicate formula, special attributes for specific situation processing, information about whether the situation is automatically started or not, and the sampling interval. It can also contain a command to execute when the situation is true, and advice to give the client when an alert for the situation is surfaced, and so on.

A situation predicate is a formula that uses attributes, functions, and other situations as operands along with threshold values to describe a filtering criterion. The situation formula is made up of one or more logical expressions.

Each expression takes the form:

The situation predicates are similar to a WHERE clause in SQL. In IBM Tivoli Monitoring, predicates are processed sequentially, and perform better if you put the most restrictive condition as the first predicate. You can use the situation editor to create/edit situations by choosing attributes, logical operator, value, and sampling interval, and so on. Situations are assigned to run on behalf of managed systems or lists of managed systems.

When a situation is running on a monitoring agent, the agent collects the current values of the attributes specified in the formula, and tests the values against a threshold. When the condition is met, that is the threshold is exceeded or a value is matched, the agent passes the collected data back to the monitoring server to which it is connected, and an event is generated.

However, some types of situations cannot be tested at the agent level:

For these types of situations, the agent returns all rows back to the monitoring server to which it is connected, and the server performs the testing. In large-scale environments, especially if the sampling interval for the situation is short, evaluation for such situations dramatically increases the workload and memory usage for the monitoring server.

In general, there is limited situation processing at the hub monitoring server if there are no agents directly connected to the hub. For remote monitoring servers, there is a direct correlation to the number of agents, situations, and data rows to the amount of memory required. Therefore, the number of situations and size of the data might be the limiting factor that determines how many agents an individual remote monitoring server can support.

Since the performance of the monitoring server is greatly affected by the volume and frequency of situation state changes, do not run a situation and collect data unless you are interested in the results.

The following recommendations provide guidance for how to write more efficient situations and how to reduce the situation processing requirements:

  1. If possible, avoid use of group functions, embedded situations, or correlated situations. Processing demands for such situations are much higher, since all attribute group rows must be sent to the monitoring server for testing, increasing the processing demand and memory usage on the monitoring server.

  2. Put the most stringent condition at the beginning of the formula because the conditions are evaluated sequentially, left to right.

    Consider a situation that has the first condition test on real storage use, the result set may contain multiple rows; then the second condition tests whether a given process name is among the returned rows. It would be more efficient to first test on process name (the result will be one row), followed by the test on the storage usage, just on the single row.

    Consider the following in creating the condition tests:

    1. Numeric attributes are processed more quickly than text attributes.

    2. String checking with substring (STR) is more efficient than the string scan (SCAN), especially for long strings. If you know the exact location of the text or characters to be evaluated, use a substring.

  3. Use longer sampling intervals where possible, especially for situations that are distributed to many agents.

  4. Minimize the number of situations on attribute groups that can return many rows, such as process or disk attribute groups.

  5. Put mission critical systems in a separated managed system group, and distribute the heavy workload situations to them only if necessary.

  6. Consider spreading business-critical situations among several different remote Tivoli Enterprise Monitoring Servers. For example, a database monitoring situation might be high load, but business-critical. Instead of having all 500 database agents report through the same remote monitoring server, consider configuring the database agents across five remote monitoring servers, which are supporting other less-demanding agents.


Parent topic:

Performance tuning

+

Search Tips   |   Advanced Search