Overview of objects

What is MainView Middleware Monitor (MVMM) actually monitoring? Well, monitoring can mean several things and can differ on the type of item being monitored and the technology involved; it can include statistics, the state of whether something is active, running, pending, etc. So let us start out on some common ground: for this product, “objects”, and more specifically, WebSphere MQ objects, are the items being monitored.  

How are objects identified?

Objects are identified in a hierarchical manner, such as in the following example: 

The type of an object and its name are often separated into “type” paths and “instance” path. When working with command line tools, a ! character is used as a delimiter.

For example: 

Host!Queue Manager!Queue

MyHost!Demo!Queue1

Sometimes an Object Identifier (OID) consisting of three numbers separated by an _ is also used. Many of the MVMM command line tools use the OID as a short hand way to identify an object. 

An object usually has attributes on which monitoring extensions publish values. These values can be statistical, identifiers, informational, etc. and can be viewed in Views and dashboards.  

Where are objects maintained?

Objects are maintained in the database and this is known as the Object Repository.

Some extensions, such as the WebSphere MQ extension, support object discovery. MQ objects include queues, topics, channels, etc. and the queue managers they reside on. Object discovery is enabled by default on distributed systems and disabled by default for z/OS. When object discovery is enabled, during each monitoring cycle the extension is able to determine which objects have been added or removed. When an object is discovered it is said to be confirmed. Each object also maintains the time when it was first discovered, when it was last confirmed to exist, and when the state last changed (each object has a state (one of ADDED, CONFIRMED, NOT-FOUND, DEPRECATED, or DELETED).

As newly added or removed objects are discovered their state is changed in the object repository maintained by the services. This enables you to use polices to perform actions in a uniform and consistent manner when objects are newly created and/or removed. Examples of actions include the following:

• Registering and unregistering the objects for monitoring. For more details, see Monitoring.
• Adding or removing a collection of display items for an object to a dashboard. For more information about collections and dashboards, see Views and dashboards.
• Adding or removing the association of an event template with an object so that one or more actions may be performed when triggered based on the published values for that or other objects. For more information about event templates, event triggers and event actions, see Events.
• Adding or removing the association of a history template with an object so that published values are preserved and summarized to observe longer term trends. For more information about history templates see History data.

Policies can use attributes of the object that rarely change, such as a description. These are also known as stable attributes. For performance, stable attributes are only published if the object is registered for monitoring and the value changes or at the time the object is discovered to exist. For more information about polices, see Overview of policies.

You can also manually perform the actions done by a policy. Refer to How does MainView Middleware Monitor work? for details on how to perform those actions using either the Monitor Console or a command line utility.