IBM Tivoli Monitoring, Version 6.3

Self-describing auto refresh and seeding

The self-describing capability enables your monitoring infrastructure to be automatically refreshed and seeded with the most current version of application support.

Auto refresh is what allows continuous and uninterrupted updates to your monitoring infrastructure. After a successful auto refresh, seeding updates your environment with the most current product definitions.

Auto refresh

Each product provides application support. Before IBM® Tivoli® Monitoring V6.2.3 or later, the application support was installed at a monitoring server, portal server, and portal client, and a recycle of each component was necessary for the new application support to be activated. For IBM Tivoli Monitoring V6.2.3, auto refresh enables the monitoring server and portal server to provide dynamic application refresh after a self-describing agent installation event.

The non-intrusive auto refresh operation occurs when a new self-describing agent initiates an application installation through the IBM Tivoli Monitoring infrastructure. The processing is triggered the first time a self-describing agent connects to a monitoring server and the application support is not already present at the remote monitoring server or hub monitoring server.

The application support is automatically installed first at the hub monitoring server, followed by the remote monitoring server the agent is currently connected to (which retrieves the support from the agent), and then at the portal server (which retrieves the support from the hub monitoring server). If an agent switches to a different remote monitoring server where the support is missing, the support is dynamically updated at the new hosting remote monitoring server.

Auto-refresh occurs at a monitoring server immediately following the metadata deployment. Metadata deployment transfers and stores attribute files, catalog files, EIF mapping files, out-of-the-box product definition files (seeding files), and version files at the monitoring server. After the files are successfully deployed, the monitoring server internal caches are updated and the new metadata is immediately available for the monitoring server components to use for monitoring. Auto-refresh also occurs at the portal server, updating all necessary files.

If the portal server database is restarted while the portal server is still running, then the portal server must be restarted for the support to finish updating the portal server. In order for auto refresh on the portal server to work correctly, the portal server database must be running.

Auto refresh guarantees that you have continuous access to the product’s metadata to support monitoring activities during a self-describing agent refresh, by using existing metadata and when the metadata auto-refresh completes, the new metadata becomes available. Some internal monitoring server components provide notification when you have new metadata, for example, to move pending wait situations to started.


Included with a product's application support are out-of-the-box monitoring definitions that include where the definitions will run. The application of a distribution or "where" is commonly termed distribution. The storing of the products monitoring and distribution definitions in the monitoring server is termed seeding. Seeding happens automatically as part of the self-describing agent product installation so that default monitoring definitions are enabled. You can alter or disable this behavior through the CLI, but you should only do so if you do not want all of the product provided monitoring definitions. For more information, see "Configuring self-describing agent seeding" in the IBM Tivoli Monitoring Installation and Setup Guide, and "tacmd editSdaOptions" in the IBM Tivoli Monitoring Command Reference.

The tacmd listappinstallrecs -d command returns the application support installation records from the monitoring server application properties table, including the values contained in the SEEDSTATE column. See the IBM Tivoli Monitoring Command Reference for more information. The following values in the SEEDSTATE column reflect the seed state of self-describing agent installed products:
During the monitoring server startup, messages are produced in the TEMS MSG2 log and audit log facility when changes or self-describing agent installation errors are detected in installed products. The monitoring server application support installation records are updated as needed to reflect the changes indicated by the MSG2 messages or audit log. The TEMS RAS1 log contains trace messages that show the success or failure of application support changes. Inspect the MSG2 messages and audit log messages in the IBM Tivoli Monitoring Troubleshooting Guide and complete the following actions:
  • Verify that detected changes in installed products were expected. If the changes were unexpected or incorrect, take the required action to install the correct product versions, through a self-describing agent installation or manual installation.
  • If any errors are noted in a self-describing agent installed product, clean up the application support installation records, if required. You can do this by deleting the records for the failed installations by using the tacmd deleteappinstallrecs command, and reinitiate the self-describing agent installations, if required. See the IBM Tivoli Monitoring Command Reference for commands that you can use to perform these tasks.
Note: The self-describing agent feature does not automate the installation of agent language packs. Language pack installation procedures for self-describing agents are the same as the procedures for standard agents. For more information, see "Installing language packs" in the IBM Tivoli Monitoring Installation and Setup Guide.