Skip navigation

MainView Middleware Mgmt

4 Posts authored by: Brad Boldon Employee
Share This:

When objects (queue managers, queues, etc.) are associated with a history template, event template or a logical type those associations remains regardless of whether the object is registered for monitoring.

 

Once associated, the intent is that history will be collected and events trigger whenever the object is registered for monitoring.   However, sometimes that object shouldn’t have been unregistered from monitoring.   This can lead to gaps in an object’s data in trend charts or reports.   It can also lead to event triggers failing to trigger as expected.

 

There a couple different ways to watch for this issue with BMC TrueSight Middleware and Transaction Monitor 8.0.00 or later.   An object that is not registered for monitoring is not presented on the Operations tab.   Noticing a missing object can be hard to do.   The Object Repository tab shows all objects and the objects in the tree that are not registered for monitoring are displayed in blue by default.   You may change the color, font and tooltip via Tools->Preferences->Unmonitored Objects so the objects stand out even more.

 

Whenever a list of associations is displayed (History Tab, Event Tab, Logical Types Tab) the object is also displayed with this same blue color (or the color and font you set in the preferences).   This will help identify why a particular event template may not be working as expected, why history is not available or why the object’s attributes are not showing values on a logical view.

 

Tip: You may register individual objects from the Object Repository Tab by right clicking and selecting Register Object for Monitoring.   Note, all ancestors of that object are also registered for monitoring.   Conversely, you may unregister an object by selecting Unregister Object from Monitoring.   All descendants of that object are also unregistered for monitoring.    The panels on the right side of the Object Repository Tab auto-refresh periodically.   However the tree coloring and fonts do not.   You only need to collapse and re-expand the parent of the object to see the changes.

 

Tip:  Now that object associations remain regardless of whether the object is registered for monitoring.   It is recommended policies be used to do that initial association.    There should be no need to use the maketmpltassoc utility to re-apply templates after a change in monitoring selection as is common for some customers where object monitoring is changed frequently.

Share This:

New to BMC TrueSight Middleware and Transaction Monitor 8.0.00 is the concept that each object has a state.   The states are ADDED, CONFIRMED, NOT-FOUND, DEPRECATED, and DELETED.

 

The addition of an object state is the result of the discovery features added to the product for the WebSphere MQ extension.   During each monitoring cycle the WebSphere MQ extension is able to determine which MQ 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.   When a discovery sweep occurs the object may be re-confirmed by updating the time when last confirmed.   See another post by me that discusses when you would use a discovery sweep.

 

There are two ways an object may change to a deleted state.    Consider the scenario that a MQ queue is registered for monitoring as it is required for use by the MQ applications.   Infrastructure changes are underway and the MQ administrator needs to reconfigure MQ.   An MQ administrator knows the queue is going away so they use the Object Repository to select the queue in the tree, right click and select "Deprecate Object".   The deprecate state is sticky in that once an object is deprecated, even if the object is re-confirmed it remains deprecated.  The intention is that this state informs users this object is going away and to avoid it or learn why.   The object remains in that state until "Undo Deprecate Object" is used or an extension says the object no longer exists at which time the object is now in a deleted state.

 

The other scenario is that the extension has determined the object is actually gone.   The object then goes to a not found state.    Perhaps the queue was simply removed by the MQ administrator but how does one know the removal wasn’t done by accident?   Now an MQ administrator can come in and choose to deprecate the object if they know the removal wasn’t by accident or they can figure out why the object was removed and re-create it if necessary.  Deprecating an object in a not found state causes the object to be in a deleted state.

 

Having said all that, the flexibility has been added where you can simply choose to mark an object deleted immediately.  Simply right click and choose "Delete Object".

 

A few notes.

 

An object isn’t really gone from the object repository when in a deleted state.  If you have a large number of deleted objects, the next time you schedule down time for the services you can run dbschema_sync with the -o option to permanently remove them.    Please consider that any history, audit events and event journals will no longer be available for those objects once permanently removed.

 

When an object transitions to a not found or deleted state, the object no longer is registered for monitoring.   So if the MQ administrator accidentally removes an MQ object and then later adds it back you will need to register that object for monitoring again unless you have a policy configured to do it for you.   In addition to the times noted earlier, the time when monitoring was last changed is also maintained for each object.   All this information can be viewed from the Object Repository tab when you select an object from the tree.

Brad Boldon

Restoring an agent

Posted by Brad Boldon Employee Feb 12, 2016
Share This:

Backing up critical data is an important aspect of any production level IT environment.   However, backing up the data is only half the picture; you must be able to restore it as well.    Being able to restore your agents after hardware failures or other mishaps is equally important.    Enhancements made to BMC TrueSight Middleware and Transaction Monitor 8.0.00 services and agents have made this easier.

 

Background Information

 

When backing up the agent and extension information we mainly refer to the current set of objects registered for monitoring, agent and extension preferences, and extension configuration files.

 

In addition to the agent’s local repository of objects (maintained in eaa.xml), the services maintains an object repository and records what objects were previously registered for monitoring.   The service repository allows you to forego backing up the agent’s local repository as we can restore up to date information from the service repository for BMC TrueSight Middleware and Transaction Monitor 8.0.00 and later agents.

 

The WebSphere MQ extension may be configured to discover queue managers and their objects.  When using discovery with policies to register objects for monitoring , the objects and monitoring from a reinstalled agent will be restored with no intervention.   When using other extensions, or when discovery is disabled, you can use the restore feature from the Management Console or repomgr command line tool.

 

The agent and extension preferences (also maintained in eaa.xml) are not duplicated in a service repository.  However, if you use policies to set the agent and extension preferences you can simply apply the policy after restoring your agent installation.    If you are not using policies to set the preferences you should use agentpref to export the preference settings to an xml file.   It is recommend that you export the preference settings after initial configuration and whenever preferences are changed.

 

The agentpref utility is available in the services installation and as an agent package.  If the agent was configured to communicate with the services using a tunnel (i.e. using TLS), and a tunnel is required to communicate with the agent (i.e. only TLS traffic is permitted to or from the agent), then you will need to export and restore the preferences using agentpref locally, on the agent machine.

 

As you can see, using policies as a recovery mechanism is an easier way to recover an agent with up to date information.   However, you should export your policies using the mqsexport command and backup the output zip file.   If necessary use mqsimport to restore the policies.

 

The WebSphere MQ extension is controlled entirely from preferences but other extensions may have files that you configure during installation.   You should back up those files after the initial configuration and whenever they are changed.    In addition, if you aren’t using the standard port or are overriding some connection parameters, remember to back up the eaapi.ini file(s).   Much of this information is specific to your environment and may be readily available from other sources.   However, it is still recommended that this information is backed up to make restoration easier and faster.

 

Restoring an agent

 

Follow these first steps for a simple agent install on a distributed platform like Linux or Windows …
* Get an agent package from the “Download Agents” link on the TMTM launch page.
* Extract the agent package on the agent machine.
* Make sure the permissions are good.
* Start the Extensible Agent (qpea) but don’t start the Configuration Agent (agent) yet.

 

The above steps are for a basic agent install. The TMTM Agent and Extensions guide covers all of the options available.

 

If you are using policies to set preferences, you can apply the policies to the agent using the Management Console (in the Policies tab, find the agent, right-click the agent and “Apply Polices”).   Otherwise, use the agentpref import option to restore the agent and extension preferences.

 

Now that preferences have been restored, start the Configuration Agent (agent).

 

If extension packages have previously been distributed to the agent, and the directories and files in the directory specified by the MQS_HOME environment variable remain, you may install extensions from the packages as was done before.    Otherwise, the packages will be deployed again and once those deployments have completed you may install them.   Check the “Package Distributions” tab of the MC for their status.

 

Finally, after installing the extension packages, restore the configuration files previously backed up or re-configure them from your own preserved information.   You may now start the extensions.

 

If you are using discovery and policies to register objects for monitoring and you are only using the WebSphere MQ extension than nothing more is required.   Otherwise, use the restore option to re-register the objects for monitoring so the agent is in sync with the services.   You may select the agent in the tree on the Object Repository tab of the MC.  Right click and select “Restore”.    You may also use the repomgr tool to perform the restore.    Either will re-register any objects currently registered for monitoring. 


Notes
If you restore an agent that was not newly installed, keep in mind this is not a full sync.   For example, if for some reason the agent thinks that an object is not registered for monitoring but the service’s object repository does, then that object will become registered for monitoring.   Similarly, if the agent thinks that an object is registered for monitoring and the service’s object repository does not, then that object will remain out of sync.    The reconfirm feature from the MC or repomgr command line tool can be used in this case.    The agent’s perception of what is registered for monitoring is used.    Under normal circumstances a reconfirm is not needed and should rarely be used but may be recommended by BMC Technical support.

Share This:

 

What is a discovery sweep and when would you do one?   Beginning with BMC TrueSight Middleware and Transaction Monitor 8.0.00 you may configure the WebSphere MQ monitoring extensions to discover MQ objects such as queues, channels and the queue managers they reside on.   This feature is enabled by default on distributed systems and disabled by default for z/OS.   When enabled, newly added or removed objects are discovered during the next monitoring cycle causing their state to change in the object repository maintained by the services.    This allows you to use polices to register the objects for monitoring, associate them with your event and history templates and perform other actions when the objects are newly created and/or removed.   Policies may 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.

 

So what is a discovery sweep?   A discovery sweep informs the WebSphere MQ monitoring extension to re-discover and publish all stable attributes for existing objects on one or more queue managers.   Essentially, this allows you to sync up those stable attributes for objects that you have not registered for monitoring that may have changed since being discovered or the last discovery sweep.    How often this is needed depends on your environment.   Stable attributes are named that for a reason, they rarely change.    A discovery sweep can take some time and it is not recommended you do it often.   Ideally you would perform a discovery sweep during off-peak times.    You may manually perform a discovery sweep from the Object Repository tab of the Management Console, use the Agent Discovery Sweep policy action with a schedule or use the repomgr command line tool with an external scheduler like cron.

 

One final tip.  If your policies are not being applied to an object that uses stable attributes in the policy expression, you may select the object in the tree of the “Object Repository” tab and view the current values for the stable attributes in the lower right pane.   Note the “Time when a stable attribute of the object was last updated” in the upper right pane.    If you feel they are out of sync, right click on the object’s queue manager in the tree and select “Discover Object” to restrict the discovery to that queue manager.    Alternatively, you may select the object’s agent in the tree and select “Discover Agent” to perform a discovery sweep for all queue mangers with discovery enabled under that agent.   Observe the "Time when a stable attribute of the object was last updated” change in the upper right pane.   Verify the stable attributes in the low right pane.   Policy actions will automatically be applied based on the updated stable attributes.

 

A reminder that although Policies apply to all object types, only the WebSphere MQ  extension from the BMC TrueSight Middleware and Transaction Monitor 8.0.00 or later release supports discovery of new or removed MQ objects.   For other extensions, only those objects registered for monitoring are visible to the services and since they are already registered for monitoring, their stable attributes are always in sync.

Filter Blog

By date:
By tag: