Wer Monitoring-Software auf einem produktiven SAP-System installiert, schafft eine Abhängigkeit, die meist im ungünstigsten Moment sichtbar wird. Der SAP-Kernel wird gepatcht. Der Monitoring-Agent läuft auf dem Applikationsserver, liest dort Prozessdaten auf niedriger Ebene und ist mit der neuen Kernel-Version nicht kompatibel. Für dieses System fällt die Überwachung aus, während der Anbieter an einer Lösung arbeitet. Niemand weiß, ob das System stabil läuft. Vier Tage später ist der Fix verfügbar, erfordert einen Neustart und erzeugt ein weiteres Change-Management-Ticket.
Dieses Szenario ist nicht hypothetisch. Es tritt in Umgebungen auf, die sich für agentenbasiertes Monitoring entschieden haben, ohne den damit verbundenen Wartungsaufwand vollständig einzukalkulieren. Bei einem einzelnen System wirkt der Aufwand überschaubar. Bei zehn Systemen mit unterschiedlichen Patchzyklen, SAP-Versionen und Agentenkonfigurationen entsteht jedoch ein eigener operativer Arbeitsstrom, den ursprünglich niemand eingeplant hat.
Agentenloses Monitoring beseitigt diese Abhängigkeit, weil auf dem SAP-System gar kein Agent installiert wird. Auf dem überwachten System befindet sich keine Monitoring-Software. Keine Transportaufträge. Keine ausgerollten ABAP-Programme. Keine zusätzlichen Prozesse auf dem Applikationsserver. Die Verbindung erfolgt vollständig von außen über vorhandene SAP-Standardschnittstellen. Dieser Artikel erklärt, wie das technisch funktioniert, was sich im Betrieb dadurch ändert und wo die Grenzen dieses Ansatzes liegen.
Was agentenloses Monitoring im SAP-Kontext wirklich bedeutet
Der Agent als Wartungsabhängigkeit
Im klassischen Monitoring ist ein Agent ein Softwareprozess, der auf oder innerhalb des überwachten Systems läuft. Im SAP-Umfeld gibt es dafür mehrere Varianten. Ein Agent auf Betriebssystemebene läuft auf dem Linux- oder Windows-Host und liest Prozessmetriken, Dateisystemdaten und Netzwerkstatistiken. Ein per Transport ausgerollter ABAP-Agent führt Programme aus, liest Tabellen und ruft Funktionsbausteine direkt im SAP-ABAP-Stack auf. Ein Java-Monitoring-Agent bindet sich in die JVM ein, um Thread-Zustände, Heap-Speicher und das Laden von Klassen auszulesen. Jede dieser Komponenten muss vorhanden sein, zuverlässig laufen und bei Veränderungen der SAP-Umgebung kompatibel bleiben.
Welche Wartungsabhängigkeit entsteht, hängt vom Agententyp ab. Ein Betriebssystem-Agent muss nach Änderungen am Betriebssystem aktualisiert, nach Hardwareänderungen getestet und nach einem Absturz neu gestartet werden. Ein per Transport bereitgestellter ABAP-Agent muss die gesamte SAP-Transportlandschaft durchlaufen: Installation in der Entwicklung, Test in der Qualitätssicherung, Übernahme in die Produktion und erneuter Test nach jedem SAP-Upgrade, das das Verhalten der aufgerufenen Funktionen beeinflussen könnte. Ein Java-Agent muss mit der SAP Java VM kompatibel bleiben, die sich mit Enhancement Packages und Feature Packs verändert.
Betreibt ein Unternehmen nur ein SAP-System, lassen sich diese Aufgaben bewältigen. Verwaltet ein MSP dagegen 40 SAP-Systeme für verschiedene Kunden, jeweils mit eigenem Patchzyklus und separater Agentenvalidierung, wird der Wartungsaufwand zu einem operativen Kostenfaktor, der im ursprünglichen Preismodell nicht berücksichtigt war.
So sieht eine Verbindung ohne Agent aus
Agentenloses Monitoring verbindet sich von außen über bereits vorhandene Schnittstellen mit dem SAP-System. Welcher Verbindungsweg genutzt wird, hängt von der überwachten Ebene des SAP-Stacks ab.
Für die ABAP-Applikationsebene wird eine RFC-Verbindung vom Typ 3 verwendet: eine externe RFC-Verbindung zum Message Server oder Gateway des SAP-Systems. Der Monitoring-Collector sendet RFC-Aufrufe an SAP. Das System führt Standardfunktionsbausteine aus oder liest Standardtabellen und liefert die Ergebnisse zurück. Auf SAP-Seite läuft kein kundenspezifischer Code. Es ist kein Transport erforderlich. Das SAP-System verarbeitet die Aufrufe über die vorhandene RFC-Infrastruktur, die es auch für andere externe Verbindungen nutzt.
Für die SAP-HANA-Datenbankebene wird eine JDBC- oder ODBC-Verbindung zur HANA-Datenbank aufgebaut. Die Authentifizierung erfolgt über einen dedizierten Monitoring-Benutzer auf Datenbankebene. Der Collector sendet SQL-Abfragen an die System-Views in den Schemas SYS und _SYS_STATISTICS, darunter M_MEMORY_OVERVIEW, M_SERVICE_REPLICATION, M_DISK_USAGE und M_EXPENSIVE_STATEMENTS. HANA führt die Abfragen aus und liefert die Ergebnisse zurück. Außer dem Datenbankbenutzer und seinen Berechtigungen ist keine zusätzliche Software auf HANA-Seite erforderlich.
Der Monitoring-Collector initiiert diese Verbindungen und speichert die zurückgegebenen Daten. Er läuft auf einer von den SAP-Systemen getrennten Infrastruktur und damit außerhalb aller überwachten Komponenten. Aus Sicht des SAP-Systems verhält er sich wie jeder andere RFC-Client oder jede andere Datenbankanwendung: Er authentifiziert sich, fragt Daten ab und trennt die Verbindung wieder.
So funktioniert die agentenlose Datenerfassung technisch
RFC-basierte Erfassung: Zugriff auf die ABAP-Ebene
RFC ist der SAP-Standardmechanismus für die Kommunikation zwischen Systemen. Möchte eine externe Anwendung einen Funktionsbaustein in einem entfernten SAP-System aufrufen, baut sie eine RFC-Verbindung auf, sendet den Namen des Funktionsbausteins und die Parameter und erhält die Rückgabewerte. Genau so kommunizieren SAP-Systeme in verteilten Landschaften miteinander. Der Monitoring-Collector nutzt denselben Mechanismus.
Über RFC verfügbare Funktionsbausteine und Tabellenzugriffe decken die relevanten Monitoring-Daten der ABAP-Ebene ab. Daten, die SM50 entsprechen, liefern Standardfunktionsbausteine mit Status und Statistiken der Workprozesse. Jobdaten aus SM37 sind über RFC-fähige Batch-Job-Schnittstellen zugänglich. Zustände von IDoc- und qRFC-Queues lassen sich über Standardfunktionsbausteine der ALE- und RFC-APIs auslesen. Systemprotokolldaten aus SM21 stehen über die Schnittstellen zum Lesen des Systemlogs zur Verfügung. Dafür ist kein kundenspezifischer Code erforderlich. Es werden dieselben RFC-fähigen Schnittstellen genutzt, die CCMS, Solution Manager und verschiedene SAP-Standardwerkzeuge seit Jahren verwenden.
Das Erfassungsintervall wird im Zeitplan des Collectors festgelegt. Bei einem Intervall von 60 Sekunden sendet er jede Minute einen RFC-Aufruf, empfängt den aktuellen Systemzustand und speichert die Daten. Ein Intervall von 30 Sekunden verdoppelt die Erfassungsfrequenz. Das SAP-System verarbeitet diese Aufrufe wie andere RFC-Anfragen und verwendet je nach Konfiguration verfügbare Hintergrund- oder Dialog-Workprozesse. Die zusätzliche Last hängt von der Frequenz und dem Datenvolumen pro Aufruf ab und bleibt im Verhältnis zur produktiven Transaktionslast in der Regel gering.
HANA-SQL-Erfassung: Zugriff auf die Datenbankebene
HANA-System-Views mit dem Präfix M_ im SYS-Schema sind die wichtigste Quelle für HANA-Monitoring-Daten. Sie liefern Echtzeitinformationen zu Speicherbelegung, Servicezuständen, aktiven Abfragen, Replikationsstatus, Festplattennutzung und zahlreichen weiteren Metriken. Diese Views sind standardisierte HANA-Objekte, von SAP dokumentiert und für jede Anwendung mit den passenden Datenbankberechtigungen abfragbar.
Der Monitoring-Collector verbindet sich per JDBC mit HANA. Der verwendete Datenbankbenutzer verfügt über die Systemberechtigungen MONITORING und CATALOG READ. Mit diesen beiden Berechtigungen kann er alle M_*-Views im SYS-Schema abfragen. Weitere Anpassungen auf HANA-Seite sind nicht erforderlich. Es werden keine Skripte ausgerollt und keine Stored Procedures installiert. Der Monitoring-Benutzer ist ein regulärer Datenbankbenutzer. Seine Berechtigungen sind dokumentiert, auditierbar und können jederzeit über die standardmäßige HANA-Benutzerverwaltung geprüft oder entzogen werden.
Die Trennung zwischen der ABAP-RFC-Verbindung und der HANA-SQL-Verbindung entspricht der Architektur des SAP-Systems. ABAP- und HANA-Metriken stammen aus unterschiedlichen Ebenen mit jeweils eigenen Zugriffsmechanismen. Der Collector verwaltet deshalb beide Verbindungen unabhängig voneinander. Eine Änderung an der HANA-Konfiguration beeinflusst die RFC-Verbindung nicht. Eine Änderung am ABAP-Berechtigungsprofil hat keine Auswirkung auf den HANA-Datenbankbenutzer.
Der Collector: Wo die externe Komponente läuft
Agentenloses Monitoring bedeutet nicht, dass keinerlei Software beteiligt ist. Der Monitoring-Collector ist eine Softwarekomponente. Entscheidend ist, wo sie ausgeführt wird. Der Collector läuft auf einer vom SAP-Team kontrollierten Infrastruktur, die von den überwachten SAP-Systemen getrennt ist. Das kann ein dedizierter Server, eine virtuelle Maschine, ein Container in einem Managementnetzwerk oder ein in der Cloud gehosteter Service sein. Wichtig ist: Er läuft nicht auf dem SAP-Applikationsserver, wird nicht in HANA installiert und nicht über das SAP-Transportsystem bereitgestellt.
Dadurch hat der Collector einen eigenen Lebenszyklus, unabhängig von den überwachten SAP-Systemen. Wird ein SAP-Kernel gepatcht, muss der Collector nicht aktualisiert werden. Ändert SAP die Schnittstelle eines Standardfunktionsbausteins, wird die Anpassung mit dem nächsten geplanten Collector-Release umgesetzt, ohne das überwachte System zu verändern. Das SAP-System weiß nicht, welche Version des Monitoring-Werkzeugs der Collector verwendet. Es registriert lediglich, dass sich ein RFC-Client authentifiziert, einen Aufruf gesendet und eine Antwort erhalten hat.
Die Verfügbarkeit des Collectors ist für ein lückenloses Monitoring wichtig. Fällt er aus, werden keine Daten erfasst und es entstehen Monitoring-Lücken. Hochverfügbarkeit durch redundante Instanzen oder automatisches Failover ist eine Aufgabe der Monitoring-Infrastruktur, nicht der SAP-Systeme. Die Verfügbarkeit des Collectors wird daher vom Monitoring-Team oder MSP verwaltet, nicht vom SAP-Team.
Der operative Aufwand von Agenten wird mit zunehmender Größe sichtbar
Ein System, ein Agent: Der Aufwand wirkt überschaubar
Die Installation eines Agenten auf einem einzelnen SAP-System bedeutet einige Stunden Arbeit. Transport anlegen, in DEV testen, in die Qualitätssicherung übernehmen, erneut testen und in die Produktion bringen. Möglicherweise ist ein Neustart nötig. Die Änderung muss dokumentiert werden. Der Aufwand ist real, bleibt aber begrenzt. Nach dem nächsten SAP-Upgrade kommt ein weiterer halber Tag für den Kompatibilitätstest hinzu. Über ein Jahr hinweg kann die Agentenwartung für ein System fünf bis zehn Arbeitsstunden beanspruchen.
In dieser Größenordnung spricht wenig gegen Agenten. Der Agent funktioniert, die Daten fließen und Wartung fällt nur gelegentlich an. Teams akzeptieren diesen Aufwand, weil er innerhalb der gesamten Betriebsarbeit kaum auffällt.
Zwanzig Systeme, zwanzig Agenten: Jetzt ändert sich die Rechnung
Bei 20 SAP-Systemen wächst der Wartungsaufwand linear. Zwanzig Transportsätze müssen verwaltet werden. Zwanzig Kompatibilitätstests stehen pro SAP-Upgradezyklus an. Zwanzig Neustartfenster sind zu koordinieren. Zwanzig Change-Management-Vorgänge müssen eröffnet und geschlossen werden. Führt das Unternehmen vierteljährlich SAP-Upgrades durch, sind das 80 Kompatibilitätstests pro Jahr. Veröffentlicht der Agentenanbieter zwei Updates jährlich, folgen daraus 40 Update-Deployments auf 20 Systemen.
Die Rechnung wird noch komplexer, wenn die 20 Systeme unterschiedliche SAP-Versionen, Betriebssysteme oder Patchpläne haben. Ein für S/4HANA 2023 FPS02 validierter Agent kann sich unter S/4HANA 2022 FPS04 anders verhalten. Das Monitoring-Team muss eine Kompatibilitätsmatrix pflegen und jede Agentenversion vor dem Rollout gegen jede SAP-Version testen. In einer heterogenen Landschaft erreicht diese Matrix schnell eine erhebliche Größe.
Der unsichtbare Kostenfaktor ist der zusätzliche Projektaufwand. Jedes SAP-Upgradeprojekt, das Agenten-Kompatibilitätstests umfasst, ist größer als ein Projekt ohne Agenten. Im Projektbudget wird dieser Testaufwand nicht immer dem Monitoring-Werkzeug zugerechnet. Er erscheint später als Überschreitung des Upgradeprojekts, ohne dass die Ursache klar benannt wird.
Das Upgrade-Problem: Warum sich der Agentenaufwand mit jedem SAP-Patchzyklus summiert
SAP veröffentlicht Kernel-Patches, Enhancement Packages, Feature Packs und Hauptversionen in einem Rhythmus, der sich seit der Einführung von S/4HANA beschleunigt hat. Jedes Release kann die Kompatibilität von Software beeinflussen, die auf oder innerhalb des SAP-Systems läuft. Der Monitoring-Anbieter muss seinen Agenten gegen die neue Version testen und eine kompatible Fassung veröffentlichen. Die Kunden müssen diese installieren, bevor sie ihre SAP-Systeme aktualisieren.
In der Praxis läuft diese Reihenfolge selten so sauber ab. Das SAP-Update ist verfügbar, bevor der Agent aktualisiert wurde. Der Kunde hat ein Wartungsfenster für den SAP-Patch, aber noch keine kompatible Agentenversion. Er kann den SAP-Patch verschieben, was bei Sicherheitsupdates nicht vertretbar ist, den Patch einspielen und bis zur Veröffentlichung des Agenten eine Monitoring-Lücke akzeptieren, was dem Zweck des Monitorings widerspricht, oder den Agenten vor dem Patch entfernen und danach erneut installieren. Aus einem Change-Management-Vorgang werden so drei.
Bei agentenlosem Monitoring entfällt dieses Problem. Ein SAP-Kernel-Patch verändert weder die RFC-Schnittstelle noch die HANA-System-Views. Der Collector erfasst die Daten unverändert weiter. Der Umfang des Upgradeprojekts wird kleiner, weil die Monitoring-Kompatibilität kein eigener Testpunkt mehr ist. Das SAP-Team kann planmäßig patchen, ohne sich mit dem Monitoring-Anbieter abstimmen zu müssen.
| Aus der Praxis: In regulierten Umgebungen, etwa GxP-konformen pharmazeutischen Systemen oder Finanzsystemen unter SOX-Kontrollen, erfordert jede Softwareinstallation auf einem Produktivsystem einen dokumentierten Change-Prozess. Die Installation eines Agenten ist eine Softwareinstallation. Sie muss daher den Change-Prozess durchlaufen, erfordert Validierungstests und je nach Validierungsstatus des Systems möglicherweise regulatorische Dokumentation. Agentenloses Monitoring vermeidet diesen Aufwand vollständig: Auf dem validierten System wird keine Software installiert und damit kein entsprechender Change-Prozess ausgelöst. |
Berechtigungen und Sicherheit beim agentenlosen Monitoring
Welche Berechtigungen der Monitoring-Benutzer wirklich benötigt
Eine RFC-basierte Monitoring-Verbindung authentifiziert sich als SAP-Benutzer. Dieser Benutzer benötigt Berechtigungen für die RFC-Aufrufe und für das Lesen der erforderlichen Daten. Dabei gilt konsequent das Prinzip der minimalen Rechte: Der Monitoring-Benutzer erhält genau den Zugriff, der für die Überwachung notwendig ist, und keine darüber hinausgehenden Berechtigungen.
Die zentralen Berechtigungsobjekte für das Monitoring der ABAP-Ebene sind S_RFC, das festlegt, welche RFC-Funktionsgruppen und Funktionsbausteine von extern aufgerufen werden dürfen, S_TCODE, das den Zugriff auf Transaktionscodes steuert, deren Daten das Monitoring-Werkzeug liest, und in bestimmten Fällen S_ADMI_FCD für einzelne lesende Funktionen der Systemadministration. Die genauen Werte hängen von den erfassten Metriken ab. Ein gut dokumentiertes Monitoring-Werkzeug stellt eine Liste der benötigten Berechtigungsobjekte und der jeweiligen Werte bereit.
Ein speziell aus diesen Berechtigungen aufgebautes Benutzerkonto hat einen klar definierten, dokumentierten und auditierbaren Zugriff. Das Security-Team kann die Rolle prüfen und bestätigen, dass der Benutzer keine SAP-Daten verändern, keine Geschäftsprozesse ausführen und auf keine Anwendungsdaten außerhalb der Systemzustandsmetriken zugreifen kann. Diese Nachvollziehbarkeit fehlt bei einem Agenten, der umfassenden Zugriff auf Betriebssystemprozesse erhalten hat oder aus Bequemlichkeit mit einem hoch privilegierten Konto installiert wurde.
Warum minimale Berechtigungen besser auditierbar sind als eine Agenteninstallation
Ein Agent, der auf Betriebssystemebene mit root- oder Administratorrechten läuft, um auf Prozessinformationen zuzugreifen, hat einen breiten Berechtigungsumfang, der sich bei einer Zugriffsprüfung nur schwer abgrenzen lässt. Das Zugriffsmodell für Betriebssystemprozesse ist binär: Der Prozess kann alles lesen, worauf sein Benutzerkonto zugreifen darf. Eine Beschränkung auf reine Monitoring-Daten erfordert zusätzliche Richtlinien auf Betriebssystemebene, unabhängig vom Monitoring-Werkzeug selbst.
Eine RFC-Monitoring-Verbindung mit einer gezielt konfigurierten Berechtigungsrolle hat dagegen einen expliziten Umfang im SAP-eigenen Zugriffskontrollsystem. Die Prüfung erfolgt in SU01 und im Rolleneditor mit denselben Werkzeugen, die das Security-Team für alle anderen Zugriffsprüfungen verwendet. Der Zugriff unterscheidet sich grundsätzlich nicht von dem eines funktionalen SAP-Benutzers. Er ist lediglich wesentlich enger gefasst.
Der praktische Nutzen dieser Auditierbarkeit zeigt sich vor allem bei Sicherheitsaudits und Penetrationstests. Auf die Frage, welchen Zugriff das Monitoring-System besitzt, gibt es eine klare und präzise Antwort aus der SAP-Berechtigungsdokumentation statt aus Konfigurationsdateien eines externen Agenten. Diese Eindeutigkeit ist für Auditoren und die für Produktivsysteme verantwortlichen Security-Teams besonders wertvoll.
Was agentenloses Monitoring nicht leisten kann und wie sich die Lücke schließen lässt
Betriebssystem-Metriken und der hybride Ansatz
Agentenloses SAP-Monitoring über RFC und HANA SQL deckt die SAP-ABAP-Applikationsebene und die HANA-Datenbankebene ab. Die Betriebssystemebene wird nicht vollständig erfasst: Dazu gehören die Auslastung von Dateisystemen auf Nicht-HANA-Volumes, der Datenverkehr von Netzwerkschnittstellen, Hardwarewerte wie Temperatur und Lüfterstatus sowie Kernel-Indikatoren für Speicherdruck, die nicht über SAP-APIs bereitgestellt werden.
Das ist die tatsächliche Grenze dieser Architektur. RFC- und SQL-Schnittstellen liefern nur die Daten, die SAP bereitstellt. Einige Betriebssystemmetriken sind über SAP-APIs verfügbar, weil SAP sie intern erfasst und über CCMS oder HANA-System-Views zugänglich macht. Die Abdeckung ist jedoch nicht vollständig.
Für die meisten Umgebungen ist ein hybrider Ansatz die pragmatische Lösung. Betriebssystemmetriken werden von etablierten Infrastruktur-Monitoring-Werkzeugen erfasst, etwa über einen schlanken Betriebssystem-Agenten, SNMP-Abfragen oder das native Monitoring des Cloud-Anbieters in Hyperscaler-Umgebungen. SAP-Applikations- und Datenbankmetriken erfasst die Monitoring-Plattform agentenlos. Beide Datenquellen fließen in integrierte Dashboards ein, in denen Betriebssystem- und SAP-Ereignisse korreliert werden können, ohne dass eines der Werkzeuge den Aufgabenbereich des anderen übernehmen muss.
Dieser hybride Ansatz ist in der Regel sinnvoller, als ein SAP-spezifisches Monitoring-Werkzeug auf die Betriebssystemebene auszudehnen. Betriebssystem-Monitoring ist mit ausgereiften Werkzeugen gut gelöst. SAP-Applikationsmonitoring ist dagegen eine Spezialdisziplin mit eigenen Anforderungen. Werden beide Bereiche in einem SAP-Monitoring-Werkzeug kombiniert, das zusätzlich Betriebssystem-Agenten installiert, entsteht erneut genau die Wartungsabhängigkeit, die eine agentenlose Architektur vermeiden soll.
Wann ein Agent weiterhin die richtige Wahl ist
Es gibt Szenarien, in denen ein Agent auch innerhalb einer ansonsten agentenlosen Umgebung sinnvoll ist. Für kundenspezifische Metriken aus Daten, die SAP nicht über Standard-APIs bereitstellt, kann ein eigener ABAP-Report oder ein schlanker Agent zum Erfassen und Weiterleiten erforderlich sein. Bestimmte Hardware-Monitoring-Szenarien benötigen Daten, die nur über das Betriebssystem oder den BMC zugänglich sind. Auch regulatorische Vorgaben können eine Architektur verlangen, bei der Monitoring-Code aus Gründen der lückenlosen Nachweiskette direkt auf dem überwachten System ausgeführt wird.
Agentenlos ist keine absolute Regel. Für SAP-Monitoring ist es jedoch die richtige Standardarchitektur, weil die vorhandenen SAP-Schnittstellen die wichtigsten Metriken abdecken, der Wartungsaufwand bei wachsender Größe zum dominierenden Betriebskostenfaktor wird und das Berechtigungsmodell klarer ist. Lässt sich eine besondere Anforderung nicht über Standardschnittstellen erfüllen, ist ein Agent eine begründete Ausnahme und kein Scheitern des Grundprinzips.
Entscheidend ist, Agenten als dokumentierte und regelmäßig überprüfte Ausnahmen zu behandeln, statt sie als Standard unbemerkt anwachsen zu lassen. Eine SAP-Landschaft, in der innerhalb von fünf Jahren sechs Teams sechs verschiedene Agenten auf jedem System installiert haben, von denen keiner vollständig dokumentiert und einige nicht mehr mit den aktuellen SAP-Versionen kompatibel sind, ist genau der Zustand, den eine agentenlose Architektur verhindert.
Schnelle Bereitstellung und skalierbares Onboarding
Zeitaufwand pro neu angebundenem System
Die Anbindung eines einzelnen SAP-Systems an eine agentenlose Monitoring-Plattform folgt einem gut planbaren Ablauf. RFC-Monitoring-Benutzer mit der benötigten Rolle in SU01 anlegen: 20 Minuten. RFC-Destination in SM59 mit Ziel Monitoring-Collector erstellen: 10 Minuten. RFC-Verbindungstest und Berechtigungsprüfung durchführen: 5 Minuten. HANA-Monitoring-Benutzer mit den erforderlichen Systemberechtigungen konfigurieren: 15 Minuten. HANA-Verbindung vom Collector prüfen: 5 Minuten. Datenerfassung starten und kontrollieren, ob die Metriken im Dashboard erscheinen: 10 Minuten.
Gesamtzeit für die Aufnahme eines neuen SAP-Systems in das Monitoring: etwa eine Stunde, zuzüglich interner Freigabezeiten für den Monitoring-Benutzer. Kein Transportauftrag. Kein SAP-Neustart. Kein Change-Management-Ticket für eine Softwareinstallation. Kein Kompatibilitätstest mit der jeweiligen SAP-Version. Nach der initialen Plattformkonfiguration ist weder SAP noch der Monitoring-Anbieter an der Anbindung beteiligt.
Bei einem agentenbasierten Ansatz umfasst derselbe Ablauf das Erstellen und Testen eines Transports in der Entwicklung, die Planung der Übernahme in die Qualitätssicherung, Tests in der Qualitätssicherung, die Planung der Produktivübernahme, den Rollout in einem Change-Fenster und die anschließende Funktionsprüfung des Agenten. Je nach Change-Management-Takt des Unternehmens dauert diese Abfolge eine bis drei Wochen. Für einen MSP, der das System eines neuen Kunden aufnimmt, hat der Unterschied zwischen einer Stunde und drei Wochen direkte wirtschaftliche Auswirkungen.
MSPs und große IT-Teams profitieren unterschiedlich
Für einen MSP, der SAP-Umgebungen mehrerer Kunden verwaltet, verändert die agentenlose Architektur die Wirtschaftlichkeit jedes neu angebundenen Systems. Die Onboarding-Kosten bleiben niedrig und vorhersehbar. Der laufende Wartungsaufwand wächst nicht mit der Zahl der Systeme. Ein Team, das 50 SAP-Systeme agentenlos überwacht, trägt pro System dieselbe laufende Wartungslast wie ein Team mit 5 Systemen. Bei Agenten muss das Team mit 50 Systemen dagegen den zehnfachen Wartungsumfang bewältigen.
Dieser Unterschied betrifft nicht nur die Effizienz. Er beeinflusst auch, welche Services der MSP glaubwürdig anbieten kann. Bei geringem Monitoring-Wartungsaufwand lässt sich die Überwachung in ein Standardpaket für Managed Services integrieren, ohne den Preis pro System künstlich zu erhöhen. Bei hohem Aufwand muss der MSP die Kosten entweder zulasten seiner Marge selbst tragen oder als Monitoring-Aufschlag weitergeben, wodurch das Angebot weniger wettbewerbsfähig wird.
Für große Unternehmens-IT-Teams, die ihre SAP-Landschaften intern verwalten, liegt der Vorteil an anderer Stelle. Der Engpass ist meist nicht der Preis pro System, sondern die verfügbare Arbeitszeit der Engineers. Eine Architektur, die weder bei jedem SAP-Upgrade ihre Beteiligung noch eine Abstimmung zwischen SAP- und Monitoring-Team für Kompatibilitätstests erfordert, schafft Zeit für wertschöpfendere Aufgaben. Das SAP-Team verantwortet die Upgrades, das Monitoring-Team die Plattform. Für die laufende Wartung ist keine gegenseitige Beteiligung nötig.
Eine Architektur, die beim Skalieren schlank bleibt
Die meisten Infrastrukturen werden komplexer, je mehr Systeme sie umfassen. Mehr Systeme bedeuten mehr Agenten, mehr Konfigurationen, mehr Einträge in Kompatibilitätsmatrizen und mehr parallele Wartungsstränge. Der operative Aufwand wächst proportional mit der Landschaft und wird ab einem bestimmten Punkt zur wichtigsten betrieblichen Einschränkung statt zu einem Hintergrundkostenfaktor.
Agentenloses Monitoring kehrt diese Beziehung um. Ein neues SAP-System wird immer auf dieselbe Weise an die Monitoring-Landschaft angebunden, unabhängig davon, ob es das fünfte oder das fünfzigste ist: ein RFC-Benutzer, eine Berechtigungsrolle, ein Datenbankbenutzer und ein Konfigurationseintrag im Collector. Die Komplexität der Monitoring-Infrastruktur wächst nicht mit der Anzahl der überwachten Systeme. Sie konzentriert sich auf den Collector, also auf einen einzigen Investitionspunkt, der von der gesamten überwachten Landschaft gemeinsam genutzt wird.
Dieser stabile Betriebsaufwand bei wachsender Landschaft macht agentenloses Monitoring zur passenden Standardarchitektur für Unternehmen, die mehr als nur wenige SAP-Systeme verwalten. Nicht weil Agenten grundsätzlich falsch sind, sondern weil sich ihre Wartungskosten summieren und schließlich dominieren. Ohne Agenten fällt diese Variable vollständig aus der Rechnung. Redpeaks verbindet sich per RFC und HANA SQL mit SAP, ohne Agenten, Transporte oder SAP-seitige Software. Nach dem Anlegen des RFC-Benutzers liefert ein neues System meist innerhalb einer Stunde Monitoring-Daten. Zur Verbindungsarchitektur.
