In this tutorial, you will learn about the central concepts of the monitor programming model, including its core programming elements and their semantics. The most fundamental concept to the monitor programming model are monitor models.
A monitor model is the specification for how you are going to monitor an observable entity, such as a business activity. Monitor models define what type of information you receive from that entity and how you can process that information to determine the performance characteristics of that entity. Such entities can be tangible (servers, ATMs) or abstract (project status, sales performance).
Monitor models are based on a programming model designed for business monitoring. Business monitoring focuses on collecting business-related statistics, like the monthly sales by region, or the percentage of shipments returned by product category. Business monitoring differs from IT monitoring in that IT monitoring focuses on collecting statistics like the maximum transaction throughput of a given server and software stack, or the average response time of a Web service. WebSphere Business Monitor is not intended for IT monitoring and so is the sample in this tutorial.
The sample used in this tutorial follows the life of a limousine company. Suppose you want to monitor the trip activities of your fleet of limousines, but are doing so on paper. When you dispatch a limousine, you have to prepare a worksheet with the plate number of the car, the driver’s name, the name of the passenger, the pickup and destination addresses, the arranged pickup time, and the planned arrival time. When a driver contacts you to inform you of a change, you have to update your worksheet. The driver can also give you real-time information such as actual arrival and departure times, trip status, and trip duration. Tracking this information on one worksheet is difficult. Because you are running a Limousine Company, you have multiple drivers and multiple cars. This means you must coordinate all of this incoming information across multiple worksheets.
To improve the efficiency of your business, you have to collect statistics and analyze these sheets regularly. For example, you might want to calculate the weekly average trip distance of a limousine so you can forecast your gasoline expenses and determine whether you need to adjust your rates. Additionally, you might want to calculate how long, on average, your cars spend idle in the lot, or which drivers are the most punctual, or who your best customers are. You can then store all of this recorded information on additional sheets and keep them in a folder for your reference. As a business owner, you often need this information to keep your business running as efficiently as possible. You might consider some of this information so important that you keep updates pegged to your corkboard so you can keep continuous track of them. This information might include gas expenses, parking hours (because you do not own the lot and you pay by the hour), and the total hours spent driving for each driver.
You are actively using your own model for monitoring the activities of your fleet. This is your monitor model. All of the information that you store on worksheets, papers in folders, and papers pinned to your corkboard is vital information to your business, and it needs to be kept up to date.
The development toolkit helps you convert your paper-based monitor model into a computer-based monitor model that can be deployed onto a monitor server. The following figure represents a high-level view of a monitor model when it is deployed in WebSphere Business Monitor.
The business activity in the limousine example is a limousine rental service. The events produced by this business activity are items such as: departure from the lot, passenger pickup, and passenger drop off. The monitor model on the monitor server listens for the events generated by the business activity. The monitor server is a runtime environment that you can deploy and run your monitor models. Multiple monitor models might be deployed on a monitor server. The monitor model uses the data contained in the incoming events to calculate performance data, such as the duration of the trip, the status of the trip, and which driver is the most punctual. This data is then stored in a database. The information from the database is presented to the user by way of a business-oriented UI known as a dashboard. The dashboard includes gages, charts, and graphs.
So far we have introduced the basic concepts in WebSphere Business Monitor by analogy using the paper-based limousine rental company as an example. The following table summarizes the analogy. You will learn more about monitoring contexts, metrics, and events in Chapter 2:
Paper-based monitoring | Computer-based monitoring |
---|---|
Worksheets with data | Monitoring contexts |
A description of what kind of data is recorded and how it is organized within a worksheet | Monitoring context definitions |
Fields within a worksheet | Metrics |
Incoming phone calls from drivers | Events |
Folder to keep the worksheets and other information computed out of the worksheets | Databases |
Corkboards | Dashboards |
The monitor programming model is event-based. Monitor models receive data input directly from events that are emitted by monitored entities. For a monitor model to correctly retrieve data from an incoming event, you must specify path expressions that reference the relevant event content. To help you define those paths, and to validate them, the MME must know the type (layout) of the event payload that contains this information.
The payload contains relevant data for the monitor model, such as the limousine's identifier, the driver’s name, and the time of departure. The payload that WebSphere Business Monitor processes is written in XML. The MME must be informed by the XML schema definition (XSD) for the payload so that the information can be accessed correctly.
In the limousine business scenario, a call from a driver is an event. Drivers can call for different reasons. They might call to say that they just arrived at the passenger's address, then you know that it is a “pick up passenger” event type, so you can expect specific information from them, such as the time they arrived at the location and what time they expected to be there. In WebSphere Business Monitor, this "event classification step" is based on filter conditions. You can make sure that the monitor tests for certain data elements to be present in an event, or to have certain values, for that event to be recognized as having a certain type. Events must be emitted and delivered through a channel or medium. In our paper model, cellular towers and radio frequencies are used to transmit the events. In WebSphere Business Monitor, events are transmitted to the monitor model through the Common Event Infrastructure (CEI).
The following figure is the same figure shown earlier in the tutorial with the event information added to it. The CEI bridges the event source (the monitored entity) to the Monitor Server. Events in the CEI are delivered in a specific format known as the Common Based Event (CBE) which is also in XML (and has its own XML schema definition). Within the CBE is a field (or slot) that contains the payload that the monitor model receives.
This lesson demonstrates that events are processed as CBEs (which are XML-based) and that the information payload is also written in XML. As a result, the monitor server requires a means for navigating through the CBE and the payload to retrieve specific data fields. That method is using XML Path Language (XPath) expressions.
At the beginning of this chapter, you recall seeing one particular problem in the Problem Tab. The error message indicates that the MME is looking for a definition in the monitor model specifying which events cause the creation of instances. In the paper-based monitor model, it corresponds to starting a new worksheet whenever a driver is dispatched.
In this section, you will fix this problem through event subscription. Event subscriptions are fundamental to the correct operation of your monitor model since the only direct input from the monitored entity to your monitor model is a stream of events. However, that entity might be emitting many different kinds of events, some of which the monitor model might not need. For this reason, the monitor model must explicitly subscribe only to the events that it needs for its computations. In the succeeding paragraphs, you will have a better understanding of how event processing is done in WebSphere Business Monitor.
As events arrive, the monitor server delivers them to the MCs that subscribed to these events. Using our worksheet metaphor, the electronic worksheets ″subscribe″ or listen to events containing information about the trip recorded on this sheet. Event subscriptions are implemented as inbound event definitions in the monitor programming model.
An inbound event contains two essential parts: (please see the diagram below).
An inbound event definition must include a directive on what to do for each of these possible cases. The table below shows what possible actions can be taken for each of these cases.
Correlation expression result | Possible actions |
---|---|
Case 1: No instance matched |
|
Case 2: Exactly one instance matched |
|
Case 3: Multiple instances matched |
|
As the monitor model developer, you must decide what to do in each of the three cases for every incoming event. The actions you specify control the processing logic of your monitor model. In the limousine example, when a limousine is dispatched and the driver calls you to let you know that he is leaving the lot, you create a fresh worksheet and fill in the initial data. This type of event (that causes instance creation) is called a creation event. However, if the event is to pick up a passenger and the correlation results to no match, you might want to treat it as an error since somebody is trying to update a worksheet that does not exist.
In summary, when an event is received by a monitoring context, the event type is identified first through filter processing. If it is an event type that the monitoring context is interested in, the event goes through a correlation processing to determine how many and which instances are affected by this event. The action to be carried out on that event depends on the result of the correlation processing and what actions were specified for each of the 3 possible cases. Finally, you must create an inbound event definition for every event type that your monitor model wants to subscribe to.
WebSphere Business Monitor monitoring contexts require something that bridges the gap between event subscriptions and metrics. You must inform WebSphere Business Monitor how to update the metrics based on the content of incoming events. This gap is bridged by defining maps.
The following figure shows symbolically a monitoring context with its event subscriptions on the left and its metrics on the right.
A map is defined by an expression, owned by a target metric that defines how the value of that metric is calculated. Maps are similar to spreadsheet formulas. A map that depends on an inbound event runs whenever this kind of event is delivered to a monitoring context; if the event is delivered to multiple instances, the map will run in each instance. A map that only depends on metrics will run when any of its input metrics changes.
Only data-driven maps are used in this tutorial.
Two different strategies can be followed to define the maps. You can either look at data flow (for each kind of inbound event, consider its effects on each metric), or at the dependencies (for each metric, consider how it is affected by each kind of inbound event). If you define your maps by their dependencies, you should cross-check the result first.
Similarly, maps amongst metrics can be defined by looking at data flow (as in what does this metric have an impact on another metric, and if so, what does it do), or dependencies (which other metrics affect this metric, and how). Double-checking the result by using the "other" method is recommended.
There are some important restrictions in defining maps, which the MME enforces. Defining a map might create dependencies among calculated metrics. These dependencies must be acyclic (if metric A depends on metric B, then metric B must not depend on metric A) and a map can reference no more than one inbound event (since events never arrive concurrently, either one or the other would not be available).
After defining the maps, the "Monitoring Flow View" can be useful to see the resulting data flow. The following figure represents a sample view. The passengerPickedUp event updates the pickUpActualTime metric, which in turn causes updates to the tripStatus and pickUpWasLate metrics.