Crash and Diagnostic-File Monitoring for SAP (Configure)

⚙️ Configure Crash and Diagnostic-File Monitoring for SAP

Configure GermainUX to detect SAP-related process failures and diagnostic files using accessible logs, files, process status, browser telemetry, and custom parsers.

GermainUX can detect and analyze only the crash evidence made available through configured data sources. It does not automatically understand every SAP crash, ABAP short dump, or binary core file.

✅ Supported capabilities

Depending on the available telemetry, GermainUX can:

Capability

Detect that a monitored process or service stopped

Detect the creation of a diagnostic or crash file

Collect approved file metadata

Parse supported text-based diagnostic content

Collect exceptions from accessible application logs

Categorize recurring and new errors

Correlate events using timestamps and available identifiers

Associate browser activity with nearby backend events

Alert when a new or recurring failure occurs

Report crash and failure trends

🏗️ Components

Component

Purpose

Engine

Monitors processes, services, logs, files, supported databases, and HTTP endpoints

RUM JS

Provides browser-side sessions, errors, requests, freezes, and user actions

Code Profiler

Can capture exceptions in supported Java components when agent deployment is possible

JS Profiler

Provides browser-side JavaScript diagnostics; it does not analyze server crashes

The primary component for this page is the GermainUX Engine.

📋 Prerequisites

Before configuring crash monitoring:

Prerequisite

Deploy and start the GermainUX Engine.

Identify the processes, services, logs, and diagnostic directories to monitor.

Confirm that the Engine can reach the relevant hosts and files.

Create read-only credentials where possible.

Obtain representative examples of the diagnostic content.

Determine whether the files are text or binary.

Configure application and environment names.

Establish privacy and retention requirements.

Define which events should generate alerts.

RUM JS is optional but useful when you want to examine browser activity near the time of a backend failure.

🔍 Identify available crash evidence

Document the sources available in the target SAP environment.

Source

Potential evidence

Process or service status

Process stopped, service unavailable, unexpected instance count

Application log

Exception, fatal error, shutdown, startup, or termination event

Diagnostic directory

New dump, trace, or diagnostic file

Text-based dump export

Error type, timestamp, stack, component, or message

Java application log

Unhandled exception, out-of-memory condition, or process failure

HTTP endpoint

Application unavailable or returning an invalid result

RUM session

User actions, browser errors, requests, or freezes near the failure

Synthetic scenario

Login, application, or workflow no longer completes

The exact sources depend on the SAP product and hosting model.

☁️ SAP Commerce Cloud

For SAP Commerce Cloud, formerly SAP Hybris, available monitoring depends on whether the environment is SAP-managed or customer-controlled.

🖥️ Customer-controlled Commerce environment

GermainUX may monitor:

Monitored item

Java process availability

Java application logs

Web-server logs

Accessible diagnostic files

Host CPU, memory, and disk

HTTP and OCC endpoints

Supported databases

Storefront browser errors

Synthetic commerce journeys

The GermainUX Code Profiler may capture supported Java exceptions when:

  • The runtime is supported.

  • Agent installation is permitted.

  • The organization controls the Java process.

  • The deployment has been approved.

🔒 SAP-managed Commerce Cloud

Direct access to servers, JVMs, logs, and diagnostic files may be restricted.

In that case, GermainUX monitoring is limited to the data sources made available to the customer, such as:

Available source

Storefront RUM

Browser errors and requests

Accessible APIs

Exported logs

Available observability integrations

Synthetic scenarios

Do not claim server- or JVM-level crash monitoring until access has been confirmed.

🖱️ Configure process and service monitoring

Use the Engine to monitor supported operating-system processes or services associated with the SAP environment.

Configure:

Setting

Server

Operating system

Engine

Credentials

Process or service name

Expected running state

Expected instance count

Collection frequency

Warning condition

Critical condition

Application

Environment

Potential conditions include:

  • Process missing

  • Service stopped

  • Instance count below expected

  • Repeated restart

  • Process unavailable after maintenance

A stopped process indicates an availability condition. It does not, by itself, identify the root cause.

📁 Configure log-based crash detection

Use an accessible log when the application records failure evidence as text.

⚙️ Configure the log source

Define:

Log setting

Host

Exact path

File pattern

Encoding

Timestamp format

Time zone

Rotation behavior

Multiline rules

Parser

Application and environment

Privacy rules

Polling interval

warning Configure failure patterns

Potential patterns include:

  • Fatal exception

  • Unhandled exception

  • Process terminated

  • Out-of-memory condition

  • Startup failure

  • Service shutdown

  • Repeated restart

  • Critical integration failure

Use patterns validated against real examples from the target environment.

Avoid generic keywords such as error or exception without context; they can produce large numbers of false positives.

🗂️ Configure diagnostic-directory monitoring

Use a directory monitor to detect new diagnostic files.

Configure:

Setting

Description

Name

Descriptive monitor name

Engine

Engine that checks the directory

Monitored server

Host containing the directory

Path

Exact approved directory

File pattern

Diagnostic files to include

Subdirectories

Whether nested directories are included

Existing files

Whether files already present are processed

Empty files

Whether zero-length files are included

Polling interval

How frequently the directory is checked

Application

Associated SAP application

Environment

Associated environment

Avoid broad paths that contain unrelated files.

📃 File metadata

Even when the file content cannot be parsed, GermainUX can use approved metadata such as:

Metadata

File name

Path

Size

Creation time

Modification time

Host

Application

Environment

This can indicate that a diagnostic artifact was created without claiming to understand its contents.

📄 Configure diagnostic-file parsing

Use a parser only when the file format is supported or a custom parser has been implemented and tested.

image-20260829-162400.png

📄 Text-based files

A generic or custom parser may extract:

Field

Timestamp

Error type

Severity

Component

Message

Stack trace

Error code

Host

Process

Thread

Correlation identifier

⛔ Binary files

Do not ingest binary core files as ordinary text logs.

GermainUX can detect their creation and collect metadata, but content analysis requires a compatible external tool or purpose-built parser.

📃 ABAP short dumps

GermainUX does not natively retrieve or interpret ABAP short dumps merely because SAP monitoring is enabled.

ST22 or other ABAP diagnostic data can be analyzed only when it is:

  • Exported through an accessible format

  • Retrieved through an approved integration

  • Supplied to GermainUX

  • Parsed by a compatible custom or supported parser

☕ Configure Java exception monitoring for SAP Commerce Cloud

For a supported, customer-controlled Java runtime, GermainUX may collect exceptions through:

  • Java application logs

  • Code Profiler instrumentation

  • Process monitoring

  • HTTP availability checks

Potential Java failure evidence includes:

  • Unhandled exception

  • Out-of-memory error

  • Thread failure

  • Application startup failure

  • Process termination

  • Repeated restart

  • Failed downstream request

Code Profiler availability depends on runtime support and permission to install the agent.

🌐 Configure browser-side evidence

When RUM JS is deployed, GermainUX can capture the browser activity preceding or surrounding a user-visible failure.

Available evidence can include:

Evidence

User action

Logical page

JavaScript error

Unhandled promise rejection

Failed request

Resource error

Browser freeze

Session Replay

Application message

This evidence can show what the user experienced. It does not prove that the user action caused a backend process to crash.

🔗 Configure correlation

GermainUX can associate evidence when compatible identifiers or timing are available.

Potential correlation attributes include:

Attribute

Application

Environment

Host

Timestamp

User

RUM session

Request identifier

Correlation identifier

Transaction identifier

Process or service

🆔 Identifier-based correlation

Use a shared request or correlation identifier when available. This provides stronger evidence than time proximity alone.

⏰ Time-based correlation

Time-based correlation can identify potentially related events, such as:

  1. User performs an action.

  2. Browser request fails.

  3. Application log records a fatal exception.

  4. Monitored process stops.

  5. Diagnostic file appears.

This sequence supports investigation but does not automatically prove causation.

Ensure that browser, Engine, SAP, server, and database clocks are synchronized.

🏷️ Configure categorization

Go to:

Germain Workspace -> Settings -->Analytics -> Categorization

Categorize failures using stable attributes such as:

  • Error type

  • Normalized message

  • Stack signature

  • Error code

  • Component

  • Process

  • File type

Remove variable values such as:

  • Timestamp

  • User ID

  • Session ID

  • Request ID

  • Memory address

  • Thread ID

  • Dynamic business identifier

  • Generated file suffix

🔎 Exact and fuzzy matching

Where the parsed data supports it:

  • Use exact matching for stable attributes that must be identical.

  • Use fuzzy matching for normalized messages or stack information that can vary slightly.

Categorization can help distinguish:

  • New failure categories

  • Recurring failures

  • Increasing failures

  • Failures introduced after a release

  • Similar failures across multiple hosts

Categorization quality depends on the fields successfully extracted from the source.

image-20250704-123757.png
image-20220102-112417.png

📈 Configure KPIs

Potential KPIs include:

KPI

Description

Process Unavailable

Monitored process is not running

Service Unavailable

Monitored service is stopped

Diagnostic File Created

New matching file detected

Fatal Log Event

Configured fatal pattern detected in a log

Java Exception

Supported Java exception collected

Browser Error

Browser-side failure associated with a user session

Synthetic Failure

Synthetic SAP scenario did not complete

HTTP Unavailable

Configured endpoint did not return an acceptable result

Failure-Affected Users

Distinct monitored users associated with the failure

Failure Category

Categorized group of similar failures

Create only KPIs backed by actual configured data sources.

📊 Configure dashboards

Go to:

Germain Workspace → Settings -> Dashboards -> All

Search for applicable SAP, availability, error, or technology dashboards, or create a custom dashboard.

Recommended views include:

  • Failures over time

  • New versus recurring categories

  • Failures by application

  • Failures by environment

  • Failures by host

  • Process and service availability

  • Java exceptions

  • Diagnostic files created

  • Affected users and sessions

  • Failures by release

  • Related synthetic failures

Provide drill-through access to the underlying evidence and related sessions where available.

🔔 Configure alerts

Create alerts for actionable conditions such as:

  • Critical process stopped

  • Required service unavailable

  • New diagnostic file detected

  • New fatal error category

  • Failure volume increased

  • Java process restarted repeatedly

  • HTTP endpoint unavailable

  • Synthetic scenario failed

  • Multiple users affected by the same failure

Use:

  • Consecutive-failure thresholds

  • Deduplication

  • Categorization

  • Cooldown periods

  • Maintenance periods

  • Warning and critical severities

Avoid generating one alert for every repeated log line.

📃 Configure reports

Schedule reports for:

  • Failure trends

  • New and recurring categories

  • Failures by host or application

  • Process availability

  • Java exception trends

  • Diagnostic-file activity

  • Affected-user counts

  • Failures introduced after releases

  • Resolution and recurrence

🔏 Privacy and retention

Diagnostic content can contain:

  • User identifiers

  • Business-document identifiers

  • File paths

  • Hostnames

  • SQL fragments

  • Request data

  • Authentication information

  • Personal or confidential data

Configure:

  • Field masking

  • Pattern-based redaction

  • Attribute exclusion

  • File-content restrictions

  • Retention

  • Role-based access

  • Export restrictions

Do not collect complete diagnostic content unless it is required and approved.

✅ Validate the configuration

⚙️ Process and service validation

Confirm that:

  • The intended process or service is monitored.

  • Its expected state is correct.

  • A safe test condition produces the correct KPI.

  • Recovery clears or updates the condition.

📂 File detection validation

Confirm that:

  • Only matching files are detected.

  • Existing files are handled as intended.

  • A new test file creates one event.

  • Restarts do not duplicate previously processed files.

  • Rotation behavior is correct.

🧪 Parser validation

Confirm that:

  • Timestamp and time zone are correct.

  • Multiline data remains one event.

  • Error type and severity are extracted correctly.

  • Variable values are normalized.

  • Sensitive data is protected.

  • Unsupported binary data is not treated as text.

🔍 Correlation validation

Confirm that:

  • Related evidence shares a validated identifier or plausible time relationship.

  • Unrelated events are not automatically joined.

  • Session Replay is linked only when an appropriate session exists.

  • The analysis does not imply causation without supporting evidence.

🚫 Limitations

GermainUX does not automatically:

  • Profile ABAP execution

  • Retrieve ABAP short dumps

  • Interpret every SAP diagnostic format

  • Parse arbitrary binary core files

  • Determine the root cause from file creation alone

  • Prove that a particular user action caused a backend crash

  • Correlate events without compatible identifiers or validated rules

  • Access restricted SAP-managed cloud infrastructure

These capabilities require accessible telemetry and, in some cases, a custom integration or parser.

ℹ️ Get More Information

GermainUX can help determine which monitoring, analytics and automation capabilities are appropriate for your SAP environment.

Contact GermainUX Support.

Feature Availability: 2022.1 or later