Seit den frühen 90er Jahren betreibt die Stadtreinigung Hamburg (SRH) ein SAP-R/3-System. Mit den Jahren wuchsen nicht nur der Kreis der Benutzer und der genutzten Module, sondern auch die Ansprüche des Unternehmens an Performance und Verfügbarkeit. Dies machte ein Monitoring und Alerting erforderlich. Die Suche nach Software, die für unsere Zwecke ein optimales Preis-Leistungs-Verhältnis bieten sollte, führte uns zu der GPL-Lösung "Nagios", die sich mit geringem Aufwand nicht nur für die Überwachung der Systeme "von außen" sondern auch per Auswertung des SAP-internen CCMS für ein Monitoring der Performance nutzen ließ. Sogar rudimentäre Berichte ließen sich erstellen.
Open-Source-Tool Nagios reichte nicht mehr aus
Mit Eintritt in das neue Jahrtausend stieg bei uns nicht nur der Kostendruck auf die IT, sondern wir waren auch mit der Forderung des Managements nach einem aussagefähigen Reporting des SAP-Produktivsystems konfrontiert. Da sich dies mit Nagios nicht ohne weiteres bewerkstelligen ließ, schafften wir nach einer Marktanalyse den "theGuard Applicationmanager (AM)" von Realtech an. Mittlerweile nutzen wir die Software seit Herbst 2005 produktiv. Mit Hilfe des AM können wir wesentlich detaillierter Daten aus der SAP-Umgebung sammeln und in Form von Reports darstellen. Unlängst wurde die R/3-Installation auf ERP 6.0 umgestellt. Hierzu mussten einige wenige Anpassungen im Verwaltungswerkzeug vorgenommen werden. Neben dem ERP-System von SAP nutzt die Stadtreinigung auch das Branchenpaket SAP Waste & Recycling.
SAP-Antwortzeiten und Statistiken
Die ERP-Software läuft im Rechenzentrum des Hosting-Anbieters BTC AG in Oldenburg, die Realtech-Software hingegen in unserem eigenen Rechenzentrum. Die von dem Applicationmanager erzeugten Berichte eignen sich auch dafür, die Leistungen des Hosters zu überprüfen und diesen auf Leistungsengpässe aufmerksam zu machen. Das SAP-System zeichnet Antwortzeiten auf und erstellt daraus Statistiken, doch die sind zu ungenau. An den Anwenderarbeitsplätzen kommt es schon einmal vor, dass Transaktionen lange dauern, was dann durch die SAP-Standardauswertungen schwer nachzuweisen ist.
Anhand der Aufzeichnungen des Tools lässt sich zum Beispiel feststellen, welche Antwortzeit einzelne Transaktionen hatten. Das ist insbesondere im Kunden-Service-Center wichtig, in dem die Mitarbeiter im Kundengespräch schnell auf alle relevanten Informationen im System zugreifen und Vorfälle bearbeiten müssen.
Das bei der Stadtreinigung installierte Paket umfasst einen theGuard- ApplicationManager-Server, eine "Reporting Console", einen SAP-DB-Datenkollektor, die "Abap-Suite" und vier Betriebssystem-Datenkollektoren. Der Server dient als Ablaufumgebung, die Abap-Suite analysiert Abläufe und Zustände des SAP-Systems, die weit über das Standardfunktionen zum Monitoring und zum Reporting hinausgehen. Das gesamte Projekt einschließlich einer Schulung kostete seinerzeit etwa 20.000 Euro.
Die Datensammler und die Alarmierungsregeln wurden konfiguriert, das Reporting jedoch erst später eingerichtet, da die Datenbasis noch zu wenige Werte enthielt. In einer weiteren Sitzung einige Wochen später richtete ein Spezialist des Anbieters nach unseren Wünschen und entsprechend den Service-Level-Agreements des Hosters das Reporting ein.
Leistungsdaten von ERP-Anwendergruppen
Die Abap-Suite versetzt uns in die Lage, genauer als das SAP-Standardwerkzeug CCMS die Performance von Transaktionen zu überwachen und darüber hinaus Leistungsdaten auch für Anwendergruppen, IP-Adressen und auf Wunsch auch für einzelne Anwender aufzuzeichnen und auszuwerten. Eskalationsroutinen sorgen dafür, dass Störfälle nicht unbeachtet bleiben. Die erste Warnung erhält die Basisadministration bei uns im Haus. Sollte sich nach einem bestimmten Zeitraum nichts an dem Zustand geändert haben, leitet das Monitoring-Werkzeug einen zweiten Alert an den Gruppenleiter. Konfigurieren lassen sich darüber hinaus spezielle Warnmeldungen für das Wochenende. Wir wollten durch das Eskalationssystem vermeiden, dass mehr Leute als notwendig durch Alarmmeldungen belästigt werden.
Anfängliche Probleme mit Linux-Rechnern
Es soll nicht verschwiegen werden, dass es auch ein paar kleine Hürden gab. Wir haben inzwischen den ersten AM-Release-Wechsel hinter uns, der das Phänomen beseitigt hat, dass ab und zu die Agenten auf den überwachten Linux-Maschinen "verstarben". Das Erneuern der ABAP-Suite beseitigte einen Fehler, der unter bestimmten Bedingungen zum Absturz des "Eventclients", der GUI des Realtech-Produkts, führte. Unser Hoster stellt uns die Applikation aus internen Gründen ab und zu auf wechselnder Hardware bereit, was dem Applicationmanager bis vor kurzem Probleme bereitete, da er mit eindeutig bezeichneten Rechnern ("Nodes") arbeitet. Mittlerweile gibt es jedoch die Möglichkeit, den Rechnernamen manuell zu ändern.
Inzwischen tut das Verwaltungssystem unauffällig seinen Dienst, alarmiert zuverlässig und lässt sich bequem über das GUI konfigurieren. Berichte verschickt das Werkzeug automatisch. Darüber hinaus lassen sich aus den Datenbeständen Trends ableiten, die eine wertvolle Planungsgrundlage darstellen. Die ABAP-Suite erspart uns die sonst erforderlichen Routineprüfungen im SAP-System, da beispielsweise Verbuchungsabbrüche, nicht funktionierende RFC-Verbindungen, als sicherheitskritisch eingestufte Aktionen, kurz alles, was wir früher ein- oder mehrmals täglich in Handarbeit überprüft haben, in der GUI zu sehen ist. Entsprechend den Einstellungen versendet das System Warnungen per E-Mail, SMS oder Fax. Mit dem Applicationmanager kann man auch Sprachnachrichten erzeugen, die wirksamer wären als eine SMS auf das Handy. Bei der Sprachvariante würde der IT-Experte vom System angerufen werden. Diesen Mechanismus nutzen wir noch nicht, da uns hierzu ein geeigneter Rechner fehlt. (fn)