Ein Financial Controller öffnet jeden Morgen um 07:30 Uhr das tägliche Umsatz-Dashboard. Der Bericht ist immer da, immer befüllt, immer mit den Daten der vergangenen Nacht aktualisiert. Bis zu einem Mittwoch, an dem er zwar vorhanden ist, aber leer bleibt. Keine Fehlermeldung. Die geplante Instanz zeigt in der Central Management Console den Status Success. Der Bericht wurde ausgeführt, hat aber keine Daten geliefert. Die Verbindung zur Datenquelle ist während der Ausführung abgelaufen, die Abfrage hat null Zeilen zurückgegeben und BusinessObjects hat dies als erfolgreiche Ausführung behandelt.
Dieses Szenario ist nicht ungewöhnlich. Es ist typisch für schlecht umgesetztes BusinessObjects Monitoring: Das System meldet auf technischer Ebene Erfolg, liefert aber auf Business-Ebene einen Fehler. Der Zeitplan wurde ausgeführt. Der Bericht ist vorhanden. Das Dashboard ist leer.
BusinessObjects nimmt in der SAP-Landschaft eine Position ein, die leicht zu wenig überwacht wird. Es ist kein transaktionales System. Fehler blockieren Geschäftsprozesse nicht sofort so, wie es ein SAP ERP-Ausfall tun würde. Probleme sammeln sich an: Berichte, die stillschweigend nicht mehr laufen, Nutzer, die vorgesehene Publikationen nicht mehr erhalten, Rendering-Zeiten, die sich innerhalb von sechs Monaten verdoppelt haben. Wenn das Problem schließlich bei jemandem ankommt, der es beheben kann, besteht es oft schon seit Wochen.
Dieser Artikel beschreibt das Monitoring, das solche Fehler tatsächlich erkennt: was in der Scheduling-Schicht überwacht werden sollte, wie sich Service Health über die reine CMC-Anzeige hinaus bewerten lässt, welche User Experience Metriken wirklich relevant sind und wo sich die wertvollsten Monitoring-Daten in einer BOBJ-Umgebung befinden, obwohl sie häufig ungenutzt bleiben.
Warum sich BusinessObjects Monitoring vom Monitoring eines SAP Application Servers unterscheidet
Die CMC ist eine Administrationskonsole, kein Monitoring-Tool
Die meisten BOBJ-Administratoren nutzen die Central Management Console als primäre operative Ansicht. Sie zeigt Service-Zustände, aktuelle geplante Job-Instanzen, User Sessions und Systemkonfigurationen. Sie ist das richtige Tool zur Verwaltung der Umgebung. Sie ist jedoch nicht für kontinuierliches Monitoring ausgelegt.
Die CMC zeigt den aktuellen Zustand, nicht den historischen Verlauf. Ein Service, der um 03:00 Uhr abgestürzt und neu gestartet wurde, erscheint um 09:00 Uhr als Running, ohne sichtbaren Hinweis auf den Neustart, es sei denn, der Administrator weiß, dass er in der Audit-Datenbank oder in den Server-Logs nachsehen muss. Ein geplanter Bericht, der ein leeres Ergebnis erzeugt hat, erscheint in der Job-Instanzhistorie mit einem grünen Success-Indikator. Ein Bericht, der seit zwei Wochen bei jeder zweiten Ausführung stillschweigend fehlschlägt, zeigt in der Instanzhistorie eine Mischung aus Success- und Failed-Einträgen. Die tatsächliche Erfolgsquote ist nur sichtbar, wenn sie jemand manuell berechnet.
Externes Monitoring, das kontinuierlich die BOBJ Service Health, die Ergebnisse von Job-Instanzen und den Systemressourcenverbrauch abfragt, leistet genau das, was die CMC nicht kann: Es zeichnet Zustandsfolgen über die Zeit auf, korreliert Ereignisse über mehrere Services hinweg und erzeugt Alerts, wenn Bedingungen vom Normalzustand abweichen, statt eine manuelle Prüfung vorauszusetzen.
Service-Zustand und Service Health sind nicht dasselbe
BusinessObjects besteht aus mehreren Server-Services: dem Central Management Server (CMS), den File Repository Servers (Input und Output FRS), dem Adaptive Processing Server (APS), dem Web Intelligence Processing Server, dem Crystal Reports Processing Server, dem Adaptive Job Server, dem Connection Server und je nach Version und eingesetzten Modulen weiteren Komponenten. Jeder Service hat einen in der CMC sichtbaren Zustand: Running, Stopped, Failed.
Running bedeutet, dass der Service-Prozess aktiv ist und dem CMS antwortet. Es bedeutet nicht, dass der Service Anfragen korrekt verarbeitet. Ein Adaptive Job Server im Status Running, dessen Processing Thread Pool jedoch ausgelastet ist, nimmt keine neuen geplanten Jobs mehr auf. Neue Jobs stauen sich hinter bestehenden Jobs, ohne dass der Server-Service selbst einen Fehler anzeigt. Ein Web Intelligence Processing Server im Status Running, der unter Speicherdruck steht, verarbeitet Berichtsanfragen langsam, ohne einen abnormalen Zustand in der CMC anzuzeigen.
Service Health, im Unterschied zum reinen Service-Zustand, erfordert Metriken jenseits der Prozessverfügbarkeit: Queue Depth pro Service, Anzahl aktiver Sessions, Speicherverbrauch pro Service-Prozess und Fehlerraten eingehender Anfragen. Diese Metriken sind über die BOBJ REST API und über die Audit-Datenbank verfügbar. In der Service-Zustandsanzeige der CMC sind sie nicht sichtbar. Ein Monitoring-Ansatz, der nur den Service-Zustand prüft, meldet ein gesundes System in Situationen, die Nutzer als langsam oder nicht erreichbar erleben.
Monitoring der Scheduling-Schicht: mehr als Pass oder Fail
Was Success bei einer geplanten Job-Instanz wirklich bedeutet
Ein geplanter BusinessObjects-Bericht erreicht den Status Success, wenn das Berichtsprogramm ohne Exception ausgeführt wird und die Ausgabedatei in den File Repository Server geschrieben wurde. Keine dieser Bedingungen setzt voraus, dass der Bericht tatsächlich Daten enthält. Ein Bericht, dessen Abfrage null Zeilen zurückgibt, weil die Datenquelle ein leeres Ergebnis geliefert hat, wird mit Success abgeschlossen. Ein Bericht, dessen Verbindung zur Datenquelle nach drei Versuchen abläuft, dann aber beim vierten Versuch gelingt und nur teilweise Daten liefert, wird ebenfalls mit Success abgeschlossen, wenn die finale Ausführung keine Exception auslöst.
Für Berichte, die als operative Dashboards oder Management-Zusammenfassungen genutzt werden, ist der Unterschied zwischen technischem Erfolg und sinnvoller Auslieferung entscheidend. Genau hier trennt sich wirksames Monitoring von Monitoring, das nur bestätigt, was die Nutzer bereits als falsch erkannt haben. Eine Ausgabe mit null Zeilen in einem Bericht, der normalerweise Hunderte von Zeilen enthält, ist ein Auslieferungsfehler. Um ihn zu erkennen, muss die Ausgabe überwacht werden, nicht nur die Ausführung.
Die Monitoring-Prüfung ist für Berichte mit bekannter erwarteter Ausgabengröße relativ einfach: Die Zeilenzahl oder Dateigröße der aktuellen Instanz wird mit dem historischen Durchschnitt desselben Berichts zum gleichen geplanten Zeitpunkt verglichen. Ein Bericht, der normalerweise eine 2 MB große Ausgabe erzeugt und aktuell nur 4 KB produziert, ist keine erfolgreiche Auslieferung, unabhängig davon, was der CMC-Instanzstatus meldet. Dieser Vergleich erfordert Zugriff auf die FRS-Ausgabedatei-Metadaten und auf die historischen Ausführungsdaten der Audit-Datenbank, ist aber ohne individuelle Entwicklung umsetzbar.
Zero-Row-Berichte: der stille Auslieferungsfehler, den niemand erkennt
Ausgaben mit null Zeilen sind häufiger, als viele BOBJ-Administratoren vermuten, weil sie für die Standard-Monitoring-Schicht unsichtbar bleiben. Sie treten häufig in bestimmten Mustern auf. Timeouts bei Verbindungen zu Datenquellen, die nach Wiederholungsversuchen zwar erfolgreich sind, aber zu spät, um sinnvolle Daten abzurufen. Datumsfilterparameter in Berichtsabfragen, die bei Erstellung des Zeitplans korrekt waren, sich aber mit dem Alter des Berichts verschoben haben. Universums- oder Query-Panel-Filter, die auf einen Prompt mit einem Standardwert verweisen, der inzwischen zu keinen Daten mehr passt.
Der praktikable Monitoring-Ansatz besteht darin, erwartete Ausgabebereiche für Tier-1-Berichte zu pflegen, also für Berichte, auf die sich Business-Stakeholder aktiv verlassen. Für einen wöchentlichen Sales Report kann ein erwarteter Bereich von 500 bis 2.000 Zeilen, basierend auf historischen Ausführungen, sowohl den Zero-Row-Fehler als auch ungewöhnlich kleine Ergebnismengen erkennen, die auf eine teilweise Datenabfrage hindeuten können. Jede Ausführung außerhalb dieses Bereichs sollte zur Prüfung markiert werden.
Das bedeutet nicht, jeden Bericht der Umgebung auf diese Weise zu überwachen. Es bedeutet, die 20 bis 30 Berichte zu identifizieren, die bei leerer oder falscher Auslieferung sofort eine Business-Eskalation auslösen würden, und die Ausgabengrößenprüfung gezielt auf diese Berichte anzuwenden. Die 80 % der Berichte in der Umgebung, die eher operative Abfragen mit geringem Risiko sind, benötigen dieses Maß an Monitoring nicht.
Wiederkehrende Zeitpläne, die stillschweigend nicht mehr wiederkehren
Wiederkehrende BusinessObjects-Zeitpläne haben eine leicht zu unterbrechende Abhängigkeit vom CMS. Ein Bericht, der täglich um 06:00 Uhr ausgeführt werden soll, ist darauf angewiesen, dass der Adaptive Job Server die ausstehende Instanz zur geplanten Zeit aufnimmt. Wenn der Adaptive Job Server um 05:55 Uhr gestoppt oder neu gestartet wurde und um 06:00 Uhr noch nicht vollständig läuft, kann es sein, dass die Instanz nicht erstellt wird. Der nächste geplante Zeitpunkt ist dann morgen um 06:00 Uhr. Der Zeitplan ist nicht fehlgeschlagen. In der CMC wird kein Problem angezeigt. Der Bericht wurde einfach nicht ausgeführt.
Ein Service-Neustart, der sich mit einem geplanten Ausführungsfenster überschneidet, erzeugt eine Lücke, die unsichtbar bleibt, wenn die geplante Ausführung nicht anhand der erwarteten Ausführungszeit überwacht wird. Monitoring, das prüft, ob ein bestimmter Zeitplan innerhalb eines definierten Fensters nach der erwarteten Ausführungszeit eine neue Instanz erzeugt hat, erkennt diese Lücke. Ein Zeitplan für 06:00 Uhr, der bis 06:15 Uhr keine neue Instanz erzeugt hat, ist ein Alert-Fall, unabhängig davon, welche Service-Zustände angezeigt werden.
Die heimtückischere Variante ist ein Zeitplan, der während eines Wartungsfensters von einem Administrator pausiert und danach nie wieder aktiviert wurde. Der Zeitplan existiert in der CMC im Status paused. Der Bericht wurde zuletzt vor drei Wochen ausgeführt. Niemand hat es bemerkt, entweder weil sich die Verteilerliste nicht beschwert hat oder weil das Fehlen des Berichts noch keinen sichtbaren Geschäftsprozess beeinflusst hat.
Achtung: Die publikationsbasierte Verteilung in BusinessObjects fügt eine zusätzliche Schicht von Fehlermodi hinzu, die reines Schedule Monitoring nicht erkennt. Eine Publikation kann erfolgreich ausgeführt werden, Berichtsinstanzen erzeugen und in der Verteilung dennoch stillschweigend scheitern, wenn der SMTP-Server nicht verfügbar ist oder die Ziel-E-Mail-Adressen ungültig sind. Der Status der Publikations-Job-Instanz muss separat vom Status der Berichtsgenerierung überwacht werden, um zu bestätigen, dass die Auslieferung und nicht nur die Generierung abgeschlossen wurde.
Server-Service-Monitoring: die Komponenten, die Berichtsverfügbarkeit bestimmen
CMS-Verfügbarkeit und die Kaskade, die sie steuert
Der Central Management Server ist der Authentifizierungs- und Metadaten-Hub der gesamten BusinessObjects-Umgebung. Jeder User Login, jeder Berichtszugriff und jede Erstellung einer geplanten Job-Instanz läuft über den CMS. Ein nicht verfügbarer oder degradierter CMS erzeugt keine partiellen Fehler, sondern verhindert den Zugriff auf das System insgesamt.
Die Überwachung der CMS-Verfügbarkeit ist der wichtigste Einzelcheck in der BOBJ-Landschaft. Verfügbarkeitsmonitoring allein verpasst jedoch den degradierten Zustand, der einem CMS-Ausfall häufig vorausgeht. Ein CMS unter Speicherdruck verarbeitet Authentifizierungsanfragen langsamer. Login-Zeiten steigen von unter einer Sekunde auf mehrere Sekunden. Berichte öffnen sich langsamer als üblich, weil CMS-Metadatenabfragen verzögert sind. Das System ist technisch verfügbar. Für Nutzer fühlt es sich trotzdem beinahe nicht verfügbar an.
Die CMS-Metriken, die kontinuierlich überwacht werden sollten, sind der Speicherverbrauch im Verhältnis zum konfigurierten Java Heap, die Anzahl aktiver Datenbankverbindungen zur CMS-Repository-Datenbank und, sofern über die REST API zugänglich, die Antwortzeiten von Authentifizierungsanfragen. Ein CMS bei 85 % Heap-Auslastung löst Garbage-Collection-Zyklen aus, die die Authentifizierungsverarbeitung pausieren können. Eine erschöpfte Connection Pool Kapazität verhindert neue Sessions. Verschlechterte CMS-Antwortzeiten sind ein Frühindikator für kommende Verfügbarkeitsprobleme.
Adaptive Processing Server und Adaptive Job Server: Kapazität und Queue Depth
Der Adaptive Processing Server übernimmt die Dokumentverarbeitung, Suchindexierung und je nach eingesetzter Version mehrere Berichtstypen. Der Adaptive Job Server steuert die Ausführung geplanter Jobs: Er nimmt ausstehende geplante Instanzen auf, weist sie den passenden Processing Servern zu und verfolgt ihre Ausführung.
Die Queue Depth des Adaptive Job Servers ist die Metrik, die Scheduling-Kapazitätsprobleme sichtbar macht, bevor sie Lieferzeiten beeinträchtigen. Unter normalen Bedingungen werden ausstehende Job-Instanzen wenige Sekunden nach ihrer geplanten Zeit aufgenommen und gestartet. Wenn die Verarbeitungskapazität aller verbundenen Processing Server ausgelastet ist, warten neue ausstehende Instanzen in der Queue. Nutzer, deren Berichte für 06:00 Uhr geplant waren, erhalten sie um 07:15 Uhr, weil sich die Queue erst um 07:14 Uhr geleert hat.
Weder die verzögerte Auslieferung noch die Queue Depth sind in der Standard-CMC-Oberfläche sichtbar, es sei denn, ein Administrator öffnet die Job Queue Ansicht und zählt ausstehende Instanzen manuell. Externes Monitoring, das die Queue Depth des Job Servers regelmäßig abfragt und einen Alert auslöst, wenn sich ausstehende Instanzen ansammeln, liefert die Transparenz, die manuelle Prüfungen in einer Produktionsumgebung nicht dauerhaft sicherstellen können.
Connection Server und die Datenquellen-Schicht
Der BusinessObjects Connection Server verwaltet Datenbankverbindungen von Berichten zu den zugrunde liegenden Datenquellen. Er pflegt Connection Pools für jede konfigurierte Verbindung, steuert Wiederholungsversuche und stellt die Abstraktionsschicht bereit, über die Berichte unabhängig vom aktiven physischen Datenbankserver ausgeführt werden können.
Fehler des Connection Servers erzeugen ein bestimmtes Muster: Berichte beginnen gleichzeitig mit Datenbankverbindungsfehlern zu scheitern, wenn sie dieselbe Datenquellenverbindung verwenden. Der Fehler konzentriert sich auf eine Datenquelle und verteilt sich nicht zufällig über die gesamte Berichtslandschaft. Dieses Konzentrationsmuster weist eher auf den Connection Server oder die Datenquelle selbst hin als auf ein berichtsspezifisches Problem.
Die zu überwachenden Metriken auf dem Connection Server sind Verbindungsfehlerraten nach Verbindungsname, aktive Verbindungen im Verhältnis zum Pool-Maximum und durchschnittliche Abfrageausführungszeit pro Verbindung. Wenn sich die Anzahl aktiver Verbindungen dem Pool-Maximum nähert, müssen neue Berichtsausführungen auf eine freie Verbindung warten. Eine Verbindung, deren durchschnittliche Abfragezeit sich in der vergangenen Woche verdoppelt hat, ist nicht ausgefallen, zeigt aber eine Verschlechterung der Datenquellen-Gesundheit, die Ausfällen vorausgehen kann.
User Experience Metriken: Rendering-Zeit, Sessions und Cache
Berichtsrenderezeit als Signal für Servicequalität
Es gibt einen erheblichen Unterschied zwischen einem Bericht, der in 12 Sekunden läuft, und einem Bericht, der 45 Sekunden benötigt, selbst wenn beide von einem einzelnen Nutzer noch als akzeptabel wahrgenommen werden. Der 45-Sekunden-Bericht belegt einen Processing Slot auf dem Web Intelligence Processing Server fast viermal so lange und reduziert dadurch die verfügbare Kapazität für andere gleichzeitige Nutzer. Wenn 10 Nutzer denselben langsamen Bericht gleichzeitig anfragen, ist der Processing Server über eine Dauer belegt, in der 40 ähnliche Berichte mit einer 12-Sekunden-Baseline hätten verarbeitet werden können.
Die Rendering-Zeit pro Bericht, über längere Zeit verfolgt, ist die Metrik, die Performance-Regressionen erkennt, bevor sie sichtbare Kapazitätsprobleme erzeugen. Ein Web Intelligence Bericht, der im letzten Quartal in 8 Sekunden gerendert wurde und nun konstant 25 Sekunden benötigt, hat irgendwo eine Performance-Regression erfahren: eine Universe-Änderung, die eine weniger effiziente Abfrage eingeführt hat, ein Datenvolumenwachstum, das einen Schwellenwert im Query Plan überschritten hat, oder ein Datenbankindex, der gelöscht oder falsch neu aufgebaut wurde. Um diese Regression früh zu erkennen, bevor sie nachgelagerte Kapazitätsprobleme verursacht, sind historische Rendering-Zeitdaten erforderlich.
Die Audit-Datenbank zeichnet die Ausführungszeit jeder Berichtsinstanz auf. Wenn diese Daten für Trends pro Bericht ausgewertet werden, statt nur durchschnittliche Rendering-Zeiten über die gesamte Umgebung zu betrachten, werden genau die Berichte sichtbar, deren Performance sich verschlechtert hat. Durchschnittliche Rendering-Zeiten über Hunderte von Berichten werden von wenigen sehr schnellen und wenigen sehr langsamen Berichten dominiert. Sie verändern sich kaum, selbst wenn einzelne Berichte deutlich schlechter geworden sind.
Lizenzauslastung: die Metrik, die stille Lockouts verursacht
BusinessObjects-Lizenzierung nutzt in den meisten Enterprise-Deployments entweder Named User Lizenzen, bei denen jeder Nutzer eine dedizierte Lizenz hat, oder Concurrent Access Lizenzen, bei denen ein Lizenzpool von allen Nutzern geteilt wird und die Grenze durch die Anzahl gleichzeitiger Sessions definiert ist. Beide Modelle haben eine Obergrenze. Wenn diese Grenze erreicht wird, geschieht dies oft still.
Bei Concurrent Access Lizenzen erhalten neue Nutzer, die sich anmelden möchten, eine Meldung, dass keine Sessions verfügbar sind, sobald die Session-Anzahl das lizenzierte Maximum erreicht. Sie können sich nicht anmelden. Es gibt keinen Alert an den BOBJ-Administrator, keine E-Mail, kein Monitoring-Event. Der Administrator entdeckt das Problem erst, wenn ein Nutzer eskaliert. Zu diesem Zeitpunkt konnten bereits eine unbekannte Anzahl von Nutzern über eine unbekannte Dauer nicht auf das System zugreifen.
Monitoring der gleichzeitigen Session-Anzahl im Verhältnis zum Lizenzlimit, mit einem Alert bei 80 % des Maximums, schafft Zeit, entweder eine kurzfristige Lizenzerweiterung anzufordern oder zu prüfen, ob verwaiste Sessions Lizenzen verbrauchen, ohne dass aktive Nutzer dahinterstehen. Verwaiste Sessions entstehen häufig, wenn Nutzer den Browser schließen, ohne sich korrekt abzumelden. Sie sammeln sich in BOBJ-Umgebungen mit der Zeit an, wenn die Session Timeout Konfiguration nicht korrekt gesetzt ist.
Bei Named User Lizenzierung liegt das Risiko anders: Neue Nutzer werden hinzugefügt, ohne die verbleibende Lizenzkapazität zu prüfen. Eine Organisation, die 500 Named User Lizenzen gekauft und 498 Nutzer provisioniert hat, hat kaum Spielraum, um Auftragnehmer, temporäre Mitarbeitende oder neue Teammitglieder hinzuzufügen, ohne einen Lizenzbeschaffungsprozess auszulösen. Monitoring der provisionierten Nutzerzahl im Verhältnis zum Lizenzlimit zeigt dieses Risiko, bevor die Grenze erreicht wird.
Cache-Performance und warum veraltete Daten ein Monitoring-Problem sind
Web Intelligence und andere BusinessObjects-Berichtstypen unterstützen einen Report Cache Mechanismus: Die Daten eines frisch ausgeführten Berichts werden im Cache gespeichert, und nachfolgende Anfragen für denselben Bericht werden aus dem Cache bedient, statt die Datenbankabfrage erneut auszuführen. Das ist leistungsfördernd, wenn viele Nutzer denselben Bericht öffnen und sich die zugrunde liegenden Daten nur selten ändern.
Die Cache-Invalidierung ist der Punkt, an dem Monitoring besonders wertvoll wird. Ein Report Cache, der um 08:00 Uhr gültig war, kann um 14:00 Uhr veraltete Daten enthalten, wenn die zugrunde liegenden Daten aktualisiert wurden, der Cache aber nicht aktualisiert wurde. Nutzer, die den gecachten Bericht öffnen, sehen Daten, die nicht mehr der aktuellen Realität entsprechen. Sie treffen möglicherweise Entscheidungen auf dieser Grundlage. Das technische System funktioniert normal. Die ausgelieferte Business-Information ist falsch.
Monitoring des Cache-Alters pro Bericht im Verhältnis zur Aktualisierungsfrequenz der zugrunde liegenden Daten identifiziert Berichte, bei denen der Cache veraltete Informationen liefern könnte. Ein Bericht zu täglichen Umsatzzahlen, dessen Cache zuletzt vor 36 Stunden aktualisiert wurde, liefert nicht die Daten, die Nutzer während der Geschäftszeiten erwarten. Die passende Monitoring-Reaktion ist entweder ein Trigger zur Cache-Invalidierung oder ein Alert an den Report Owner, dass der Refresh-Zeitplan angepasst werden muss.
Die Audit-Datenbank: die Monitoring-Quelle, die die meisten BOBJ-Umgebungen ignorieren
Was die Audit-Datenbank tatsächlich enthält
SAP BusinessObjects führt eine Audit-Datenbank, die jedes bedeutende Ereignis im System aufzeichnet: jeden User Login und Logout, jede Berichtsansicht, jeden Start und jedes Ende einer geplanten Job-Ausführung, jede Publikationsauslieferung, jeden fehlgeschlagenen Authentifizierungsversuch sowie jede Dokumenterstellung und Dokumentlöschung. In den meisten Produktionsumgebungen läuft diese Datenbank seit Jahren und enthält eine vollständige operative Historie der BusinessObjects-Landschaft.
Die Audit-Datenbank wird in Organisationen, die sie überhaupt nutzen, meist für Compliance Reporting verwendet. Für Monitoring wird sie fast nirgends eingesetzt. Das ist eine verpasste Chance, denn sie ist die reichhaltigste operative Datenquelle in einer BOBJ-Umgebung. Die meisten externen Monitoring-Tools für BOBJ fragen die CMS REST API nach Echtzeit-Zustandsinformationen ab. Die Audit-Datenbank ergänzt die historische Dimension, die die REST API nicht liefern kann: nicht nur, was jetzt passiert, sondern was passiert ist und wie sich das vom Normalverhalten unterscheidet.
Die für Monitoring-Zwecke wichtigsten Tabellen der Audit-Datenbank sind das Event Log mit allen Events nach Typ, Zeitstempel, Nutzer und Status, das Job Execution Log mit geplanten Instanzen, Timing, Erfolg oder Fehler und Ausgabemetadaten sowie das Session Log mit Login- und Logout-Ereignissen einschließlich Session-Dauer. Zusammen liefern diese drei Tabellen alles, was für trendbasiertes Monitoring von Scheduling-Erfolgsraten, Nutzeraktivitätsmustern und Berichtsperformance über die Zeit benötigt wird.
Audit-Daten für proaktives Monitoring nutzen
Die Audit-Datenbank ermöglicht eine Monitoring-Kategorie, die Echtzeit-Polling nicht abdecken kann: Anomalieerkennung auf Basis historischer Muster. Wenn ein bestimmter Bericht seit 18 Monaten an jedem Werktag um 06:00 Uhr läuft und heute nicht ausgeführt wurde, lässt sich dieses Fehlen durch eine Abfrage der Audit-Datenbank auf die erwartete Ausführung erkennen. Wenn ein Nutzerkonto 90 Tage inaktiv war und plötzlich 200 Login-Ereignisse innerhalb von 10 Minuten zeigt, ist diese Anomalie aus den Session Log Daten erkennbar.
Praktischer ausgedrückt ermöglicht die Audit-Datenbank die Berechnung von Scheduling-Erfolgsraten über rollierende Zeiträume. Ein Bericht mit einer Erfolgsquote von 98 % in den letzten 30 Tagen verhält sich normal. Derselbe Bericht mit 72 % in den letzten 7 Tagen verschlechtert sich und sollte untersucht werden, bevor die Fehlerrate hoch genug wird, um Geschäftsprozesse zu beeinträchtigen, die von ihm abhängen.
Der Umsetzungsweg für Audit-Datenbank-basiertes Monitoring ist ein geplanter Abfragejob, der aggregierte Metriken aus den Audit-Tabellen extrahiert und an eine Monitoring-Plattform übergibt. Das ist keine komplexe technische Implementierung. Es erfordert allerdings, dass die Zugangsdaten zur Audit-Datenbank für die Monitoring-Plattform verfügbar sind und dass das Monitoring-Team versteht, welche Audit-Event-Typen welchen operativen Bedingungen entsprechen. Dieses Verständnis ist die größte Hürde. Die Daten sind bereits vorhanden.
Hinweis: Die Audit-Datenbank wächst kontinuierlich mit jedem Systemereignis und benötigt eine Retention- und Archivierungsstrategie, um als Abfragequelle performant zu bleiben. In Umgebungen mit hoher Aktivität kann die Event Log Tabelle über einige Jahre auf Hunderte Millionen Zeilen anwachsen. Abfragen ohne passende Indexierung und ohne Datumsbereichsfilterung erzeugen langsame Queries, die mit normaler Systemaktivität konkurrieren. Die meisten BOBJ-Administratoren wissen, dass die Audit-Datenbank existiert, haben sie aber nicht für effiziente Abfragen gepflegt. Bevor sie als Monitoring-Quelle genutzt wird, sollten Indexierungsstrategie und Datenaufbewahrungsfenster geprüft werden, um historische Tiefe und Query Performance sinnvoll auszubalancieren.
Wovor BOBJ Monitoring schützen muss
BusinessObjects nimmt in der SAP-Landschaft eine besondere Position ein: Es ist die Schicht, in der Business-Daten zu Business-Informationen werden. Die transaktionalen Daten, die ERP-Systeme erzeugen, sind erst dann wirklich nützlich, wenn eine Person sie sehen, interpretieren und darauf reagieren kann. Wenn Berichte nicht laufen, langsam laufen oder falsche Daten liefern, wird der Wert der zugrunde liegenden transaktionalen Systeme beeinträchtigt, unabhängig davon, wie gut diese Systeme selbst funktionieren.
Die Monitoring-Herausforderung besteht darin, dass die spezifischen Fehler dieser Schicht keine Infrastrukturfehler sind. Ein ausgefallener Server ist offensichtlich. Ein Bericht, der läuft, aber leere Daten liefert, ist es nicht. Eine Publikation, die versendet wird, aber an die falsche Empfängerliste geht, ist es nicht. Eine Rendering-Zeit, die sich über drei Monate verdoppelt hat, ist es nicht. Genau diese Fehlermodi sammeln sich in BOBJ-Umgebungen still an, ohne Standard-Infrastruktur-Alerts auszulösen.
Sie zu erkennen erfordert Monitoring unterhalb der reinen Service-State-Ebene: Output-Validierung für kritische geplante Berichte, Queue-Depth-Tracking auf Processing Servern, Rendering-Zeittrends pro Bericht, Session-Zahlen im Verhältnis zu Lizenzlimits und Audit-Datenbankabfragen, die Muster sichtbar machen, die Echtzeit-Polling nicht erkennt. Nichts davon ist schwer umzusetzen. Es erfordert vor allem, BusinessObjects als System mit eigenen spezifischen Fehlermodi zu behandeln, statt es wie einen Server zu betrachten, der entweder up oder down ist.
Redpeaks überwacht SAP BusinessObjects-Umgebungen, einschließlich Service-Verfügbarkeit, Erfolgsraten von Job-Instanzen, Rendering-Zeittrends und Lizenzauslastung, über eine einzige agentenlose Verbindung zur BOBJ-Landschaft und zu den zugrunde liegenden SAP-Systemen. Entdecken Sie die BusinessObjects Monitoring Coverage.
