Writer instructions | |
|---|---|
Page title | For most spaces, this page must be titled Space announcements. For spaces with localized content, this page must be titled Space announcements l10n. |
Purpose | Provide an announcement banner on every page of your space. |
Location | Move this page outside of your home branch. |
Guidelines | |
Overview of objects
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:
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.