1. KPI Management Overview

UDRs from network assets and IT systems contain raw data that may represent various aspects of business and operations performance. KPI Management allows you to create metrics based on this data, and to calculate KPIs for each of these metrics in different dimensions. This can be used to retrieve valuable information such as the quality of service that a specific customer segment is perceiving, or the status of network assets in a crowded geographical area. 

Examples of metrics:

  • Average duration
  • Total volume
  • Maximum quantity
  • Quality of service
  • Failure rate

Examples of dimensions:

  • Assets type
  • Location
  • User segment
  • Product category
  • Vendor

All calculations are based on configurable service models in which the relations between the various entities are defined, e g metrics, dimensions, and KPIs.

For instance, assume that a set of raw data contains fields that indicate the result of business transactions and a quantitative measurement such as sales amount. These types of fields are suitable to calculate metrics.

Furthermore, also assume that the data set contains information about the geographical location and vendor involved in the transactions. You may use these types of fields to create dimensions in your data. Dimensions can be arranged in tree hierarchies that describe on which level the KPI output should be calculated.

By combining the metrics and dimensions in your service model, you may create KPI definitions. Optionally, you may associate these with thresholds for alarm generation.

To process the data in KPI Management, you must first convert the decoded input into KDR UDRs. To do this, you will copy the values of the fields in the decoded UDR to a map of key-values in the KDR, which can then be referenced in the service model.

The type field in the KDR makes it possible to distinguish between different input types, e g the original UDR type.

Data flow with example

When you run data through your service model, the output will be generated in periods of configurable length. The start- and end time of each period does not depend on system-time but on a timestamp that you can either generate or extract from the input.

The output for each defined KPI is delivered in KPIOutput UDRs. These UDRs contain the "instance path", the name of the KPI, and the calculated value. The instance represents the tree structure in the figure above, but with actual values from the KDR.

Representation of calculated KPIs in KPIOutput UDRs


There are two variants of processing in KPI Management:

  • Non-distributed processing - The KPI calculations are performed in the KPI agent. This type of processing requires little initial configuration and is suitable when you want to process all of the data on a single EC/ECSA, or when manual sharding is an acceptable method of scaling. For further information about non-distributed processing, see 3. KPI Management - Non-Distributed Processing.
  • Distributed processing - The KPI calculations are performed in a Spark cluster that is managed via a service running on one or more SCs. You can scale the solution, without the need for manual “sharding” of the data, by adding Execution Container hosts and SCs. The KPI Cluster In and KPI Cluster Out agents are used to transfer data between Spark and the  workflows via Kafka/Zookeeper. For further information about distributed processing, see 4. KPI Management - Distributed Processing.

Service model definitions for the two variants are identical.

To begin using KPI Management, it is recommended that you follow the steps in the quick-start guides: