In diesem Lernprogramm lernen Sie die zentralen Bestandteile des Monitor-Programmiermodells einschließlich seiner wesentlichen Programmierungselemente und deren Semantik kennen. Die Grundlage für das Monitor-Programmiermodell bilden die Monitor-Modelle.
Ein Monitor-Modell spezifiziert, auf welche Weise Sie eine überwachbare Entität wie zum Beispiel eine Geschäftsaktivität überwachen. Monitor-Modelle definieren, welchen Typ von Informationen Sie von dieser Entität empfangen und wie Sie diese Informationen verarbeiten können, um die Leistungsmerkmale dieser Entität festzustellen. Solche Entitäten können materiell (zum Beispiel Server oder ATMS (Advanced Text Management Systems)) oder abstrakt (wie zum Beispiel Projektstatus und Verkaufsleistungen) sein.
Monitor-Modelle basieren auf einem Programmiermodell, das für Business Monitoring entworfen wurde. Business Monitoring konzentriert sich auf die Erfassung von geschäftsbezogenen Statistikdaten wie zum Beispiel die monatlichen Verkaufszahlen nach Region oder dem Prozentsatz der Rücksendungen von Lieferungen nach Produktkategorie. Business Monitoring unterscheidet sich von der IT-Überwachung dadurch, dass die IT-Überwachung sich auf die Erfassung von Statistikdaten wie dem maximalen Transaktionsdurchsatz eines bestimmten Servers und eines Software-Stacks oder auf die durchschnittliche Antwortzeit eines Web-Service konzentriert. WebSphere Business Monitor ist nicht für die IT-Überwachung konzipiert und das Beispiel in diesem Lernprogramm ebenfalls nicht.
Das Beispiel in diesem Lernprogramm verfolgt den Ablauf eines Fahrdienstunternehmens 'Limousine Company'. Angenommen, Sie möchten die Fahrtaktivitäten Ihrer Fahrzeugflotte überwachen und tun dies bereits auf Papier. Wenn Sie ein Fahrzeug zuteilen, müssen Sie ein Arbeitsblatt mit dem Kennzeichen des Fahrzeugs, dem Namen des Fahrers, dem Namen des Fahrgastes und der Abhol- und Zieladresse, der vereinbarten Abholzeit und der geplanten Ankunftzeit am Zielort vorbereiten. Wenn der Fahrer sich bei Ihnen meldet, um Sie über eine Änderung zu informieren, müssen Sie Ihr Arbeitsblatt aktualisieren. Der Fahrer kann Ihnen ferner Echtzeitinformationen wie die tatsächlichen Ankunfts- und Abfahrtszeiten, den Status der Fahrt und die Dauer der Fahrt mitteilen. Die Überwachung dieser Informationen auf einem Arbeitsblatt ist schwierig. In Ihrem Unternehmen 'Limousine Company' verfügen Sie über mehrere Fahrer und mehrere Fahrzeuge. Das bedeutet, Sie müssen alle diese eingehenden Informationen auf unterschiedlichen Arbeitsblättern koordinieren.
Um die Effizienz Ihres Unternehmens zu verbessern, müssen Sie Statistikdaten erfassen und diese Arbeitsblätter regelmäßig analysieren. Sie möchten zum Beispiel die durchschnittliche, wöchentliche Fahrtstrecke eines Fahrzeugs berechnen, damit Sie Ihre Kraftstoffkosten vorhersagen und feststellen können, ob Sie Ihre Preise anpassen müssen. Ferner möchten Sie berechnen, wie lange Ihre Fahrzeuge durchschnittlich ungenutzt auf dem Parkplatz stehen, oder welche Fahrer am pünktlichsten sind oder wer Ihr bester Kunde ist. Sie können alle diese aufgezeichneten Informationen auf weiteren Arbeitsblättern eintragen und sie als Referenz in einem Ordner aufbewahren. Als Unternehmer benötigen Sie diese Informationen häufig, um Ihr Unternehmen so effizient wie möglich zu führen. Manche dieser Informationen erachten Sie als so wichtig, dass Sie die Aktualisierungen an Ihre Pinwand heften, damit Sie sie kontinuierlich verfolgen können. Diese Informationen können Kraftstoffkosten, Parkplatzgebühren (Sie sind nicht Eigentümer des Parkplatzes und zahlen die Stellplätze pro Stunde) und die Gesamtsumme der Stunden, die jeder Fahrer gefahren ist, sein.
Sie verwenden Ihr eigenes Modell zur Überwachung der Aktivitäten Ihrer Flotte. Dies ist Ihr Monitor-Modell. Alle Informationen, die Sie auf Arbeitsblättern, Blättern in Ordnern und auf Papieren an der Pinwand notieren, sind wichtige Informationen für Ihr Unternehmen und müssen laufend aktualisiert werden.
Das Entwicklungstoolkit unterstützt Sie dabei, Ihr Überwachungsmodell auf Papierbasis in ein Monitor-Modell auf Computerbasis zu konvertieren, das auf einem Monitor Server implementiert werden kann. Die folgende Abbildung zeigt eine abstrakte Sicht des Monitor-Modells bei der Implementierung in WebSphere Business Monitor.
Die Geschäftsaktivität im Beispiel 'Limousine Company' ist ein Mietservice für Fahrzeuge mit Fahrer. Die durch diese Geschäftsaktivität erzeugten Ereignisse sind Elemente wie: Abfahrt vom Stellplatz, Aufnahme und Absetzen des Fahrgastes. Das Monitor-Modell im Monitor Server überwacht die von der Geschäftsaktivität generierten Ereignisse. Der Monitor Server ist eine Laufzeitumgebung, die Ihre Monitor-Modelle implementieren und ausführen kann. Mehrere Monitor-Modelle können auf einem Monitor Server implementiert werden. Das Monitor-Modell verwendet die in den eingehenden Ereignissen enthaltenen Daten, um die Leistungsdaten wie zum Beispiel die Dauer der Fahrt, den Status der Fahrt und die Angaben dazu, welcher Fahrer am pünktlichsten ist, zu berechnen. Diese Daten werden anschließend in einer Datenbank gespeichert. Die Informationen der Datenbank werden dem Benutzer über eine geschäftsorientierte Benutzerschnittstelle dargestellt, die als Dashboard bezeichnet wird. Das Dashboard umfasst Messanzeigen, Tabellen und Diagramme.
Bisher haben wir die Grundlagen von WebSphere Business Monitor an Hand von Analogien zur Überwachung des Mietservice für Fahrzeuge mit Fahrer 'Limousine Company' auf Papierbasis erläutert. In der folgenden Tabelle sind die Analogien zusammengefasst. In Kapitel 2 erfahren Sie mehr über Monitoring-Kontexte, Messwerte und Ereignisse:
Papierbasierte Überwachung | Computerbasiertes Monitoring |
---|---|
Arbeitsblätter mit Daten | Monitoring-Kontexte |
Eine Beschreibung dessen, welche Daten aufgezeichnet werden und wie diese auf einem Arbeitsblatt angeordnet sind | Monitoring-Kontextdefinitionen |
Felder auf einem Arbeitsblatt | Messwerte |
Eingehende Telefonanrufe von den Fahrern | Ereignisse |
Ordner mit den Arbeitsblättern und anderen von den Arbeitsblättern berechneten Informationen | Datenbanken |
Pinwände | Dashboards |
Das Monitor-Programmiermodell ist ereignisgesteuert. Monitor-Modelle empfangen Daten direkt von Ereignissen, die von den überwachten Entitäten ausgegeben werden. Damit ein Monitor-Modell Daten korrekt von einem eingehenden Ereignis empfängt, müssen Sie Pfadausdrücke angeben, die auf den relevanten Ereigniskontext verweisen. Um Sie bei der Definition dieser Pfade zu unterstützen und um sie zu validieren, muss der Monitor-Modelleditor (MME) den Typ (das Layout) der Ereignisnutzdaten kennen, die diese Informationen enthalten.
Die Nutzdaten enthalten Daten für das Monitor-Modell wie zum Beispiel die Fahrzeug-ID, den Namen des Fahrers und den Zeitpunkt der Abfahrt. Die Nutzdaten die WebSphere Business Monitor verarbeitet sind in XML geschrieben. Der MME muss durch die XML-Schemadefinition (XSD) für die Nutzdaten informiert werden, damit auf die Informationen korrekt zugegriffen werden kann.
Im Geschäftsszenario des Mietservice für Fahrzeuge mit Fahrer, ist der Anruf eines Fahrers ein Ereignis. Fahrer können aus unterschiedlichen Gründen anrufen. Möglicherweise rufen sie an, um mitzuteilen, dass sie gerade bei der Abholadresse des Fahrgastes eingetroffen sind. Dann wissen Sie, dass es sich um ein Ereignis vom Typ 'pick up passenger' (Fahrgast abholen) handelt, das den Zeitpunkt der Ankunft bei der Abholadresse und die erwartete Ankunftzeit enthält. In WebSphere Business Monitor, basiert dieser 'Ereignisklassifikationsschritt' auf Filterbedingungen. Sie können sicherstellen, dass Business Monitor das Ereignis auf bestimmte Datenelemente oder bestimmte Werte überprüft, auf deren Grundlage das Ereignis einem bestimmten Typ zugeordnet werden kann. Ereignisse müssen ausgegeben und über einen Kanal oder ein Medium übermittelt werden. Bei unserem Beispiel auf Papierbasis, werden Mobilfunksender und Radiofrequenzen für die Übertragung der Ereignisse verwendet. In WebSphere Business Monitor werden Ereignisse über CEI (Common Event Infrastructure) an das Monitor-Modell übertragen.
Die folgende Abbildung entspricht der bereits zuvor im Lernprogramm dargestellten Abbildung, wobei jetzt Ereignisdaten hinzugefügt wurden. CEI verbindet die Ereignisquelle (die überwachte Entität) mit dem Monitor Server. Ereignisse in CEI werden in einem bestimmten Format gesendet, dass als Common Based Event (CBE) bezeichnet wird und auch in XML geschrieben ist (und über eine eigene XML-Schemadefinition verfügt). Innerhalb von CBE befindet sich ein Feld (oder Slot) mit den Nutzdaten, die das Monitor-Modell empfängt.
Diese Lerneinheit verdeutlicht, dass Ereignisse als CBEs (die auf XML basieren) verarbeitet werden, und dass die Informationsnutzdaten ebenfalls in XML geschrieben sind. Daher benötigt der Monitor Server eine Möglichkeit, um durch CBE und die Nutzdaten zu navigieren, um bestimmte Datenfelder abzurufen. Diese Methode verwendet XPath-Ausdrücke (XML Path Language).
Zu Beginn dieses Kapitels erinnern Sie sich daran, dass Sie auf der Registerkarte 'Problems' (Probleme) einen bestimmten Fehler gesehen haben. Die Fehlernachricht weist darauf hin, dass der Monitor-Modelleditor (MME) nach einer Definition im Monitor-Modell sucht, die angibt, welche Ereignisse die Erstellung von Instanzen bewirken. Beim Überwachungsmodell auf Papier entspricht dies dem Ausfüllen eines neuen Arbeitsblatts, sowie ein Fahrer eingeteilt wurde.
In diesem Abschnitt werden Sie diesen Fehler durch eine Ereignissubskription beheben. Ereignissubskriptionen sind für den korrekten Betrieb Ihres Monitor-Modells von fundamentaler Bedeutung, da nur die direkte Eingabe von der überwachten Entität in Ihr Monitor-Modell ein Ereignisstrom ist. Diese Entität könnte jedoch viele verschiedene Typen von Ereignissen aussenden, die das Monitor-Modell möglicherweise nicht benötigt. Aus diesem Grund muss das Monitor-Modell explizit nur die Ereignisse subskribieren, die es für seine Berechnungen benötigt. In den nachfolgenden Abschnitten erlangen Sie ein besseres Verständnis der Ereignisverarbeitung in WebSphere Business Monitor.
Sobald Ereignisse eintreffen, sendet der Monitor Server diese an die Monitoring-Kontexte (MCs), die diese Ereignisse subskribiert haben. Um das Bild des Arbeitsblatts zu verwenden: Ihre elektronischen Arbeitsblätter subskribieren oder überwachen Ereignisse, die Informationen zu der auf diesem Blatt aufgezeichneten Fahrt enthalten. Ereignissubskriptionen werden als Definitionen eingehender Ereignisse im Monitor-Programmiermodell implementiert.
Ein eingehendes Ereignis enthält zwei wesentliche Teile: (siehe das Diagramm unten)
Die Definition eines eingehenden Ereignisses muss eine Anweisung für jedes dieser drei möglichen Ergebnisse enthalten. Die Tabelle unten zeigt, welche möglichen Aktionen für jedes dieser drei Ergebnisse ausgeführt werden können.
Ergebnis des Korrelationsausdrucks | Mögliche Aktion |
---|---|
Fall 1: Keine Instanz stimmt überein |
|
Fall 2: Genau eine Instanz stimmt überein |
|
Fall 3: Mehrere Instanzen stimmen überein |
|
Als Entwickler des Monitor-Modells müssen Sie entscheiden, was in jedem der drei Fälle für jedes eingehende Ereignis geschehen soll. Die von Ihnen angegebenen Aktionen steuern die Verarbeitungslogik Ihres Monitor-Modells. In unserem Beispiel 'Limousine Company' erstellen Sie ein neues Arbeitsblatt und tragen die Anfangsdaten ein, wenn ein Fahrzeug eingeteilt wurde und der Fahrer Sie anruft, um zu melden, dass er den Parkplatz verlässt. Dieser Ereignistyp (der die Erstellung einer Instanz bewirkt) wird als Erstellungsereignis bezeichnet. Falls das Ereignis jedoch die Aufnahme des Fahrgastes ist und das Ergebnis der Korrelation 'keine Übereinstimmung' lautet, möchten Sie möglicherweise dieses Ergebnis als Fehler behandeln, da jemand versucht, ein Arbeitsblatt zu aktualisieren, das nicht vorhanden ist.
Zusammenfassung: Wenn ein Ereignis von einem Monitoring-Kontext empfangen wird, wird zuerst der Ereignistyp durch die Filterverarbeitung identifiziert. Falls es ein Ereignistyp ist, der für den Monitoring-Kontext von Interesse ist, durchläuft das Ereignis die Korrelationsverarbeitung, um festzustellen, wie viele und welche Instanzen von diesem Ereignis betroffen sind. Die für das Ereignis auszuführende Aktion hängt vom Ergebnis der Korrelationsverarbeitung und davon ab, welche Aktion für die drei möglichen Ergebnisse angegeben wurde. Schließlich müssen Sie eine Definition für eingehende Ereignisse für jeden Ereignistyp erstellen, den Ihr Monitor-Modell subskribieren möchte.
Monitoring-Kontexte von WebSphere Business Monitor benötigen eine Verbindung zwischen Ereignissubskriptionen und Messwerten. Sie müssen WebSphere Business Monitor Informationen darüber liefern, wie die Messwerte auf Grundlage des Inhalts eingehender Ereignisse aktualisiert werden sollen. Diese Verbindung wird durch die Definition von Zuordnungen geschaffen.
Die folgende Abbildung stellt symbolisch einen Monitoring-Kontext mit ihren Ereignissubskriptionen auf der linken und ihren Messwerten auf der rechten Seite dar.
Eine Zuordnung wird durch einen Ausdruck definiert, dessen Eigner ein Zielmesswert ist, der definiert, wie der Wert dieses Messwerts berechnet wird. Zuordnungen entsprechen Formeln in Tabellenkalkulationsanwendungen. Eine Zuordnung, die von einem eingehenden Ereignis abhängt, wird immer dann ausgeführt, wenn dieser Typ von Ereignissen an einen Monitoring-Kontext gesendet wird. Falls das Ereignis an mehrere Instanzen gesendet wird, wird die Zuordnung in jeder Instanz ausgeführt. Eine Zuordnung, die nur von Messwerten abhängt, wird ausgeführt, wenn einer ihrer Eingabemesswerte sich ändert.
In diesem Lernprogramm werden nur datengesteuerte Zuordnungen verwendet.
Zwei unterschiedliche Strategien können verwendet werden, um die Zuordnungen zu definieren. Sie können entweder den Datenfluss betrachten (für jeden Typ eingehender Ereignisse, beachten Sie die Auswirkungen auf die einzelnen Messwerte) oder Sie können die Abhängigkeiten betrachten (für jeden Messwert, beachten Sie, wie dieser durch die einzelnen Typen eingehender Ereignisse beeinflusst wird). Wenn Sie Ihre Zuordnungen nach ihren Abhängigkeiten definieren, sollten Sie das Ergebnis unter Verwendung der anderen Methode überprüfen.
Ähnlich können Zuordnungen unter Messwerten definiert werden, indem Sie den Datenfluss betrachten (unter der Fragestellung, welchen Einfluss dieser Messwert auf andere Messwerte hat und wie dieser Einfluss ggf. aussieht) oder indem Sie Abhängigkeiten betrachten (unter der Fragestellung welche Messwerte diesen Messwert beeinflussen und wie sie dies tun). Eine doppelte Überprüfung des Ergebnisses unter Verwendung der anderen Methode wird empfohlen.
Es gibt einige wichtige Einschränkungen bei der Definition von Zuordnungen, die der MME erzwingt. Die Definition einer Zuordnung führt möglicherweise zu Abhängigkeiten unter den berechneten Werten. Diese Abhängigkeiten müssen azyklisch sein (falls Messwert A von Messwert B abhängt, darf Messwert B nicht von Messwert A abhängen) und eine Zuordnung kann auf nur ein eingehendes Ereignis verweisen (da die Ereignisse nie gleichzeitig eintreffen, ist das eine oder andere Ereignis nicht verfügbar).
Nach der Definition der Zuordnungen, kann die Sicht 'Monitoring Flow' nützlich sein, um den sich ergebenden Datenfluss anzuzeigen. Die folgende Abbildung stellt eine Beispielsicht dar. Das Ereignis passengerPickedUp aktualisiert den Messwert pickUpActualTime, der wiederum Aktualisierungen der Messwerte tripStatus und pickUpWasLate bewirkt.