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.
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.
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:
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.
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.
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.
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 a dashboard to visualize the example data. Check if the representation suffices your needs.
(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.
(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).
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.
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.