-
Non-Product Related Assistance
Request for existing cases, user IDs, Portal navigation support and more
Open KPI Store
The Open KPI Store is part of SAP Focused Run.
Request for existing cases, user IDs, Portal navigation support and more
The Open KPI Store is part of SAP Focused Run.
The Open KPI Store makes it possible to store any time series of numeric values with some identifiers in one generic table and display the result in a chart of System Analysis. The sender of these values can be anything from an APM (like DynaTrace or Introscope), a script running on a host, a weather station or coffee machine. The sender just needs to send the data in a given json format (see data format).
A walkthrough for using the OpenKPI store in the context of a simple example is described in the Step-by-Step guide.
A metric represents one time-based numeric value series. In most cases it will be based on a continuous stream of time points of fixed frequency (for example one point per minute). One point in time can only hold one metric value (number with 25 digits whole part and 6 decimal digits). Uniqueness has to be guaranteed by the sender and will not be checked.
A metric can have a unit (20 characters) and a preferred aggregation method (3 characters, MIN, MAX, SUM, AVG, CNT) which will be used for any non-time based aggregation.
The metric description can be up to 128 characters long and should be unique for the sender, since it is used for dashboard selection and alerting. It is possible to enable self-monitoring for every metric individually. When self-monitoring is activated the Open KPI framework will trigger an alert if the last incoming data push requests did not provide any data for the specific metric.
A sender can have up to 255 different metrics.
Example: File size in MB with the dimension file name. The metric aggregation will be SUM, so that the metric value is aggregated as a sum over every maintained file name.
Additionally to the time dependency a metric can have up to 18 character-based dimensions. The metric value for one point of time and one dimension value tuple needs to be unique. This uniqueness has to be guaranteed by the sender and will not be checked.
The dimension description can be up to 128 characters long.
Dimensions are unique to the sender, not to one particular metric! If a sender has multiple metrics, they all share the same dimensions. Dimensions are also independent from each other.
The first dimension value can be up to 512 characters long, each others dimension can be up to 128 characters long.
A sender represents one generic data storage within the Open KPI Store. It can be interpreted as one monitored object that has exactly one sender type. In that case compared to system monitoring the sender would correspond to one particular technical system like ABCADM~ABAP. The sender could also be interpreted as a group of similar metrics with similar dimensions. In that case the monitored objects could be modeled as the first dimension. For example multiple hosts could send their data to the same sender with different values as the first dimension.
A sender has a 32 character long GUID (globally unique Identifier) that is self-given. It is highly recommended to use a randomized alphanumeric string for this, so that it is unlikely that multiple senders feed the same data storage by accident. The sender also has a 128 character description and a 40 character sender type. The sender type specifies similar senders that feature common attributes. A sender can have up to 5 attributes (128 characters). The labels of these attributes can be maintained per sender type (using the configuration menu from within the System Analysis UI).
Reasonable attributes might describe the location (data center, geographic location like country, region, city) or the technical details of a device (brand, manufacturer, model name).
When comparing to system monitoring, the sender type can be mapped to a technical system type like "ABAP", "JAVA", or "HANA" to categorize the monitoring objects. A sender can then be interpreted as an instance of that sender type.
It is recommended to model a sender type in such a way, that the metrics and dimensions of senders within this sender type are the same or at least comparable. If different senders deliver metrics with the same name but different semantics the end user has to take care about this.
The Open KPI Store is part of the RCA housekeeping job SAP_FRN_RCA_HOUSEKEEPER, which will partition the data and log data base tables. It will also delete any data entries or logs that are older then 30 days. This can be customized using SM30 view rca_hkconfig.
Sender meta data will not be cleaned up automatically.
Data must be sent in POST request bodies to the REST end point https://<frunhost>:<httpport>/sap/bc/rest/rca_gs. Replace the place holders <frunhost> and <frunport> with the actual values, e.g. copied from the FRUN launchpad URL. The request must authenticate with valid user credentials. The authorization SR_SYSANA with activity "01 - Create" must be assigned to this user. The POST body with content type application/json has the following format:
The meta sub object contains the following properties. Properties marked with * are mandatory for sender creation:
The data property contains a nested array of the actual data points: Each data point is an array of the following values:
The following constraints apply:
[
{ "guid":"12345678901234567890123456789012",
"meta":
{ "description":"Sender description",
"type":"Sender type",
"dataEncoding":"STRING",
"attributes":[{"value":"Attribute1 value"} {"value":"Attribute2 value"}],
"metrics":[{"description":"Metric1","unit":"MB","aggregation":"SUM"},
{"description":"Metric2","unit":"°C","aggregation":"AVG"}],
"dimensions":[{"description":"Dimension1"},
{"description":"Dimension2"}]
},
"data":[
["timestamp1","Metric1 value","Metric2 value","Dimensions1 value","Dimension2 value"],
["timestamp1","Metric1 value","Metric2 value","Dimensions1 value","Dimension2 value2"],
["timestamp1","Metric1 value","Metric2 value","Dimensions1 value2","Dimension2 value1"],
["timestamp1","Metric1 value","Metric2 value","Dimensions1 value2","Dimension2 value2"],
...
["timestamp2","Metric1 value","Metric2 value","Dimensions1 value","Dimension2 value"],
...}
]
[{
"guid": "57b03fd8345531de708430494a9e1629",
"meta": {
"description": "myhost1",
"type": "Host",
"dataEncoding": "STRING",
"attributes": [{
"value":"10.20.30.40" // IP address
},{
"value":"Linux" // Operating System
},{
"value":"dc-eu-1" // data center
}],
"metrics": [{
"description": "CPU Usage","unit": "%"
},{
"description": "Disk space available","unit": "%"
}],
"dimensions": [{
"description": "File System"
}]
},
"data": [
["20190116071900", "55.75", "", ""], // metric value 1 = CPU Usage, metric value 2 empty, dimension empty since not applicable for CPU
["20190116071900", "", "95.0", "/usr"], // metric value 1 empty, metric value 2 for file system /usr
["20190116071900", "", "95.0", "/var"], // metric value 1 empty, metric value 2 for file system /var
["20190116072000", "80.34", "", ""] // next time period
]
}]
[{
"guid": "265FBF6CABF91ED2F3B7DCFEC3AE42BC",
"meta": {
"description": "Frankfurt",
"type": "Weather",
"dataEncoding": "STRING",
"attributes": [{
"value": "DE"
}, {
"value": "Frankfurt"
}],
"metrics": [{
"description": "Temperature","unit": "°C","aggregation": "AVG"
}, {
"description": "Humidity","unit": "%","aggregation": "AVG"
}, {
"description": "WindSpeed","unit": "km/h","aggregation": "AVG"
}, {
"description": "Barometric Pressure","unit": "hPa","aggregation": "AVG"
}],
"dimensions": [{
"description": "Country Code"
}, {
"description": "Station Name"
}]
},
"data": [
["20190606133000","18","59","04","1013","DE","Frankfurt"]
]
}]
The Open KPI validator serves two different purposes:
In both cases it is possible to directly send OpenKPI payload to FRUN using the current user account.
Use the Create JSON Configuration tab to visually compose valid OpenKPI payload.
First click the + to create a new sender. You will see warnings whenever the information in the current object is incomplete. Expand the newly created sender via >. Choose a Type from the dropdown list. Fill in a sender name in the Description field. You can accept the GUID for the sender object or fill in any other unique identifier. For the Encoding you will most likely want to stay with UTF-8 or STRING.
Next, fill in attributes for this sender: Use + in the Attributes line to create lines attribute values. If you have maintained attribute names in the configuration they will be displayed here and you can fill in attribute values of the current concrete sender. A warning will be issued if the number of attribute values for the sender does not match with the number of names defined.
In the subsequent section list the metrics that will be reported for the sender and optionally dimensions. Again create new lines via +.
In the last section you can create actual data points. Based on the meta data of the previous sections the metrics and dimensions will be shown.
The bottom part of the screen shows the JSON payload corresponding to the data that was composed visually step by step. You can use Upload button to directly send the payload to your Focused Run system, using the current user account.
Use the tab Validate JSON Configuration to parse and inspect existing JSON payload.
You can paste JSON payload into the input area. Any errors will be indicated by warnings on the top. Any valid OpenKPI senders will be displayed as list below the input area. You can use the beautify button to pretty print the JSON text and the upload button to send the JSON directly to Focused Run.
There are two flavors of alerts available for the OpenKPI store:
To get alerts when the OpenKPI data volume substantially changes (it drops or increases), or if one of the sender type limits is hit you can use self-monitoring alerts. They are activated automatically. In addition you can activate self-monitoring alerts if data points fail to arrive for an expected metric. For this purpose you can set the flag “selfmonactive” for a metric in the JSON payload.
Alerting on metrics values is available starting with Focused Run 3.0 SP00.
In the System Analysis application open the configuration panel via the header button. Open the alert configuration dialog via the “warning” icon in the OpenKPI Settings area.
Click the “Create New Alert” to start defining a new alert.
The overview tab offers the following options:
Next, navigate to tab “Metrics” in the alert configuration dialog.
Click “Add New Metrics” to select metrics for the alert: You will get a dialog listing all metrics defined for the selected sender type. Choose metrics for which you want alerting and confirm the metric selection dialog with “OK”. The metrics are listed in the metrics table then. For each metric use the “>” in the table row to navigate to the detailed definition of a metric. You can define:
Next, navigate to tab “Scope” in the alert configuration dialog.
Click “Add new scope elements” to select sender objects for which this alert should be considered. Via the check box “select senders dynamically” you can decide:
Finally, click “Save” to persist the alert definition.
Alerts will arrive in the Focused Run Alert Inbox (Alert Management on the Focused Run Launchpad) with the Object Type “OpenKPI Sender”.
The ABAP report RCA_GS_SENDER_DELETION enables the user to delete senders from the Open KPI Store. This includes meta information, metric data and logs. It is irreversible.
Please make sure that the collector of the sender is disabled as well. As long as the collector is sending data and meta information to the Open KPI inbound processing, the sender will reappear in the scope selection.
The ABAP report RCA_GS_DYNATRACE enables the user to pull Dynatrace data into the Open KPI Store without creating an own collector. It is mainly meant to be executed as an background job.
After entering the Dynatrace URL, the environment UUID, name and the access token the user can click on the "Load Metric Definition" -button. This triggers the retrieval of the metric catalog from the Dynatrace environment, which is also used for the Dynatrace metrics selection F4-Help.
Additionally to the required fields, the user can also provide a tag defined in Dynatrace to narrow down the object selection on Dynatrace side. Dynatrace tags can be used, e.g., to map hosts and processes to Cloud Foundry spaces.
After loading the metric catalog the user can access the F4-Help to select every metric he wants to pull from the given Dynatrace environment.
Besides the available metric ID and description the F4-Help also shows the sender type this metric will be put into.
Attention: After the selection of a subset of metrics here and executing the program as a background job, it it not possible to change the selection for this environment, tag and sender type anymore. Any changes to the metric selection will result in data inconsistency! We recommend to delete any sender of the sender type in question before changing the metric subset!
If the user wants to maintain multiple environments and/or tags, he needs to create one background job per environment and tag combination.
Dynatrace collector results: