Knowledge Base

cancel
Showing results for 
Search instead for 
Did you mean: 

Derived Metrics Calculator and Cluster Metrics Processor for AppDynamics Extensions

Derived metrics are the metrics created by using the existing metrics (let’s call them base metrics).

For example, we have two metrics, namely, cache hits and cache misses. We can calculate the derived metric "cache hit ratio" using the following formula:

cache hits / (cache hits + cache misses)

Since cluster metrics can be obtained by aggregating all the node level metrics, cluster metrics are also considered as derived metrics

 

Points to remember while configuring derived metrics and cluster metrics through config.yml in Appdynamics extensions:

1.Specifying base metric path pattern:

First and foremost, the derived metrics calculator uses the base metric paths and metric values. Since these paths are dynamically created in AppDynamics, it is required to have an insight into these metric paths. So, while configuring the derived metrics in the config.yml, the base metrics have to be specified with their metric path pattern.

For example, Let’s take the following metric hierarchy:

Server1

   Queue

       Queue1

           Cache hits : 10

           Cache misses : 20

           Cache ratio

       Queue2

           Cache hits : 15

           Cache misses : 30

           Cache ratio

Server2

   Queue

       Queue1

           Cache hits : 10

           Cache misses : 20

           Cache ratio

       Queue2

           Cache hits : 15

           Cache misses : 30

           Cache ratio

Let’s consider the base metric “Cache hits”. In the given metric hierarchy, we have 4 "Cache hits”.

  1. Server1|Queue|Queue1|Cache hits
  2. Server1|Queue|Queue2|Cache hits
  3. Server2|Queue|Queue1|Cache hits
  4. Server2|Queue|Queue2|Cache hits

If we analyze the 4 paths, we can see that all the paths have a common pattern with static as well as dynamic parts. Using the above metric paths, let’s build a common pattern.

The static parts in the above paths are “Queue” and “Cache hits”. The dynamic parts are “Server1 (or) Server2” and “Queue1 (or) Queue2”. While building the common pattern for the base metrics, the static part remains the same in the base metric pattern whereas the dynamic parts have to be specified by place holders like "{x}”. Since in this example we have two dynamic parts, two place holders have to be used. Let’s use "{x}” for “Server1 (or) Server2” and “{y}” for “Queue1 (or) Queue2”. The final common base metric path pattern for “Cache hits” is :

{x}|Queue|{y}|Cache hits

 

2.Using multiple base metric path patterns:

The important thing to remember when multiple base metrics need to use the same dynamic value, the place holder variable should be the same.

For example, let’s consider the same hierarchy specified above. Suppose we want to calculate the  "Cache ratio" for each queue in every server. We have the following base metrics pairs, where each pair represent the base metrics required for calculating "Cache ratio” of a specific queue in a specific server.   

  1. Server1|Queue|Queue1|Cache hits  ,  Server1|Queue|Queue1|Cache misses
  2. Server1|Queue|Queue2|Cache hits  ,  Server1|Queue|Queue2|Cache misses  
  3. Server2|Queue|Queue1|Cache hits  ,  Server2|Queue|Queue1|Cache misses
  4. Server2|Queue|Queue2|Cache hits  ,  Server2|Queue|Queue2|Cache misses

In each pair, we can observe that the dynamic parts have the same value, so the metric path patterns of both the base metrics should have same place holder as follows:

    {x}|Queue|{y}|Cache hits

    {x}|Queue|{y}|Cache misses

This means that while calculating the derived metric, same values will be used for the dynamic parts in both the base metrics as shown in the base metric pairs above.

If same place holders are not used, a mix up of values will happen.

 

3.Specifying derived metric path pattern:

The base metrics have a metric path in the metric hierarchy, likewise, the derived metrics should also have a metric path which infers where in the metric tree, the derive metrics fit.

For example, in the above example tree, we want to calculate the "Cache ratio" for each queue in every server as "Cache hits / (Cache hits + Cache misses)”. So, the metric path of the derived metric "Cache ratio” will be {x}|Queue|{y}|Cache ratio and the formula to calculate it will be

{x}|Queue|{y}|Cache hits / ( {x}|Queue|{y}|Cache hits + {x}|Queue|{y}|Cache misses ). It means that for every queue in all the servers, the corresponding Cache hits and Cache misses are used to calculate Cache ratio.

If the place holder {y}, is missed from the derived metric path i.e, {x}|Queue|Cache ratio, then the metric tree will look as follows:

Server1

   Queue

       Queue1

          Cache hits : 10

          Cache misses : 20

       Queue2

          Cache hits : 15

          Cache misses : 30

       Cache ratio

Server2

   Queue

       Queue1

           Cache hits : 10

           Cache misses : 20

       Queue2

           Cache hits : 15

           Cache misses : 30

       Cache ratio

This metric tree implies that the Cache ratio is calculated by using the Cache ratios of both the queues in a server. Although it does not make sense in this case, this technique can be used to get values at cluster level. For example, consider the following:

 

Server1

   Queue

       Queue1

            RAM ops : 0

            Hdd ops : 0

            Total ops:0

       Queue2

             RAM ops : 15

             Hdd ops: 4

             Total ops:19

       Total ops: (0 + 19 = 19)

Server2

   Queue

       Queue1

             RAM ops : 9

             Hdd ops: 3

             Total ops:12

       Queue2

             RAM ops : 2

              Hdd ops: 6

              Total ops:8

        Total ops: (12 +  8 = 20)

 

In this tree we have 2 base metrics “RAM ops” and “Hdd ops", (4 occurrences each)

  1. Server1|Queue|Queue1|RAM ops , Server1|Queue|Queue1|hdd ops
  2. Server1|Queue|Queue2|RAM ops , Server1|Queue|Queue2|hdd ops
  3. Server2|Queue|Queue1|RAM ops , Server2|Queue|Queue1|hdd ops
  4. Server2|Queue|Queue2|RAM ops , Server2|Queue|Queue2|hdd ops

The base metric patterns can be "{x}|Queue|{y}|RAM ops” and “{x}|Queue|{y}|Hdd ops". If we want to calculate the Total ops at queue level, then we can use the following formula:

{x}|Queue|{y}|Total ops =  {x}|Queue|{y}|RAM ops + {x}|Queue|{y}|Hdd ops

But, if we want Total ops at server level, we can derive it with derived metric, “Server Total ops” with the metric path {x}|Queue|Server Total ops and the formula {x}|Queue|{y}|RAM ops + {x}|Queue|{y}|hdd ops.

Since we omitted one dynamic path level({y}) from derived metric path, we can achieve aggregation at its previous dynamic path level({x}). Basically what will happen at this level is, Total ops will be calculated at queue level but the derived metric path is required at server level, so all the queue level Total ops for a specific server will be aggregated at Server level. Likewise if we omit the next dynamic path level({x})  from the derived metric path, we can get Total ops at Cluster level.

The aggregation type can be sum, average or last observed value base on the aggregation qualifier of the metric.  

 

Configuring “derivedMetrics" section in config.yml:

  • To initiate derived metrics in an AppDynamics extension, the config.yml should contain a separate section called “derivedMetrics” and it should have the list of derived metrics and cluster metrics required to be calculated. A sample of the “derivedMetrics” section is as follows:

derivedMetrics:

   - derivedMetricPath: "{x}|Queue|{y}|Cache ratio"

     formula: “{x}|Queue|{y}|Cache hits / ({x}|Queue|{y}|Cache hits + {x}|Queue|{y}|Cache misses)

   - derivedMetricPath: “Cluster|Total ops"

     formula: “{x}|Total ops

     aggregationType: “SUM"

     timeRollUpType: “SUM"

     clusterRollUpType: “COLLECTIVE

  - derivedMetricPath: “{x}|Queue|Server Total ops

     formula: “{x}|Queue|{y}|RAM ops + {x}|Queue|{y}|hdd ops"

  • If the expression has only one operand like the second metric in the above sample, it means that the derived metric is actually a cluster metric, calculated by aggregating base metric values, which does not require applying operations on the base metrics.
  • If the expression has multiple operands, but the “derivedMetricPath” has lesser dynamic path levels like the third metric in the above sample, it also means that the derived metric is a cluster metric, that requires applying operations on the base metrics and use those values to aggregate at the desired level.
  • In the list of derived and cluster metrics, each derived metric should have a “derivedMetricPath” -> path of the derived metric in the metric hierarchy, as well as a “formula” -> the expression used for calculating the derived metric. These two fields are required.
  • In case of cluster metrics (see second metric in the above sample), aggregation type depends on the aggregation qualifier(aggregationType) specified. If the “aggregationType” field is not present(see third metric in the sample), by default, the values are averaged.
  • Other optional fields are timeRollUpType(default value is AVERAGE), clusterRollUpType(default value is INDIVIDUAL), alias which gives an alias name to the derived metric to be used in the metric hierarchy, multiplier, delta and convert .

NOTE : If the base metrics have aliases which are used in the metric tree, the alias names have to be used in the derived metric formula to represent the base metrics.

For example, In the third metric of the above sample, if base metric “RAM ops” has an alias “RAM operations”, then the formula should be “{x}|Queue|{y}|RAM operations + {x}|Queue|{y}|hdd ops” instead of “{x}|Queue|{y}|RAM ops + {x}|Queue|{y}|hdd ops”.

 

Please find the assumptions and limitations of Derived Metrics Calculator and Cluster Metrics Processor here.

Version history
Revision #:
4 of 4
Last update:
Wednesday
Updated by:
 
Labels (5)
Contributors