SAP monitoring for S/4HANA, HANA and NetWeaver
Bring SAP into the same view as the rest of your stack: connect SAP HANA through the OpenTelemetry Collector, NetWeaver hosts through Prometheus exporters and business data through SAP APIs.
Why monitor SAP with Obseria
Open integration paths
SAP HANA metrics flow through the saphana receiver of the OpenTelemetry Collector; no proprietary connector is required.
SAP next to everything else
See HANA, application servers, VMs and the non-SAP services around them in one topology with TopoGraph.
Technical and business view
Combine database and system health with business process data you pull from SAP APIs.
SAP components you can connect to Obseria
- SAP HANA. Memory, CPU, connections, blocked transactions, backups and replication via the OpenTelemetry Collector saphana receiver.
- SAP NetWeaver application servers. Start Service processes, enqueue server and dispatcher queues via community Prometheus exporters such as sap_host_exporter.
- SAP S/4HANA business processes. Order, delivery or invoice volumes and backlogs pulled from SAP OData APIs into Business Observability.
- SAP Java stack and BTP Java apps. JVM-based SAP workloads and custom extensions instrumented with the OpenTelemetry Java agent where supported.
- Hosts and virtualization. Linux hosts and VMware VMs running SAP, monitored by the Obseria Agent and agentless integrations.
- Interfaces and middleware. HTTP, RFC gateways and message flows around SAP, seen through the services that call them.
The SAP signals that matter
Obseria collects these values automatically and shows them in ready-made dashboards and alerts.System resources
Shows how much memory and processing power your SAP database uses, so bottlenecks are addressed before users notice.
User activity and blockages
Tells you how many users are connected and whether business transactions are stuck waiting on each other.
Backup and recovery
Reveals whether backups are current and your standby system is in sync, protecting critical business data.
Warnings and licenses
Highlights open system warnings and upcoming license expiry, so no avoidable outage catches your business off guard.
Show all 9 metrics in detail
| Metric | Unit | What it tells you |
|---|---|---|
saphana.service.memory.used | By | Memory used per HANA service; the core indicator for an in-memory database. |
saphana.column.memory.used | By | Memory used by column store tables, usually the largest consumer. |
saphana.cpu.used | ms | CPU time spent by the HANA instance, to detect saturation. |
saphana.connection.count | {connections} | Current connections, by status, to spot connection storms. |
saphana.transaction.blocked | {transactions} | Transactions waiting for a lock; growth means contention. |
saphana.alert.count | {alerts} | Current HANA alerts, by rating, from the database itself. |
saphana.backup.latest | s | Age of the latest backup; alert when it exceeds your backup policy. |
saphana.replication.backlog.time | us | System replication backlog time, critical for disaster recovery. |
saphana.license.expiration.time | s | Time until the HANA license expires. |
Set up SAP monitoring in minutes
- Step 1
Create a monitoring user
Create a dedicated, read-only HANA database user with the monitoring privileges described in the receiver documentation.
- Step 2
Run the OpenTelemetry Collector
Configure the saphana receiver and, for NetWeaver hosts, a Prometheus scrape of your exporter; export via OTLP to Obseria.
- Step 3
Add business signals
Pull process KPIs from SAP OData APIs with an Obseria Automation workflow or your own job and send them as metrics or events.
receivers:
saphana:
endpoint: "hana-db01:30015"
username: ${env:HANA_MONITOR_USER}
password: ${env:HANA_MONITOR_PASSWORD}
collection_interval: 60s
prometheus:
config:
scrape_configs:
- job_name: sap-host-exporter
static_configs:
- targets: ["sap-app01:9680"]
exporters:
otlphttp:
endpoint: ${env:OBSERIA_OTLP_ENDPOINT}
headers:
Authorization: "Bearer ${env:OBSERIA_TOKEN}"
service:
pipelines:
metrics:
receivers: [saphana, prometheus]
exporters: [otlphttp]Out of the box
Dashboards, alerts and SLOs that are ready the moment data arrives.
- SAP HANA overview: memory, CPU, connections
- Alert on HANA memory near allocation limit
- Alert on backup age above policy
- System replication backlog
- Business process volumes from SAP APIs
SAP monitoring: what matters
Why SAP monitoring belongs in your observability platform
SAP systems run the processes that companies cannot afford to stop: order-to-cash, procure-to-pay, production planning and finance. At the same time, SAP rarely runs alone. Web shops, mobile apps, integration platforms and custom microservices call into S/4HANA, and SAP depends on databases, hosts and networks underneath. When a checkout slows down, the cause may be a HANA memory bottleneck, a busy application server or a service in front of SAP. SAP monitoring in an isolated tool cannot answer that question; it has to sit next to the rest of your telemetry.
SAP ships its own administration and monitoring tools, and they remain the right place for deep basis work. The goal of SAP observability in Obseria is different: bring the key health signals of SAP into the same data model, topology and alerting as everything else, using open and documented integration paths.
SAP signals that matter
SAP HANA
For an in-memory database, memory is the first thing to watch. The OpenTelemetry Collector saphana receiver exposes saphana.service.memory.used, saphana.column.memory.used and the configured limits, plus CPU time, connections, blocked transactions, alerts, backup age and system replication backlog. Together they cover capacity, contention and resilience.
NetWeaver and ABAP application servers
On the application layer, work process queues and the enqueue server show whether the system can keep up with user and batch load. Community Prometheus exporters such as sap_host_exporter read this information from the SAP Start Service and expose it for scraping. Host metrics from the Obseria Agent add CPU, memory, disk and network for each instance.
Business processes
Technical health is only half the picture. S/4HANA exposes business objects through OData APIs. Pulling volumes and backlogs, for example open sales orders or blocked invoices, and sending them to Obseria as metrics lets you see when a process slows down before users report it.
Common SAP performance problems and how to detect them
- HANA memory pressure: used memory approaching the effective limit leads to unloads and out-of-memory dumps. Alert on the ratio, not on absolute values.
- Lock contention: rising
saphana.transaction.blockedduring batch windows points to competing jobs or long-running transactions. - Exhausted work processes: long dispatcher queues mean dialog users wait even though the database is healthy.
- Replication lag: a growing replication backlog weakens your disaster recovery position without any visible user impact.
- Missing backups: backup age is a simple metric that prevents a serious incident.
- Slow interfaces: services that call SAP show rising client latency; traces on the calling side make the dependency explicit.
Watch the batch windows
Many SAP issues start at night, when closing runs, data loads and backups overlap. Compare HANA memory, CPU and blocked transactions for the same time windows over several weeks to see whether a run slowly takes longer before it spills into business hours.
Best practices for SAP performance monitoring
- Use a dedicated monitoring user with read-only privileges for every HANA connection.
- Run the OpenTelemetry Collector close to the SAP landscape and keep credentials in environment variables or a secret store.
- Tag every signal with the SAP system ID and landscape tier, for example production or quality, as resource attributes.
- Instrument the services that call SAP, so latency at the boundary is measured from the consumer side.
- Define a small set of business KPIs per process and alert on deviations, not on every technical metric.
How Obseria helps with SAP monitoring
Obseria ingests SAP telemetry through OpenTelemetry and Prometheus, the same paths you use for the rest of your stack, and stores it in Obseria Lake together with traces, logs and infrastructure metrics. TopoGraph links SAP hosts, databases and the services that call them. Anomaly detection learns normal patterns for HANA memory, connections and business volumes. When an incident occurs, Obseria Intelligence correlates SAP signals with deployments, infrastructure changes and upstream services and explains the probable root cause with its chain of evidence. With data residency in the EU and certifications such as ISO 27001 and BSI C5, SAP-related data can stay within your compliance boundaries.
Related integrations
Related capabilities
Database Monitoring
Find the slow query behind a slow endpoint. Obseria links database metrics, query performance and logs to the traces and services that call them.
Learn moreAnomaly Detection
Obseria Intelligence learns the normal rhythm of every service, flags real deviations instead of threshold noise and groups related anomalies into one problem with a probable root cause.
Learn moreService Catalog
Every service, its owner, its dependencies and its SLOs in one place, discovered automatically from traces and topology and enriched with the metadata your teams provide.
Learn moreLearn more
What is observability?
What is observability? Learn how metrics, logs, traces and profiles let you understand any system state, how it differs from monitoring, and how to start.
What is root cause analysis (RCA)?
What is root cause analysis? The RCA process for software incidents, 5 Whys, fishbone and fault tree methods, a worked example and how AI speeds up RCA.
SAP monitoring FAQ
No. Obseria connects SAP through open paths: the OpenTelemetry Collector saphana receiver for HANA, Prometheus exporters for NetWeaver hosts, SAP APIs for business data and the Obseria Agent for hosts.
The saphana receiver exposes memory, CPU, connections, transactions, alerts, backups, replication, licenses, volumes and schema statistics. You can disable metrics you do not need in the receiver configuration.
Transaction-level ABAP data is not part of the open integration paths described here. You can collect work process and dispatcher statistics through exporters and pull business object data from SAP APIs.
Query S/4HANA OData APIs on a schedule, for example with an Obseria Automation workflow, and send the results to Obseria as metrics. Business Observability then tracks volumes and backlogs over time.
The receiver is part of the OpenTelemetry Collector contrib distribution and is currently marked alpha. Test it in a non-production landscape first and pin the Collector version you deploy.
Start monitoring SAP today
Connect SAP in minutes with OpenTelemetry or the Obseria Agent. Free for 14 days.