Service Model Definition (4.0)
- Jenni Wallin
A service model contains definitions of objects that represent dimensions, metrics, KPIs, and alarm thresholds. The service model also describes these objects, e g the metrics and dimensions that are required to calculate a KPI.Â
Service model objects and dependencies
The metric and dimension objects are mapped to specific fields in the KDR input. The figures in the example below illustrate how the input data is mapped to a KDR and finally to dimensions and a metric.
Example - Mapping objects to KDR input
The UDR types below have a startTime field that can be used for triggering start and closing of period, i e timestamp field of the KDR is populated with this value. If this type of field does not exist, you can generate a timestamp from APL.
The UDRs RecA and RecB have a different set of fields but it is possible to define dimensions and metrics for the set fields that are available in each type. For instance, a metric can be defined so that it is calculated based on valueX for type 1 and valueY for type 2. You may use any string value as a type identifier. In this example the recordType field is used to identify the type.
Ultra configuration
The KDRs are populated with the values from the collected UDRs. The keys in the value field of the KDR (hereafter also referred to as "fields") can be selected arbitrarily but have to be unique within the KDR. These fields will be referenced in the metric and dimension definitions of the service model.
At this point it would have been possible to treat both UDR types, RecA and RecB, as a single type. In this case you would assign the same field names to both records. For instance, myvalue instead of valueX or valueY.
The fields that will be used for metric calculations must be numerical types, e g int, long, float, double etc.
APL configuration
The service model has two dimensions, Region and Site. There are two references for each of the dimensions, one for the respective types. For type 1, the model references the field region to retrieve the instantiated name of Region. For type 2, it references the field named district. It is assumed here that these will serve an identical purpose even though the original UDRs have distinct formats.
The service model has a simple structure under the tree object that indicates that Region is the parent dimension to Site. This tree has a single root node, tree1, but you may add multiple root nodes. For instance, if a site may span multiple regions, you may want to add a second tree where the hierarchal order is reversed.
The service model has one metric that calculates an average value. Similar to the dimension, there are references for each type in the expression (expr). The expression only contains one field name, which will return its actual value as a floating-point number (double). You may perform more complex calculations using functions, operators, and a combination of fields. For further information, see metric.
Finally the the dimensions, metric, and the tree are combined to define two KPIs. When you apply this model in KPI Management, the output in each period will be the Average metric for the two dimensions, Region and Site. The length of the periods is specified by windowSize, which will have the same unit as the input value. For instance, if the value in the timestamp field of the KDR has the unit seconds, the period length will be 60 seconds.
Service model
Object Types Overview
These are the main object types in the service model:
Object Type | Description |
|---|---|
dimension | The Example - JSON Representation"dimension": {
"Region": {
"kdr_record_type_a": "region_name"
}
}For further information about the |
tree | The The name of a Example - JSON Representation"tree": {
"tree1": {
"Region": {
"Site": {}
}
}
} For further information about the |
metric | The For further information about the |
threshold | The For further information about the |
kpi | The For further information about the |
Â