Performing Aggregation Using Multiple Conditions
The procedure detailed below takes the example of a Citrix XenApp farm. Let us see how to define an aggregate test that will report the following values:
- Raise a Critical alert when 20% of Citrix XenApp servers in the farm consume over80% of CPU;
- Raise a Major alert when 60% of Citrix XenApp servers in the farm consume over 40% of CPU;
- Raise a Minor alert when 30% of Citrix XenApp servers in the farm consume over 60% of CPU;
The steps to achieve this are as follows:
Select the Add/Modify Tests option from the Aggregates menu of the Infrastructure tile. Figure 1 then appears.
- Set the Aggregate flag in Figure 2 to Managed Components.
- Pick Citrix XenApp 7.x as the component type from the Filter by component type list.
- Since the CPU usage measure of interest to us is reported by the System Details test, select System Details as the Test to be aggregated.
- Provide a meaningful display name for the new aggregate test in the Aggregate test display name text box.
- As aggregation is not descriptor-based in the case of our example, set the Report by descriptorsflag to No.
- The Available measures section will then display all measures that are reported by the Test to be aggregated. Against every measure name, the Aggregate Measure Name set by default for that measure and the Aggregate Function that is applied by default when aggregating that measure will be displayed.
- Let us now focus on the CPU utilization measure. To aggregate the value of this measure based on a single condition, select the Multi-condition option as the Aggregate Function for that measure.
- Once Multi-condition is chosen as the Aggregate Function and Report by Descriptors is set to No, five new columns get added to Figure 2. They are, namely – Target Operation, Target Values, Target Violation by Descriptors, Target Components, and Measurement Unit.
- From the Target Operation drop-down, select the logical function to define the Conditional Aggregation criteria. For the purpose of our example, select >= from this drop-down.
- Since three conditions need to be set for the purpose of our example, the Target Values specification needs to be configured with 3 values - one each for reporting the Critical, Major, and Minor values (respectively) for the new measure.The format for the specification is as follows: <Critical_target>/<Major_target>/<Minor_target>. Accordingly, set Target Values to 80/60/30 in our example.
This specification applies only to multi-conditional aggregation. Here, you need to specify what percentage of components should violate the configured Target Values in order to report the corresponding measure. Like Target Values, this specification should also be in the format: Critical/Major/Minor. For instance, in the case of our example, if more than 80% of components consume more than 20% of CPU, then the measure should report the value Critical. So, the first value under Target Components should be 80. In the same way, the other two values that should be configured for Target Components is 60 and 30. The complete Target Components specification therefore is 20/60/30.
- For every Target Value configured, a corresponding value should exist in the Target Components specification.
- If a Target Value is configured, but no Target Components specification corresponds to it, then eG will throw an error message to that effect, when you click the Include button inFigure 2. Similarly, if a Target Components specification does not have a corresponding Target Value configuration, then again eG will throw an error message to that effect.
Since the Report by Descriptors flag is set to No, you will find an additional Target Violation by Descriptors column. This column offers the following options:
Option Purpose Majority
If you select this option, then the state of the majority of descriptors (for a measure) will be assigned to the component. For example, if 4 out of 5 descriptors of the CPU utilization measure violate the critical target value that you have configured, then the state of the corresponding component will also be Critical. However, if no single state has a clear majority, then by default, eG will assign the least state to the component. For instance, if the CPU utilization measure of a component reports metrics for 3 descriptors, and each of these descriptors violated the critical, major, and minor target values respectively, then by default, eG will assign the lowest state – Minor – to that component. Similarly, if of the 3 descriptors, one descriptor has not violated any of the target values and is Normal, then the state of the corresponding component will be Normal.
If this option is chosen, then eG will first check if all the descriptors for that measure are in the same state for a component. If so, then eG will assign that state to the component. On the other hand, if the descriptors of the measure are in different states, then eG will by default assign the least state to the component. For example, if all 5 descriptors of the CPU utilization measure violate the critical target value that you have configured, then the state of the corresponding non-aggregate component will also be Critical. However, if 3 of these descriptors violate the critical target value, 1 descriptor violates the major target value, and the other descriptor violates the minor target value, then eG will assign the lowest state – Minor – to the non-aggregate component. Also note that, if of the 3 descriptors, one descriptor has not violated any of the target values and is Normal, then the state of the corresponding component will also be Normal.
If this option is chosen, then eG will compare each Target Value with the real-time value of the non-aggregate measure. This comparison will begin with the critical target value specification. Even if a single descriptor violates this target value, the Critical state is assigned to that component. If no descriptors violate the critical target value, eG then compares the major target value with the measure value. If this value is violated by even a single descriptor, then the state of the measure will be Major. Likewise, if no descriptors violate the critical or major values, eG compares the minor target value with the measure value. If this value is violated by even a single descriptor, then the state of the component will become Minor.
Since the Any option is what suits our purpose, select that for the CPU utilization measure in our example.
- From the Measurement Unit drop-down, pick the unit in which the value of this aggregate measure is to be reported. For a multi-condition, the measurement unit can only be Number. Therefore, select Number as the Measurement Unit.
- Then, select the check box corresponding to the CPU utilization measure and click he Include button to save the changes.
Next, switch to the Monitor interface to check what measure this aggregate test reports. Figure 3 depicts the value of the new aggregate measure. As is evident from Figure 2, the CPU health of the server farm is reported as Critical - this means that over 20% of XenApp servers in the farm are utilizing over 80% of CPU. To know which are these XenApp servers, click the icon corresponding to the measure name in Figure 3.
Figure 4 will then appear.
- Figure 4 describes how the value of the measure was computed. In the table at the bottom ofFigure 4, you can see that the components in the XenApp farm have been listed. Against each component, the descriptors - i.e., the Processors - supporting the corresponding server will be listed. The percent CPU utilization of each processor will also be displayed alongside, with an indication as to whether/not that utilization value has violated the configured Target Value condition. The type of violation - i.e., Critical, Major, or Minor - will also be indicated. In the case of our example, the System Details test of each of the XenApp servers in the farm reports metrics for the Summary descriptor only, and not for the individual processors. Therefore, the aggregate test also looks for violations in the Summary descriptor alone.
- As per our specification, a server in the farm is considered to have violated a target value, if any of its descriptors violates that value. Since Summary is the only descriptor in our example, then a XenApp server will be deemed to have violated a Target Value if the CPU utilization value of this descriptor for that XenApp server exceeds any of the Target Values configured .
- If you now look at the values in the Average of CPU utilization column in Figure 4, it will be clear to you that the CPU usage summary exceeds 80% in only 1 out of the 4 XenApp servers - i.e., in 25% of the servers. This violates the Critical Target Value and Critical Target Components specifications. This is why, the measure reports the value Critical.