Application Check Metrics

How you can contact us:

Technical Assistance

Request product support from SAP
Non-Technical Assistance

Request non-product support or provide feedback on SAP Support Portal site

Application Check Metrics

Metric Name	Description	Available since
HTTP Health API	Measures the health of a cloud application specified by its URL. The cloud application implements an API. The API is called by a data collector running on a Simple Diagnostics Agent in the collection group. The data collector uses the API to extract KPIs (key performance indicators) from the cloud application – for example, availability of a cloud service belonging to the application, CPU usage of a cloud service, or disk usage of a cloud service.	FRUN 3.0 SP00
Prometheus	Measures the health of a cloud application specified by its URL. The cloud application implements a Prometheus API to provide monitoring data for the open-source Prometheus systems monitoring and alerting application. The Prometheus API of a cloud application is called by a data collector running on a Simple Diagnostics Agent in the collection group. The data collector uses the Prometheus API to extract KPIs (key performance indicators) from the cloud application. KPIs include, for example, the availability of a cloud service belonging to the application service.	FRUN 3.0 SP00
Health Push	A program executed periodically as a job in the SAP Focused Run system calls APIs on SAP Business Technology Platform (SAP BTP) to extract key performance indicators (KPIs) from SAP BTP, Neo environment. These are either KPIs that refer to Java applications running in the Neo environment or KPIs that refer to database systems running in the Neo environment. Examples of such KPIs include CPU load and OS memory usage. (Valid only for FRUN 3.0 FP02. In subsequent feature packs, this functionality is replaced by Cloud Service metrics of the type SAP BTP Neo.)	FRUN 3.0 FP02

Metric Name

Description

Available since

HTTP Health API

Measures the health of a cloud application specified by its URL. The cloud application implements an API. The API is called by a data collector running on a Simple Diagnostics Agent in the collection group. The data collector uses the API to extract KPIs (key performance indicators) from the cloud application – for example, availability of a cloud service belonging to the application, CPU usage of a cloud service, or disk usage of a cloud service.

FRUN 3.0 SP00

Prometheus

Measures the health of a cloud application specified by its URL. The cloud application implements a Prometheus API to provide monitoring data for the open-source Prometheus systems monitoring and alerting application. The Prometheus API of a cloud application is called by a data collector running on a Simple Diagnostics Agent in the collection group. The data collector uses the Prometheus API to extract KPIs (key performance indicators) from the cloud application. KPIs include, for example, the availability of a cloud service belonging to the application service.

FRUN 3.0 SP00

Health Push

A program executed periodically as a job in the SAP Focused Run system calls APIs on SAP Business Technology Platform (SAP BTP) to extract key performance indicators (KPIs) from SAP BTP, Neo environment. These are either KPIs that refer to Java applications running in the Neo environment or KPIs that refer to database systems running in the Neo environment. Examples of such KPIs include CPU load and OS memory usage.

(Valid only for FRUN 3.0 FP02. In subsequent feature packs, this functionality is replaced by Cloud Service metrics of the type SAP BTP Neo.)

FRUN 3.0 FP02

Additional Information

Custom Metric Analysis Pages

You can configure your own custom Metric Analysis pages for Application Check metrics. For more information, see here.

Collecting Metrics from SAP BTP Neo Environment

If you want to collect metrics from SAP Business Technology Platform, Neo environment, check out the setup here (FRUN 3.0 FP02).
For information on how to collect SAP BTP Neo KPIs in FRUN 3.0 FP03, see Configuration of Cloud Services.
Important: If you have SAP Focused Run 3.0 FP03, do not use the report RCA_GS_NEO_METRICS (from FRUN 3.0 FP02) for Health Monitoring.

Collecting Metrics from SAP Integration Suite

If you want to collect metrics from SAP Integration Suite, check out the following guide. It explains the necessary settings on SAP BTP and in the Health Monitoring app, check out the guide here (FRUN 3.0 FP02).
Important: If you have SAP Focused Run 3.0 FP03 and want to collect metrics from SAP Integration Suite, check out the following guide: Configuration of Cloud Services.

Error Codes

For an overview of error codes relating to Availability Metrics metrics and Application Check Metrics metrics (types: HTTP Health API and Prometheus), click here.

Parameters for Application Check Metrics

You can specify the following parameters for Application Check metrics:

Collection Frequency
For Application Check metrics of type HTTP Health API and Prometheus, the collection frequency is the time interval (in minutes, hours, or days) at which a Simple Diagnostics Agent measures the metric. For example, if you set a collection frequency of one minute, the Simple Diagnostics Agent measures the metric once each minute.

Thresholds
A threshold defines when a metric will receive a certain rating, such as Info (blue), Ok (green), Warning (yellow), Critical (red), or Fatal (red). If no threshold is defined for a metric, Health Monitoring uses the rating for the metric reported by the cloud service.

The types of threshold available depend on the type of metric:

Metric type: Status
- Available thresholds: Info Only, Status
Metric type: Performance
- Available thresholds: Info Only, Status, Numeric, Numeric (Critical)
Metric type: Quota
- Available thresholds: Info Only, Status, Numeric, Numeric (Critical)

The following threshold types are available:

Info Only: When you assign a threshold of the type Info Only to a metric, the rating of the metric that is reported by the cloud service is overwritten by the rating Info Only.
Status: When you assign a threshold of the type Status to a metric, the rating of the metric that is reported by the cloud service can be overwritten by a specified rating. For example, if the cloud service reports a Warning rating, you can specify in the threshold that the reported rating is overwritten by Critical.
You can also switch on Use delay and specify a delay in minutes before the rating of the metric is set to Critical. This means the rating of the metric is not set to Critical as soon as the threshold is reached, but only after the specified delay.
Numeric: When you assign a threshold of the type Numeric to a metric, you specify a limit at or above which the rating of the metric is set to Warning and a second limit at or above which the rating of the metric is set to Critical. For each limit, you must also specify the condition for setting the rating – for example, if the value of the metric is below or above the limit. Additionally, you can switch on Use delay and specify a delay in minutes before setting the rating of the metric to Critical. This means the rating of the metric is not set to Critical as soon as the limit is reached, but only after the specified delay.
When you specify a limit for a metric of the type Performance, you have to use the metric value when defining a limit.
When you specify a limit for a metric of the type Quota, you can use its metric value, metric limit, or metric usage to define the limit.

As of SAP Focused Run 4.0, you can also define additional thresholds. See Additional Thresholds for Cloud Service and Application Check Metrics in the Health Monitoring App.

Example of a Performance metric
The rating of the metric cpu.usage is set to Warning when the value of the metric is above 50%. The rating of the metric cpu.usage is set to Critical when the value of the metric is above 80%.

Example of a metric of the type Quota
The rating of the metric disk.usage is set to Warning when the usage is above 50%. The rating of the metric disk.usage is set to Critical when the usage is above 90%.

Numeric (Critical)
This threshold type offers similar functionality to the threshold of the type Numeric, with one exception: You can specify only one limit at or above which the rating of the metric is to be set to Critical.

Alerts (optional)
When you don't maintain a threshold, an alert is generated when the cloud service reports a metric status red (critical or fatal). When you maintain a threshold for a metric, an alert is generated when the defined threshold is reached. Alerts are displayed in the Health Monitoring and Alert Management applications.

The following Alert settings are available:

Alert Active
Set the switch to On to generate an alert when the metric rating is set to red. Set to Off to prevent alerts being generated.
Alert Name
Specify a name for your alert. Be sure to use a descriptive name that others can easily understand.
Notification Variant
Select an alert consumer variant of the type Notification to be informed when the metric turns red (for example, by e‑mail).
Outbound Variant
Select an alert consumer variant of the type Outbound Integration to create a support ticket in a ticketing system, for example.
Alert Category
Choose a category to categorize an alert so that you can display alerts by category in the Alert Management app.
Severity
Select a severity value from 0 (Very Low) to 9 (Critical).
Separate by Label
Create an alert for metrics with the specified label.
Alert Documentation
Describe the alert and provide any additional information that the user may need.

Alert Rules
An alert rule selects metrics of the destination. Select metrics by either their name or their label.
Use the Include table to select metrics for which alerts are created.
Use the Exclude table to select metrics for which no alerts are created.

Availability Alerts Generated from Application Check Metrics

Availability alerts can be generated from Application Check metrics (HTTP Health API and Prometheus). A metric is reported to Service Availability Management as an unplanned outage if the following prerequisites are met:

The metric has been assigned to a technical system.

An active service definition has been created for the technical system in Service Availability Management as explained here.