IBM BPM, V8.0.1, All platforms > Authoring services in Integration Designer > Developing monitor models > What are monitor models?

How monitoring works

Monitor models contain monitoring contexts, which define the set of information to be collected at run time. A monitoring context is created for each real-world object that is monitored.

The monitoring context receives the events that report changes in the real-world object, and updates its properties based on information extracted from these events. These properties include business measures, such as metrics, counters, and stopwatches, which describe the performance aspects of a business that are required for real-time business monitoring.

Business measures typically refer to entities that have multiple real-world instances and thus must be indexed by key values designating the instance. The following list contains examples of the indexing of business measures:

A monitoring context groups all business measures with the same index, and is a container for those business measures that collectively describe the state of the same real-world object (for example, a particular order, ATM, flight, or process execution). A monitoring context instance is created for each instance of the real-world object, and its lifetime typically corresponds to the lifetime of the object being monitored.

In the Monitor Model editor, you provide a definition for a monitoring context. There is one such definition for each kind of object you want to observe.

For example, you would need different monitoring context definitions for orders, ATMs, flights, or process executions. From the definition, Business Monitor then creates a new monitoring context instance for each instance of the real-world entity (for example, one instance per order, ATM, flight, or process execution).

Each monitoring context instance requires a key to uniquely identify it.

For example, if the monitoring context represents a running order process, its key could be the order ID. You could have 15 instances of the order handling process running at the same time, each handling a different order. Each instance would be represented by a different monitoring context instance and order ID key value.

All communication into and out of a monitoring context is handled by events. Monitoring context instances subscribe to events, update their state based on information in the events, and emit events to report a business situation. They are created, hosted, and terminated by Business Monitor.

For example, Business Monitor might create a new monitoring context instance when a Process Started event arrives, update the state of the monitoring context instance as Task Completed events arrive, and terminate the monitoring context instance when a Process Ended event arrives. It might also emit a Process Delayed event when the time since Process Started exceeds a certain threshold. For Business Monitor, all of these actions are defined in the monitor model, which contains monitoring context definitions that define inbound and outbound events, business measures, and triggers for business situations.

In summary, Business Monitor works in this way:

  1. Load a monitor model containing one or more monitoring context definitions.
  2. Wait.

    • If an inbound event arrives, deliver it to all affected monitoring context instances (creating new instances as needed), update their state (that is, their metrics), process any triggers, emit outbound events, terminate any monitoring context instances that require termination, and return to wait.

      A monitoring context might require termination if the real-world entity that was being monitored no longer exists.

      For example, if the order that was being monitored has been fulfilled or the transaction being monitored with an ATM has been completed, the monitoring context instance representing that order or ATM transaction would also be considered complete and could be terminated.

    • If the recurring wait time for a trigger arrives, process any triggers and their effects (such as metric updates and outbound events), terminate any monitoring contexts that require termination, and return to wait.

The following image shows the next level of detail. This illustration is a schematic, high-level view of how monitoring works but does not necessarily describe the precise flow. Each step is described under the image. For more detail about the participating elements, see "Monitor details model."


Step 1. Load monitor model

At startup, Business Monitor server loads a monitor model, which defines its configuration. A monitor model contains one or more monitoring context definitions.


Step 2. Wait

Business Monitor then waits for one of these occurrences:


Step 3. Find qualifying inbound events

When an inbound event arrives, Business Monitor finds all subscriptions for this kind of event in all monitor models that have been loaded. Event subscriptions are defined through the filter conditions at event entry points (called inbound event definitions) in a monitoring context definition. The filter condition is an expression that evaluates to true or false based on the attributes of the event, for example, the order cost must be greater than $500, or the date must fall within a certain period, or both. If the filter condition is not met, the event is ignored by this inbound-event subscription point (although it might still be detected by other subscription points in the same or a different monitoring context). Events that satisfy the filter condition are considered for delivery (through this entry point) to the monitoring context instances. The specific instances for event delivery are determined at the next step.


Step 4. Find correlated monitoring context instances

If an inbound event is of the required event type and passes the filter of an event entry point, its correlation expression is evaluated for each existing monitoring context instance in each monitor model that matched the condition in Step 3. (Step 3 checks all applications, whereas Step 4 finds the matching instances within an application.) This evaluation can result in zero, one, or several matches. In each case, there are model-defined settings that determine the action. The possibilities include the following actions:

After Business Monitor has determined which monitoring context instances should receive the event, it delivers the event to each event entry point with a matching correlation predicate and a "deliver event" setting. Events can be delivered to zero or more monitoring context instances.

Steps 5 and 6 occur in each monitoring context instance to which the event was delivered (or in which a trigger occurred).


Step 5. Evaluate expressions

All expressions that depend on the incoming event are evaluated and update their target metrics. Expressions with input that depends on metrics that have been changed are evaluated iteratively to calculate any secondary effects. This behavior is similar to the updating of a spreadsheet, in which an update of one cell can lead to cascading updates of other cells, based on spreadsheet formulae. The spreadsheet formulae are the equivalent of these expressions.


Step 6. Process triggers

Any triggers that were activated due to the incoming event, the metric changes, or the expiration of a time interval, are now checked to see which ones actually fire. If their conditions evaluate to true, the triggers fire.

Any counters or stopwatches that depend on a trigger are updated: counters are incremented, decremented, or reset; stopwatches are stopped, started, or reset. All metrics that depend on an expression controlled by a trigger are updated.

If metrics were updated, new triggers might fire and steps 5 and 6 are repeated until all cascading effects have been processed. A monitor model must not contain any cyclic dependencies, so the cascading effects will always end in a finite number of steps.


Step 7. Send outbound events

Any expressions for outbound events that were controlled by a trigger are evaluated. The event attribute values are entered and the events are emitted if their filter conditions evaluate to true.

Finally, any monitoring contexts to be terminated as a result of a trigger are marked for termination, and are terminated after all other effects have been processed. Terminated monitoring contexts are unable to receive future inbound events. The values of their metrics, counters, and so on are still available to Business Monitor.

Although this explanation does not cover key performance indicator (KPI) contexts, they work in a similar way to monitoring contexts. They can process inbound events, evaluate recurring wait-time triggers (for example, for checking whether a KPI has gone out of range), and send outbound events (for example, a notification that the KPI is out of range).

What are monitor models?


Related concepts:
Monitor details models