A root-level monitoring context is automatically defined
whenever you create a monitor details model. It must be completed
with definitions of its elements, such as metrics, triggers, and event
subscriptions.
About this task
To create a new monitoring context, click the
Monitor
Details Model tab, right-click the monitor details model
at the top of the model tree, and click . Or, to create
a nested monitoring context, right-click a monitoring context and
click .
To define a monitoring context,
complete the following steps:
Procedure
- Click the Monitor Details Model tab
of the editor and click the monitoring context.
- Optional: To change the ID, click Edit on
the ID field. The ID is required,
and it must be unique for all monitor models. The ID must be an XML
NCName (non-colonized name), which means that it must start with a
letter or underscore and that it can contain only letters, digits,
underscores, hyphens, and periods.
Important: The monitoring
context ID must be unique within the monitor model. Other elements
are required to be unique only within their own containers; for example,
an inbound event ID must be unique within its own monitoring context
or KPI context.
- Optional: Type a new name
in the Name field.
- Optional: Type a description
in the Description field. The description
is used only in the Monitor Model editor and is not displayed anywhere
in Business Monitor. The
character set is unrestricted.
- To specify that this monitoring context not be shown on
the dashboard, select Hide from dashboards.
- Optional: Specify quality of service
properties to provide the location of configuration information inside
your events. When you specify one of these properties at the monitoring
context level, the value is applied to all descendant inbound events,
except those that are contained in a descendant context that specifies
the same property. You can override the value for individual inbound
events by providing a custom value on the inbound event page.
- Specify an event sequence path, which
is a path to an event attribute that indicates the processing order
for inbound events. The event sequence expression must start with
the ID of the inbound event. If no event sequence path
is defined, events are processed in the order in which they arrive.
For more information about event sequence paths, see Event sequence paths.
- Specify the path to the creation time
of the event. The Monitor server uses this attribute to indicate the
instance creation time, for example, to determine the stop and start
times of a stopwatch, or to determine which instances should be included
when calculating historical KPI values. Use a business-relevant creation
time from the event payload, such as the date and time that an order
was placed.
- Specify the path to the global instance
ID. This ID is used to relate the problem determination message to
a specific event when there is an error at run time, (for example,
in the WebSphere® Application
Server log).
Content assist is not available to help
you select the event attributes to use for the paths, because the
inbound events will have different structural characteristics and
there is no single event definition that can be used as the basis
for content assist. You can define an expression that refers to any
constant, function, or event attribute.
- Optional: If this monitoring context was generated
from a Process Server application,
an Application element field shows the display
name of the event source that is linked to this monitoring context.
If any of the elements in the monitoring context were generated from
templates, the templates are shown in the table. Open a template to
see the managed elements. For example, if you open a Start Time template,
you see a Start Time metric and inbound events for each event that
can create a monitoring context. If more than one event source is
associated with this monitoring context, you can select an application
element from the list to see the associated templates and elements.
To remove the association between the monitoring context
and the application, click
Remove.
Important: Removing the association also removes all associations
to application elements from all descendant monitor model elements.
You can then edit the fields that are currently read-only because
they are managed by the application, but you will no longer be able
to synchronize the monitor model with the application.
To
add more templates to the monitoring context, click Add on
the table and select the templates to add.
To remove a template,
click Remove. You are given the option of removing
all the monitor elements that are managed by the template (assuming
they are not required for the implementation of any other templates)
or just removing all associations to the referenced monitor model
elements from the template and removing it from the list of applied
templates.
What to do next
You can add keys, inbound events, triggers, metrics, counters,
stopwatches, outbound events, and nested (or
child) monitoring
contexts to this monitoring context. To add one of these elements,
right-click the monitoring context in the model tree, click
New,
and select the element to add.
To filter the elements that are visible
in the model tree, right-click a node and click Filter.
Select any elements that you do not want displayed.