4.4.1 KDR

The KDR UDRs collected by the KPI Cluster In agent hold the source data for KPI calculations. In your APL configuration, you can map the fields of this UDR type to the fields in your service model, e g metric or dimension objects.

The timestamp of the KDR UDRs are used to trigger closing and opening of periods.

Relation between KDR timestamps, Spark Batch Duration, Window Size, and periods

The smallest timestamp in the first Spark batch determines the start of the initial period for each respective KPI. The start time is calculated as:

timestamp - (timestamp mod windowSize)

The end of the periods are determined by period start and window size. When a Spark batch contains records with a timestamp that exceeds the end of the period and if the delay property is set to 0 (zero) the output is sent to Kafka as a last step in the Spark batch. The period is then closed. Records in later Spark batches that belong to the closed period will still be used for KPI calculations but the output will be discarded.

In the figure above, the delay property is set to 1 (one) second. If the delay is configured to be greater than 0 then the trigger for output will be delayed until Spark receives a batch that has timestamp that exceeds the end of the period with the added delay. This property is used to prevent that periods are closed too early due to late arriving data. The default value of this property is 0 (zero).

Since the KPI output is generated at the closing of a period, you can use UDRs to "flush" pending data. The timestamp of the flush record must exceed the start of the next period plus any configured delay. Suggestion for algorithm:

timestamp > <last timestamp> - (<last timestamp> mod <window size>) + <window size> + <delay property>

The following fields are included in the KDR UDRs:

Field	Type	Description
`key`	`bytearray`	This field is reserved for future use.
`timestamp`	`long`	This field must contain a timestamp (e g in Unix time) time for sorting the `KDR` data into a time periods. The meaning of this value can be arbitrary but the contained values should be chronologically consistent. For example the timestamp may indicate either the start or end of a session but not both.
`type`	`string`	This field must contain a string that identifies the `KDR` type. The type is used in the definitions of `metric`- and `dimension` objects in the service model.
`values`	`map<string,any>`	This field must contain a map of key-value pairs where the key is an arbitrary string, and the value contains the input data. The values are used in the definitions of `metric`- and `dimension` objects in the service model.

Example - Mapping input to KDR UDR in APL

kpimanagement.KDR kdr = udrCreate(kpimanagement.KDR);
kdr.type = input.type; 
kdr.timestamp = input.start_time;
kdr.values = mapCreate(string, any);
mapSet(kdr.values, "dimension_1", input.end_time);
mapSet(kdr.values, "dimension_2", input.end_time); 
mapSet(kdr.values, "call_length", input.call_length); 
mapSet(kdr.values, "connect_latency", input.connect_latency);

Next:

4.4.2 KPIAggregatedOutput