The repository in Central Monitoring Administration includes two major areas: Manage Repository and Deployable Package Repository. This section discusses best practices for both of these areas.
The Manage Repository area contains installation packages from BMC that were imported as the base repository, extended repository, a single solution, or a combination of these. These packages can be downloaded from the BMC Electronic Product Distribution web site and imported into the repository.
The base and extended repository versions 9.5 and higher are compatible with Central Monitoring Administration in TrueSight Presentation Server v10.0. You should not try to import or use older versions.
Deployable package repository and tagging
The Deployable Package Repository area contains installation packages that you create. These packages are created by selecting product components and versions available from the Manage Repository area and entering installation configuration criteria.
BMC recommends the following best practices regarding the Deployable Package Repository:
Provide meaningful names for the packages you create. Put the information with the maximum impact at the beginning of the package names. For example, if you are creating a package for the basic monitoring of Red Hat Enterprise Linux operating systems, and this package is to be deployed to all or most of the Red Hat systems in the environment as a standard, name it something like “RHELOSBasic”.
Enter complete descriptions in every package description field. Put the most important information at the beginning of the description so that it is readily visible without having to hover your mouse over it.
Policy assignment to the correct agents on the appropriate managed nodes is a critical part of policy administration. This is accomplished through the agent criteria configuration in policies and in most environments requires proper tagging of agents. Tags provide very precise agent selection criteria for use in automatically assigning monitoring policies to the agent through Central Monitoring Administration. Tags in an agent’s configuration identify the technology to be monitored that is running on the managed computer. When the agent checks into Central Monitoring Administration, the tags are leveraged by the policy application process in Central Monitoring Administration to automatically apply the appropriate policies to each agent. The following is good practice of determining and setting PATROL Agent tagging during the deployable package creation and installation process.
Create agent and operating system Knowledge Module deployable packages that contain all the tags necessary for a managed node based on the technology to be managed that is running on the managed node. For example, consider an environment has the following to manage:
- Oracle databases running on Red Hat Enterprise Linux 6.4
- SQL Server databases running on Windows 2008 R2
- Apache running on Windows 2008 R2 and Red Hat Enterprise Linux 6.4
- WebLogic running on Windows 2008 R2 and Red Hat Enterprise Linux 6.4
Create the following deployable packages with the tags indicated:
The Knowledge Module packages do not contain tags. (It is not possible to include tags in packages that only contain Knowledge Modules.)
|OracleRHEL||Linux/UNIX Agent, Linux/UNIX OS Knowledge Module||LinuxOS, OracleDB|
|SQLWin||Windows Agent, Windows OS Knowledge Module||WinOS, SQLDB|
Windows Agent, Windows OS Knowledge Module
Linux/UNIX Agent, Linux/UNIX OS Knowledge Module
|WebLogicWin||Windows Agent, Windows OS Knowledge Module||WinOS, WebLogic|
|WebLogicRHEL||Linux/UNIX Agent, Linux/UNIX OS Knowledge Module||LinuxOS, WebLogic|
|Oracle||Oracle Database Knowledge Module||N/A|
|SQLServer||SQL Server Database Knowledge Module||N/A|
|Apache||Internet Server Manager Knowledge Module||N/A|
|WebLogic||WebLogic Knowledge Module||N/A|
This may look like an excessive number of packages. You can reduce the number of packages and avoid duplicating PATROL Agents in packages by following the tagging methodology outlined here.
The methodology discussed above assumes there is no host naming convention or IP address range that can help identify what is running on a managed node. For example, the managed nodes are named based on colors (red, yellow, green, blue, and so on). If host naming conventions follow strict content that identifies what is running on each managed node, then the method above is not needed and you can leverage staging policies to apply tags instead.
You can copy packages to create a new package. You can do this by editing an existing package and saving it with a new package name. This allows you to easily copy packages that contain only the PATROL Agent and OS Knowledge Modules, and edit only the tag values. You can also edit other aspects of the package as necessary or required.
Define and follow standards for installation settings as listed in the following examples. (These are only examples. There are various additional settings.)
- Installation directory on Red Hat Enterprise Linux - /opt/bmc
- Agent user ID/password – Patr0L123 / <password>
- Agent port – 3181
Use default settings as much as possible, especially for port numbers and installation directories. This helps in troubleshooting if assistance is required from BMC Customer Support.
Do not specify Integration Services used for data collection in the deployable packages. Instead, specify staging Integration Services in the deployable packages.
Specify tags in the deployable packages to provide granular control of policy application.