Eine SAP-Landschaft über drei Clouds hat drei Statusseiten, drei Netzwerkmonitoring-Konsolen und drei SLA-Dokumente, aber keine Sicht auf einen Geschäftsprozess über alle drei hinweg. Solche Landschaften sind heute üblich. Ebenso üblich ist die beim Architekturentwurf unterschätzte Monitoring-Lücke.
Dieser Artikel behandelt Sichtbarkeitsprobleme bei mehreren Cloud-Anbietern oder Cloud und On-Premises, verschärfende Architekturmuster und Designentscheidungen für Ende-zu-Ende-Transparenz ohne vollständigen Infrastrukturumbau.
Wie Multi-Cloud-SAP in Unternehmen aussieht
Der Begriff umfasst unterschiedliche Konfigurationen. Häufig laufen ECC oder S/4HANA lokal oder auf kundenseitig verwalteter IaaS, während BTP-Erweiterungen je nach Region und Konto auf Azure, AWS oder GCP liegen. Eine weitere Kombination ist RISE für den S/4HANA-Kern, verbunden über BTP Integration Suite mit Drittservices eines anderen Anbieters.
Meist wird Multi-Cloud nicht bewusst gewählt, sondern durch Projekte angesammelt: Azure für BTP wegen eines Unternehmensvertrags, Logistik-SaaS auf AWS, BusinessObjects seit Jahren auf einer GCP-VM. Hybride Architekturmuster helfen beim bewussten Design. Hier geht es um bereits bestehende Konfigurationen, denen das Monitoring nicht angepasst wurde.
Die entstehende Sichtbarkeitslücke
Drei Monitoring-Ebenen ohne Korrelation
Azure Monitor beobachtet Azure, CloudWatch AWS und BTP Cockpit BTP-Dienste und Integration-Suite-Flows. Jede Plattform liefert korrekte Daten ihres Bereichs, sieht aber die anderen nicht.
Ein Cloud-übergreifender Prozessfehler erzeugt getrennte Ereignisse. Ein S/4HANA-Auftrag auf Azure löst keine Logistikmeldung aus, weil ein BTP-Transformationsfehler die IDoc-Erzeugung für den AWS-Dienstleister verhindert. Azure meldet eine gesunde Instanz, BTP einen Flow-Fehler und AWS nichts, weil die Nachricht nie ankam. Automatische Korrelation fehlt.
Die Untersuchung muss Zeitstempel manuell abgleichen, den BTP-Flow zur SAP-Transaktion finden und das Ausbleiben in AWS als Ursache oder Folge einordnen. Ohne durchgängige Korrelations-ID wird daraus Detektivarbeit statt Dashboard-Abfrage. Ende-zu-Ende-SAP-Observability verbindet technische Ereignisse und Geschäftsergebnisse über Infrastrukturgrenzen.
Netzwerklatenz als neue SAP-Performancevariable
On-Premises liegt die Latenz zwischen Applikation und HANA typischerweise unter einer Millisekunde. In derselben Cloud-Verfügbarkeitszone sind es häufig 1 bis 3 ms, zwischen Zonen einer Region 2 bis 5 ms und zwischen Regionen oder Anbietern 20 bis 50 ms pro synchronem Hop.
Aufeinanderfolgende synchrone Aufrufe summieren diese Verzögerung. Preisfindung in S/4HANA, Steuerberechnung in Integration Suite und Vertragsprüfung im Drittservice fügen bei je 30 ms bereits 90 ms vor der Verarbeitung hinzu. Einzelkomponentenmonitoring sieht diesen Overhead nicht; Ende-zu-Ende-Messung schon.
Deshalb muss auf Prozessebene gemessen werden. Ein in 200 ms arbeitender Baustein kann korrekt funktionieren, während ein viersekündiger Prozess zwölf Cloud-übergreifende Aufrufe mit jeweils 30 ms Zusatzlatenz ausführt. Das Architekturproblem wird erst im Gesamtzeitverlauf sichtbar.
Neue Cloud-spezifische Fehlermuster für SAP-Teams
Ausfall und Teildegradation einer Verfügbarkeitszone
Lokale Fehler erscheinen oft binär: Server läuft oder steht, Netzwerk verbunden oder getrennt. Eine Cloud-Zone kann teilweise degradieren, mit erhöhten API-Fehlern, langsamerem Storage oder sporadischen Paketverlusten. SAP bleibt erreichbar, liefert aber zeitweise längere Antworten und einzelne Transaktionsfehler.
Die verstreuten Symptome sind mit Standard-SAP-Monitoring schwer zu erkennen. Manche Transaktionen sind langsam, andere erfolgreich, andere fehlerhaft; ein klares Systemereignis fehlt. Die Ursachenfindung benötigt Korrelation mit externen Verfügbarkeitsdaten der betroffenen Zone.
Schwankende Storage-I/O und HANA
HANA reagiert empfindlich auf Storage-Latenz. Cloud-Blockstorage variiert stärker als dedizierte Arrays: Eine Schreiboperation mit normalerweise 1 ms kann während Wartung oder hoher Backend-Auslastung 15 ms benötigen.
Solche Spitzen beeinflussen Savepoints, Log-Backups und Delta Merges. Kontinuierliche HANA-Metriken machen sie als Betriebssignal sichtbar. Abweichende Savepoint-Dauern zeigen Storage-Degradation häufig früher als die Statusseite des Anbieters.
Hinweis: Anbieterstatusseiten zeigen verfügbarkeitsrelevante Infrastrukturereignisse, nicht jede Performance-Verschlechterung. Dreifache I/O-Latenz kann dort fehlen, aber in HANA-Savepoints und bei anhaltender Störung in Dialogantwortzeiten erscheinen.
RISE with SAP und die Monitoring-Grenze
RISE bündelt S/4HANA-Hosting, Infrastrukturmanagement und Plattformbetrieb. SAP verwaltet Infrastruktur, HANA-Clusterkonfiguration und grundlegende Verfügbarkeit. Anwendungskonfiguration, Erweiterungen, Integrationen und Anwendungsobservability bleiben beim Kunden.
Der SLA deckt Infrastrukturverfügbarkeit und Plattformgesundheit ab. Prozessabschlussquoten, Job-Erfolg, Schnittstellenfehler und HANA-Anwendungsperformance sind kundenseitig. Nur integriertes SAP-Monitoring zu nutzen lässt daher blinde Flecken.
Bei Prozessfehlern kann SAP eine gesunde Infrastruktur bestätigen; die Anwendungsuntersuchung bleibt beim Kunden. Dafür braucht er eine unabhängige Verbindung zur S/4HANA-Anwendungsschicht über RFC oder REST. Einrichtung und Berechtigung sind explizit erforderlich und fehlen oft. Agentenloses Monitoring eignet sich besonders, weil nur ein technischer Anwendungsbenutzer statt Infrastrukturzugriff nötig ist.
Architekturlösungen für Multi-Cloud-Transparenz
Einheitliche Monitoring-Ebene mit verteilter Datenerfassung
Sie verbindet SAP-Anwendungsdaten, Cloud-Metriken und Middleware auf einer gemeinsamen Zeitachse. RFC und HANA SQL liefern SAP-Daten; Anbieter-APIs ergänzen Zonenzustand, Storage-I/O und Netzwerk. Eine Zonendegradation und gleichzeitige SAP-Anomalie erscheinen gemeinsam statt in getrennten Werkzeugen.
Dafür müssen bestehende Cloud-Tools nicht ersetzt werden. Die Plattform muss mehrere Quellen aufnehmen und nach Zeit sowie Geschäftskontext korrelieren. SAP-spezifische Daten, die Anbieter nicht liefern, erfordern eine SAP-fähige Anbindung.
Cloud-übergreifende Transaktionskorrelation
Korrelations-IDs müssen vom Ursprung über Middleware zu allen Zielsystemen mitreisen. Ohne gemeinsame ID erfordert die Zuordnung von S/4HANA-Transaktion, BTP-Flow und empfangenem Ergebnis manuelle Rekonstruktion. Mit einer ID im Payload und in jedem Verarbeitungsschritt genügt eine Suche. Das SAP-Integration-Hub-Monitoring beschreibt eine einheitliche Weitergabe.
Synthetische Geschäftsprozessprüfungen
Synthetisches Monitoring führt regelmäßig leichte Testtransaktionen aus und misst das Gesamtergebnis. Eine Sonde legt einen Testauftrag an, prüft die Nachricht in Integration Suite und bestätigt die Zustellung im Ziel. Alle paar Minuten wird die gesamte Kette geprüft. Bei Fehler oder Zeitüberschreitung folgt ein Alert, bevor echte Benutzertransaktionen betroffen sind.
Eine erfolgreiche Sonde bestätigt den gesamten Pfad; eine gescheiterte zeigt Schritt und Cloud. Sie ersetzt keine Komponentenüberwachung, liefert aber das erste Signal und verkürzt die Ursachenrecherche.
Multi-Cloud-Sichtbarkeit ist zuerst ein Architekturproblem. Ein weiteres Dashboard behebt weder fehlende Korrelation noch gemeinsame IDs oder Prozessmessung. ID-Weitergabe, Standort der einheitlichen Erfassung und Auswahl synthetischer Prüfungen sollten beim Design festgelegt werden und sind später schwer nachzurüsten.
Übernimmt ein Team eine Landschaft ohne vorgesehene Transparenz, beginnt es mit einer Lückenanalyse: Welche Komponenten werden überwacht, welche nicht, und welchen Prozessen fehlt Ende-zu-Ende-Sicht? Das kostenlose SAP-Monitoring-Assessment bietet einen strukturierten Einstieg. Korrekturen erfolgen schrittweise, die Analyse bestimmt den Anfang.
Redpeaks sammelt SAP-Anwendungsmetriken über RISE, kundenseitige Clouds und On-Premises mit einer agentenlosen Anbindung und bietet systemübergreifende Korrelation sowie Integrationsmonitoring. Entdecken Sie die Multi-Cloud-Abdeckung.
