BTP Application Stats Monitor

BTP Application Stats Monitor

Overview

The BTP Application Stats Monitor provides comprehensive monitoring of SAP Business Technology Platform (BTP) Cloud Foundry applications. It tracks application health, resource usage, and instance status in real-time, allowing you to proactively detect and respond to performance issues or failures.

Prerequisites

BTP Cloud Foundry API access
Valid BTP credentials with permissions to:
- List applications (/v3/apps)
- Read process statistics (/v3/processes/{guid}/stats)
Network connectivity from the monitoring system to BTP API endpoints

API Endpoints Used

Endpoint	Purpose
POST /oauth/token	Authentication (OAuth2 token generation)
GET /v3/apps	List all applications (wildcard mode)
GET /v3/processes/{guid}/stats	Retrieve instance statistics for an application

Key Features

Metrics Collection

The monitor collects the following metrics for each application:

Running Instances - Number of healthy, operational instances
Crashed Instances - Number of failed instances
Memory Used (MB) - Total memory consumption across all running instances
Disk Used (MB) - Total disk space consumption across all running instances
CPU Usage (%) - Average CPU utilization across all running instances

Alarm Capabilities

Application State Monitoring - Detect when apps are not in the expected state (e.g., STOPPED, CRASHED)
Crashed Instance Detection - Alert when the number of crashed instances exceeds a threshold
Memory Usage Alarms - Warning and Critical thresholds for memory consumption
Disk Usage Alarms - Warning and Critical thresholds for disk consumption
CPU Usage Alarms - Warning and Critical thresholds for CPU utilization

Wildcard Support

Monitor all applications in your BTP space automatically by using * as the app name. The monitor will:

Automatically discover all applications in your BTP Cloud Foundry space
Monitor each application individually
Dynamically adapt to new or removed applications

How It Works

Data Collection Process

Authentication: The monitor authenticates to the BTP Cloud Foundry API using OAuth2 with cached token management
Application Discovery (wildcard mode): Retrieves all applications from /v3/apps endpoint
Stats Collection: For each application, calls /v3/processes/{guid}/stats to gather instance-level statistics
Data Aggregation: Combines data from all instances to calculate totals and averages
Alarm Evaluation: Compares collected metrics against configured thresholds
Metrics Storage: Stores collected metrics for historical tracking and reporting

Application State Determination

The overall application state is determined as follows:

RUNNING - At least one instance is running (even if some are crashed)
CRASHED - All instances are crashed
STOPPED - No instances are running (and none are crashed)

Note: If you have 2 instances where 1 is RUNNING and 1 is CRASHED, the application is considered RUNNING because it's still serving traffic.

Resource Aggregation

Memory & Disk: Summed across all running instances only (crashed instances are excluded)
CPU: Averaged across all running instances only
Quotas: Summed across all instances (running + crashed) to calculate usage percentages

Configuration

Connection Settings

Create a Web Service Connector pointing to your BTP Cloud Foundry API endpoint
- Example: https://api.cf.eu10-123.hana.ondemand.com
Configure authentication credentials (user profile with BTP credentials)

Monitor Configuration

Adding Applications to Monitor

There are two ways to add applications to the monitor:

Method 1: Load BTP Apps (Recommended)

Open the BTP Application Stats monitor configuration
Click the “Load BTP Apps” button in the toolbar
The system will:
- Connect to your BTP Cloud Foundry API
- Retrieve all available applications
- Populate the table with application names
Select which applications to monitor by checking the Active checkbox
Configure alarm thresholds for each application individually

Benefits:

No need to manually find application GUIDs
Shows all available applications in your BTP space
Pre-fills application names automatically
Allows selective monitoring of specific applications

Method 2: Wildcard Mode (Monitor All)

Set App Name to *
The monitor will automatically:
- Discover all applications at runtime
- Monitor every application using the same configuration
Adapt to new or removed applications without reconfiguration

Benefits:

Zero configuration for comprehensive coverage Automatically monitors new applications Single configuration for all apps

Basic Settings

Field	Description	Default
Active	Enable/disable monitoring for this application	`true`
Schedule	Collection frequency (minutes)	`5`
Timeout	Maximum execution time (seconds)	`120`
App Name	Application name or * for all apps	*

State Monitoring

Field	Description	Default
State Alarm	Enable state monitoring	`true`
Expected State	Expected application state	`RUNNING`
State Check Mode	`EQUALS` or `NOT_EQUALS`	`NOT_EQUALS`
State Severity	Alarm severity (1-5)	`4` (Critical)

Check Mode Examples:
- NOT_EQUALS + RUNNING → Alarm if app is NOT running
- EQUALS + CRASHED → Alarm if app IS crashed

Crashed Instances Monitoring

Field	Description	Default
Crashed Instances Alarm	Enable crashed instance detection	`true`
Crashed Instances Threshold	Maximum acceptable crashed instances	`0`
Crashed Instances Severity	Alarm severity	`4` (Critical)

Memory Monitoring

Field	Description	Default
Memory Alarm	Enable memory monitoring	`true`
Memory Warning %	Warning threshold	`80%`
Memory Critical %	Critical threshold	`90%`

Disk Monitoring

Field	Description	Default
Disk Alarm	Enable disk monitoring	`true`
Disk Warning %	Warning threshold	`80%`
Disk Critical %	Critical threshold	`90%`

CPU Monitoring

Field	Description	Default
CPU Alarm	Enable CPU monitoring	`true`
CPU Warning %	Warning threshold	`80%`
CPU Critical %	Critical threshold	`90%`

General Settings

Field	Description	Default
Auto Clear	Automatically clear alarms when conditions normalize	`true`
Metric	Enable metrics collection	`true`

Usage Examples

Example 1: Load and Monitor Specific Applications

Click “Load BTP Apps”
Select only production apps (e.g., prod-api, prod-web, prod-worker)
Configure stricter thresholds for production:

   Memory Warning: 70%
   Memory Critical: 85%
   CPU Warning: 60%
   CPU Critical: 80%

* Leave development apps inactive

Example 2: Monitor All Applications with Wildcard

App Name: *
State Alarm: Enabled
Expected State: RUNNING
State Check Mode: NOT_EQUALS

→ Monitors all apps in your BTP space and raises alarms if any app is not running.

Example 3: Mixed Approach

Use wildcard (*) with default thresholds for general coverage
Add specific critical apps via Load BTP Apps with custom thresholds
Both configurations can coexist in the same monitor

Example 4: Monitor Only Application State

App Name: background-worker
State Alarm: Enabled
Memory Alarm: Disabled
Disk Alarm: Disabled
CPU Alarm: Disabled
Crashed Instances Alarm: Disabled

→ Only monitors if the application is running, ignoring resource usage.

Collected Metrics

The BTP Application Stats monitor collects 5 key performance metrics for each monitored application. These metrics are stored with dimensional tags for easy filtering and analysis.

Metric Types

Metric Name	Unit	Description	Example
running_instances	count	Number of healthy, operational instances	2
crashed_instances	count	Number of failed or crashed instances	0
memory_used_mb	MB	Total memory consumption across all running instances	256.5
disk_used_mb	MB	Total disk space consumption across all running instances	512.3
cpu_usage_percent	%	Average CPU utilization across all running instances	15.67

Metric Format

All metrics follow this naming convention:

promonitor.btp_app_stats.<metric_name> app_name:<app_name>;host:<api_endpoint>;

Alarm Examples

State Alarm

BTP App my-app is in state STOPPED (expected state: RUNNING)

Crashed Instances Alarm

BTP App my-app has 2 crashed instance(s) (threshold: 0)

Memory Alarm

BTP App my-app memory usage is 92.5% [CRITICAL] (thresholds: warning=80%, critical=90%)

CPU Alarm

BTP App my-app CPU usage is 85.23% [WARNING] (thresholds: warning=80%, critical=90%)

Best Practices

Use “Load BTP Apps” to easily discover and select specific applications to monitor
Use Wildcard Mode for comprehensive coverage when you want to monitor everything
Combine both approaches - Use wildcard for general monitoring and add specific apps with custom thresholds
Adjust thresholds based on your application's normal behavior patterns
Enable Auto Clear to automatically resolve alarms when conditions improve
Set appropriate schedules - 5 minutes is recommended for production monitoring
Monitor crashed instances separately from state to distinguish between partial and total failures
Review metrics regularly to identify trends and optimize resource allocation

Troubleshooting

"Load BTP Apps" Button Doesn't Work

Verify BTP credentials are correct in the Web Service Connector
Check network connectivity to BTP API
Ensure the connector is properly configured and saved
Review logs for authentication errors

No Data Collected

Verify BTP credentials are correct
Check network connectivity to BTP API
Ensure the application GUID is correct (for specific app monitoring)
Review logs for authentication errors

Metrics Show Zero

Application may have no running instances
All instances might be crashed or stopped
Check application status in BTP Cockpit

Alarms Not Clearing

Verify Auto Clear is enabled
Check if the condition has actually normalized
Review alarm threshold configurations

Table of Contents