OpenKPI Store Step-by-Step Guide

This section is intended as a step-by-step guide to get started with an OpenKPI project. The goal is to run a proof-of-concept and get an idea on the outcome without major efforts, in particular without development efforts. As last step to productize use of the OpenKPI store, though, still some kind of script/code needs to be developed to collect your custom data.

To illustrate the different steps, we use a simple example: Assume we want to monitor two metrics for each host in our landscape: CPU usage on host level and the amount of free space in each file system of the host. Note that these metrics are covered already by standard System Monitoring content. We pick it here anyway for simplicity.

Decide on the Data Model

As a first step you have to make up your mind on the data model. See the reference section on the data format below for details. We suggest writing down at least two concrete example sender objects.

Sender Type: It is assumed that you want to collect metrics for some kind of information technology objects, e.g. host, databases, printers, switches. Objects of the same category are expected to share the same properties and metrics should be assigned the same sender type. Each of these objects is called “sender”.

Sender ID: Every sender must have a unique identifier. This identifier must remain constant for the lifetime of a sender. This can be a unique part of a name (e.g. physical host name), an installation number, a MAC address, or a GUID that is generated once and then remains permanently assigned to the object (e.g. stored in a file on the associated host).

Sender Name: A clear label for the sender.

Sender Attributes: You can assign up to five attributes to a sender. Typical use cases may be properties of the IT object (IP address, physical location, host name for a database, database brand, etc.)

Metrics: Even though metrics must not be defined up-front it makes sense to list them. Note that internally metrics are defined by index: To avoid confusion Payload should always contain all metrics. Set a reasonable unit for each metric. Note that only numerical values are supported.

Dimensions: For each metric you can define one or more dimensions. The set of dimensions is shared across all metrics, but dimension values can be empty for any metric.

Example: Sender Type: „MyHost“
  • Sender ID: fully qualified host name in lower case
  • Sender name: unqualified host name
  • Sender attributes: domain, IP address, operating system
  • Metrics and dimensions: CPU (%), file system free (%), dimension = file system name
Example: Sender Type: „MyDatabase“
  • Sender ID: fully qualified host name + “_” + database SID
  • Sender name: database SID
  • Sender attributes: database vendor, host name
  • Metrics: last backup age (days), size (GB)
Non-IT Example: Sender Type “Weather Station“
  • Sender ID = Sender name: name of weather station
  • Sender attributes: latitude, longitude, elevation, operator
  • Metrics: temperature (°C), Humidity (%), Barometric pressure (hPa), WindSpeed (km/h) (no dimensions)
Non-IT Example: Sender Type “DAX“ (stock index)
  • Sender ID = ISIN
  • Sender Name = Company name
  • Sender attributes: branch, country, company_url
  • Metrics: stock price (USD), profit_per_share (USD)

Prepare Meta Data

Register Sender Type and Set Limits

In the System Analysis application, open the configuration panel and expand the section “OpenKPI Settings”. In the first panel click “+” to register a new sender type. Fill in the estimated limits:

  • SenderType / Pattern: Fill in the exact sender type here
  • Pattern: do not check
  • Maximum Number of Senders: Expected number of different objects of this type for which data will be reported
  • Maximum Number of Metrics: Expected number of different metrics in this sender type
  • Maximum Number of requests/hour: Expected number of POST requests
  • Maximum number of datapoints/request: Expected number of values in each request. Strictly speaking the maximum number of data points per sender is considered here: Since you can combine an array of data for multiple senders in a single POST request this can make a difference.

In general, these limits are intended to avoid denial-of-service attacks. As soon as one of the limits is reached corresponding requests will be blocked and a self-monitoring alert is triggered. There is no need to set these limits too strictly, and there is no resource pre-allocation for the limits. To avoid additional obstacles, we suggest setting these limits rather generous than too strict.

Example “MyHost”

  • SenderType: MyHost
  • Pattern: No
  • Maximum Number of Senders: 200 (assume we currently have 57 hosts)
  • Maximum Number of Metrics: 2
  • Maximum Number of requests/hour: 2400 (if we collect every 5 minutes for each host separately we expect 12 * 57 requests)
  • Maximum number of datapoints/request: 100 (if we expect <= 99 file systems per host and since we send for each host separately)

Set Attribute Names

To get additional guidance, e.g. in OpenKPI scope selection, you can maintain the attribute names for your sender. Again in the System Analysis application, in the configuration panel and section “OpenKPI Settings”, use the second panel to enter “Sender Type Attributes”: Select the sender type that you registered and fill in attribute names  as you like. For unused attributes, keep the fields empty.

Example “MyHost”

  • SenderType: MyHost
  • Attribute 1: Domain
  • Attribute 2: IP Address
  • Attribute 3: Operating System
  • Attribute 4 and 5: <empty>

Set LMDB Association

If you would like to connect the OpenKPI charts and dashboards to the LMDB-based scope selection you can pre-define mappings of the sender name and sender attributes to LMDB properties.

Example “MyHost”

  • SenderType: MyHost
  • Sender: {HOST.NAME}  (note: does not fully match to FQDN)
  • Namespace: <empty>
  • Attribute 1-5: <empty>

Sample Data

Send Example Request

Use the OpenKPI Validator (since SAP Focused Run 3.0 SP00) to send some example data. If you do not have the validator yet: compose a JSON payload manually / with your favorite tool.

Create Dashboard

Create a dashboard to visualize the example data. Check if the representation suffices your needs.

Alerting

Configure Alerting

(since SAP Focused Run 3.0 SP00)

Configure an alert for one of the metrics that you designed in your data model with reasonable thresholds.

Test Alerting

(since SAP Focused Run 3.0 SP00)

Use the OpenKPI Validator again to send another example request. Choose values that will breach the thresholds and thus trigger an alert. Switch to the Alert Inbox (Alert Management) to see if the alert arrives in the expected format (Managed Object Type OpenKPI Sender).

Productize

Develop Automated Data Collection

Once you come to the insight that your data model fits your needs it is time to automate: Create a script / application that collects data and produces JSON out of it automatically. You can decide if you want to distribute the script to each object, e.g. each host, and send data individually for each sender, or if you want to collect data centrally and send it even with a single request for multiple senders.

Clean Up Broken Test Data

Your experiments may have created some faulty records, e.g. because you changed the sender type multiple times or because you changed other things. To clean this up use ABAP report RCA_GS_SENDER_DELETION.