SAP-Monitoring für S/4HANA, HANA und NetWeaver
Holen Sie SAP in dieselbe Sicht wie den Rest Ihres Stacks: SAP HANA über den OpenTelemetry Collector, NetWeaver-Hosts über Prometheus-Exporter und Geschäftsdaten über SAP-APIs.
Warum SAP mit Obseria überwachen
Offene Integrationswege
SAP-HANA-Metriken fließen über den saphana-Receiver des OpenTelemetry Collector; ein proprietärer Connector ist nicht nötig.
SAP neben allem anderen
HANA, Applikationsserver, VMs und die umgebenden Nicht-SAP-Services erscheinen in einer gemeinsamen Topologie mit TopoGraph.
Technische und fachliche Sicht
Verbinden Sie Datenbank- und Systemzustand mit Prozessdaten, die Sie über SAP-APIs abrufen.
SAP-Komponenten, die Sie mit Obseria verbinden können
- SAP HANA. Speicher, CPU, Verbindungen, blockierte Transaktionen, Backups und Replikation über den saphana-Receiver des OpenTelemetry Collector.
- SAP-NetWeaver-Applikationsserver. Prozesse des Start Service, Enqueue Server und Dispatcher-Queues über Community-Exporter wie sap_host_exporter.
- Geschäftsprozesse in SAP S/4HANA. Auftrags-, Liefer- oder Rechnungsvolumen und Rückstände aus SAP-OData-APIs in Business Observability.
- SAP-Java-Stack und BTP-Java-Apps. JVM-basierte SAP-Workloads und eigene Erweiterungen, wo unterstützt, mit dem OpenTelemetry Java Agent instrumentiert.
- Hosts und Virtualisierung. Linux-Hosts und VMware-VMs mit SAP, überwacht vom Obseria Agent und agentenlosen Integrationen.
- Schnittstellen und Middleware. HTTP-, RFC-Gateways und Nachrichtenflüsse rund um SAP, sichtbar über die aufrufenden Services.
Die SAP-Kennzahlen, auf die es ankommt
Obseria erfasst diese Werte automatisch und zeigt sie in fertigen Dashboards und Alerts.Ressourcen des Systems
Zeigt, wie viel Speicher und Rechenleistung Ihre SAP-Datenbank nutzt, damit Engpässe behoben werden, bevor Nutzer sie bemerken.
Nutzeraktivität und Blockaden
Zeigt, wie viele Nutzer verbunden sind und ob Geschäftsvorgänge feststecken, weil sie aufeinander warten.
Sicherung und Wiederherstellung
Macht sichtbar, ob Sicherungen aktuell sind und Ihr Ersatzsystem synchron läuft, zum Schutz kritischer Geschäftsdaten.
Warnungen und Lizenzen
Hebt offene Systemwarnungen und ablaufende Lizenzen hervor, damit Sie kein vermeidbarer Ausfall unvorbereitet trifft.
Alle 9 Metriken im Detail anzeigen
| Metrik | Einheit | Aussage |
|---|---|---|
saphana.service.memory.used | By | Speicherverbrauch je HANA-Service; der zentrale Indikator einer In-Memory-Datenbank. |
saphana.column.memory.used | By | Speicher der Column-Store-Tabellen, meist der größte Verbraucher. |
saphana.cpu.used | ms | CPU-Zeit der HANA-Instanz, um Sättigung zu erkennen. |
saphana.connection.count | {connections} | Aktuelle Verbindungen je Status, um Verbindungsstürme zu erkennen. |
saphana.transaction.blocked | {transactions} | Auf Sperren wartende Transaktionen; Wachstum bedeutet Contention. |
saphana.alert.count | {alerts} | Aktuelle HANA-Alerts je Bewertung, direkt aus der Datenbank. |
saphana.backup.latest | s | Alter des letzten Backups; Alert, wenn es Ihre Backup-Richtlinie überschreitet. |
saphana.replication.backlog.time | us | Rückstand der Systemreplikation, entscheidend für das Disaster Recovery. |
saphana.license.expiration.time | s | Verbleibende Zeit bis zum Ablauf der HANA-Lizenz. |
SAP-Monitoring in wenigen Minuten einrichten
- Schritt 1
Monitoring-User anlegen
Legen Sie einen eigenen HANA-Datenbankuser mit Lesezugriff und den in der Receiver-Dokumentation beschriebenen Monitoring-Rechten an.
- Schritt 2
OpenTelemetry Collector betreiben
Konfigurieren Sie den saphana-Receiver und für NetWeaver-Hosts einen Prometheus-Scrape Ihres Exporters; Export per OTLP an Obseria.
- Schritt 3
Fachliche Signale ergänzen
Rufen Sie Prozess-KPIs über SAP-OData-APIs mit einem Obseria-Automation-Workflow oder eigenem Job ab und senden Sie sie als Metriken oder 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]Sofort einsatzbereit
Dashboards, Alerts und SLOs, die bereitstehen, sobald die ersten Daten ankommen.
- SAP-HANA-Übersicht: Speicher, CPU, Verbindungen
- Alert bei HANA-Speicher nahe am Limit
- Alert bei zu altem Backup
- Rückstand der Systemreplikation
- Prozessvolumen aus SAP-APIs
SAP-Monitoring: Darauf kommt es an
Warum SAP-Monitoring in Ihre Observability-Plattform gehört
SAP-Systeme tragen die Prozesse, die ein Unternehmen nicht anhalten kann: Order-to-Cash, Procure-to-Pay, Produktionsplanung und Finanzen. Gleichzeitig läuft SAP selten allein. Webshops, mobile Apps, Integrationsplattformen und eigene Microservices rufen S/4HANA auf, und SAP selbst hängt von Datenbanken, Hosts und Netzwerken ab. Wird der Checkout langsam, kann die Ursache ein Speicherengpass in HANA, ein ausgelasteter Applikationsserver oder ein Service vor SAP sein. SAP-Monitoring in einem isolierten Werkzeug kann diese Frage nicht beantworten; es muss neben Ihrer übrigen Telemetrie stehen.
SAP liefert eigene Administrations- und Monitoring-Werkzeuge, und für tiefe Basis-Arbeit bleiben sie der richtige Ort. Das Ziel von SAP Observability in Obseria ist ein anderes: die wichtigsten Gesundheitssignale von SAP über offene und dokumentierte Integrationswege in dasselbe Datenmodell, dieselbe Topologie und dasselbe Alerting zu bringen wie alles andere.
Die wichtigsten SAP-Signale
SAP HANA
Bei einer In-Memory-Datenbank steht der Speicher an erster Stelle. Der saphana-Receiver des OpenTelemetry Collector liefert saphana.service.memory.used, saphana.column.memory.used und die konfigurierten Limits, dazu CPU-Zeit, Verbindungen, blockierte Transaktionen, Alerts, Backup-Alter und den Rückstand der Systemreplikation. Zusammen decken sie Kapazität, Contention und Ausfallsicherheit ab.
NetWeaver- und ABAP-Applikationsserver
Auf der Applikationsebene zeigen Work-Process-Queues und der Enqueue Server, ob das System mit Dialog- und Batch-Last Schritt hält. Community-Exporter für Prometheus wie sap_host_exporter lesen diese Informationen aus dem SAP Start Service und stellen sie zum Scrapen bereit. Host-Metriken des Obseria Agent ergänzen CPU, Speicher, Disk und Netzwerk je Instanz.
Geschäftsprozesse
Technischer Zustand ist nur die halbe Wahrheit. S/4HANA stellt Geschäftsobjekte über OData-APIs bereit. Wenn Sie Volumen und Rückstände abrufen, etwa offene Kundenaufträge oder gesperrte Rechnungen, und als Metriken an Obseria senden, sehen Sie, dass ein Prozess stockt, bevor Anwender es melden.
Typische SAP-Performance-Probleme erkennen
- Speicherdruck in HANA: Nähert sich der genutzte Speicher dem effektiven Limit, folgen Entladungen und Out-of-Memory-Dumps. Alarmieren Sie auf das Verhältnis, nicht auf absolute Werte.
- Lock-Contention: Steigt
saphana.transaction.blockedin Batch-Fenstern, konkurrieren Jobs oder lange laufende Transaktionen. - Erschöpfte Work Processes: Lange Dispatcher-Queues bedeuten Wartezeit für Dialoguser, obwohl die Datenbank gesund ist.
- Replikationsverzug: Ein wachsender Rückstand schwächt Ihr Disaster Recovery, ohne dass Nutzer etwas bemerken.
- Fehlende Backups: Das Backup-Alter ist eine einfache Metrik, die einen schweren Vorfall verhindern kann.
- Langsame Schnittstellen: Services, die SAP aufrufen, zeigen steigende Client-Latenz; Traces auf der aufrufenden Seite machen die Abhängigkeit sichtbar.
Batch-Fenster im Blick behalten
Viele SAP-Probleme entstehen nachts, wenn Abschlussläufe, Datenübernahmen und Backups gleichzeitig laufen. Vergleichen Sie Speicher, CPU und blockierte Transaktionen der HANA-Datenbank über mehrere Wochen für dieselben Zeitfenster. So erkennen Sie, ob ein Lauf schleichend länger dauert, lange bevor er in den Arbeitstag hineinreicht und Dialoguser beeinträchtigt.
Best Practices für SAP Performance Monitoring
- Nutzen Sie für jede HANA-Verbindung einen eigenen Monitoring-User mit reinen Leserechten.
- Betreiben Sie den OpenTelemetry Collector nah an der SAP-Landschaft und halten Sie Zugangsdaten in Umgebungsvariablen oder einem Secret Store.
- Versehen Sie jedes Signal mit SAP-System-ID und Landschaftsstufe, etwa Produktion oder Qualitätssicherung, als Resource-Attribut.
- Instrumentieren Sie die Services, die SAP aufrufen, damit die Latenz an der Grenze aus Sicht der Konsumenten gemessen wird.
- Definieren Sie je Prozess wenige fachliche KPIs und alarmieren Sie auf Abweichungen statt auf jede technische Metrik.
So unterstützt Obseria das SAP-Monitoring
Obseria verarbeitet SAP-Telemetrie über OpenTelemetry und Prometheus, also über dieselben Wege wie den Rest Ihres Stacks, und speichert sie in Obseria Lake zusammen mit Traces, Logs und Infrastrukturmetriken. TopoGraph verknüpft SAP-Hosts, Datenbanken und die aufrufenden Services. Die Anomalieerkennung lernt normale Muster für HANA-Speicher, Verbindungen und Prozessvolumen. Im Störungsfall korreliert Obseria Intelligence SAP-Signale mit Deployments, Infrastrukturänderungen und vorgelagerten Services und erklärt die wahrscheinliche Ursache mit einer Beweiskette. Dank Datenhaltung in der EU und Zertifizierungen wie ISO 27001 und BSI C5 bleiben SAP-bezogene Daten innerhalb Ihrer Compliance-Grenzen.
Verwandte Integrationen
Passende Funktionen
Datenbank-Monitoring
Finden Sie die langsame Query hinter dem langsamen Endpunkt. Obseria verknüpft Datenbankmetriken, Query-Performance und Logs mit den Traces und Services, die sie aufrufen.
Mehr erfahrenAnomalie-Erkennung
Obseria Intelligence lernt den normalen Rhythmus jedes Service, meldet echte Abweichungen statt Schwellenwert-Rauschen und fasst zusammenhängende Anomalien zu einem Problem mit wahrscheinlicher Ursache zusammen.
Mehr erfahrenService-Katalog
Jeder Service, sein Owner, seine Abhängigkeiten und SLOs an einem Ort – automatisch aus Traces und Topologie erkannt und um die Metadaten Ihrer Teams ergänzt.
Mehr erfahrenMehr erfahren
Was ist Observability?
Was ist Observability? Wie Metriken, Logs, Traces und Profile Ihre Systeme verständlich machen und was Observability vom Monitoring unterscheidet.
Was ist eine Root-Cause-Analyse (RCA)?
Was ist eine Root-Cause-Analyse? Der RCA-Prozess für Software-Incidents, 5 Whys, Fishbone und Fehlerbaum, ein Praxisbeispiel und RCA mit KI.
Häufige Fragen zum SAP-Monitoring
Nein. Obseria bindet SAP über offene Wege an: den saphana-Receiver des OpenTelemetry Collector für HANA, Prometheus-Exporter für NetWeaver-Hosts, SAP-APIs für Geschäftsdaten und den Obseria Agent für Hosts.
Der saphana-Receiver liefert Speicher, CPU, Verbindungen, Transaktionen, Alerts, Backups, Replikation, Lizenzen, Volumes und Schema-Statistiken. Nicht benötigte Metriken deaktivieren Sie in der Receiver-Konfiguration.
Daten auf Ebene einzelner ABAP-Transaktionen sind nicht Teil der hier beschriebenen offenen Integrationswege. Work-Process- und Dispatcher-Statistiken erfassen Sie über Exporter, Geschäftsobjekte über SAP-APIs.
Fragen Sie S/4HANA-OData-APIs zeitgesteuert ab, etwa mit einem Obseria-Automation-Workflow, und senden Sie die Ergebnisse als Metriken an Obseria. Business Observability verfolgt dann Volumen und Rückstände im Zeitverlauf.
Der Receiver ist Teil der Contrib-Distribution des OpenTelemetry Collector und derzeit als Alpha eingestuft. Testen Sie ihn zunächst in einer Nicht-Produktionslandschaft und fixieren Sie die eingesetzte Collector-Version.
Starten Sie heute mit dem SAP-Monitoring
Binden Sie SAP in Minuten per OpenTelemetry oder Obseria Agent an. 14 Tage kostenlos.