Deployable packages best practices
From the TrueSight repository, administrators select monitor installation components, such as the BMC PATROL Agent and monitoring solutions, to create a deployable package. The components can then be installed together using the installation package. You can reuse the installation packages, or deploy the packages to managed nodes.
After creating a deployable package, administrators can save the package for future use, orafter saving the package. For saved packages, administrators can the package on any host, or a package.
Best practices for Deployable packages with monitoring solutions only
From the TrueSight console, it is possible to deploy packages that contain monitoring solutions only. It is not possible to deploy packages that include the PATROL Agent, PATROL Agent patches, or the PATROL Configuration Manager.
BMC recommends the following best practices regarding the Deployable packages with monitoring solutions only:
- 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.
- For monitoring solutions that contain sub-components (For example, Microsoft Windows Servers), select only the sub-components that are required. This helps in reducing the deployable package file size.
Best practices for Deployable packages with PATROL Agent
Deploying the PATROL Agent is a manual process and cannot be performed through the TrueSight console.
BMC recommends the following best practices regarding the Deployable packages that include the PATROL Agent:
PATROL Agent tagging
If a BMC PATROL Agent is already configured through the PATROL Configuration Manager, and the agent is integrated with Infrastructure Management through the adapter for BMC PATROL, do not add a tag to that BMC PATROL Agent. Instead, continue managing the configuration for that BMC PATROL Agent through the PATROL Configuration Manager.
If you add a tag to the BMC PATROL Agent, configuration information might be overwritten. Duplicate instances could be created, conflicting monitor instances that were based on PATROL Configuration Manager settings will be marked for deletion, and all historical data will be lost.
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 the Presentation Server. Tags in an agent’s configuration identify the technology to be monitored that is running on the managed computer. When the agent checks into the Presentation Server, the tags are leveraged by the policy application process in the Presentation Server 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
- SQL Server databases running on Windows
- Apache running on Windows and Red Hat Enterprise Linux
- WebLogic running on Windows and Red Hat Enterprise Linux
Create the following deployable packages with the tags indicated:
|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.
Monitoring policy settings
Consider the following options:
A deployable package can contain an integration tag value. This tag can then be used as part of the selection criteria in a staging policy to help determine the proper data collection Integration Service to assign the agent to. You must also leverage criteria such as the Infrastructure Management Server that the agents are to report into for staging policies.
Settings in a package can allow or deny the use of policies. If you choose to deny policy usage, the PATROL Agent does not leverage policies unless the PATROL agent configuration is set to allow policies. You can manage this from the TrueSight console. Note the following points:
If you allow policy management, the deployable package must include configuring the PATROL Agent to connect to the staging Integration Service. Using the allow setting causes the agent to leverage the new policy configuration format rules, and the old configuration rules that conflict with the new rules format are ignored by the agent.
If you deny policy management, the package must include configuring the PATROL Agent to connect to a data collection Integration Service. The deny setting is useful during upgrades and migrations. It ensures that the current Agent configuration is maintained but used in the newly updated PATROL Agent and Infrastructure Management infrastructure.
Predefined packages and policies
You have the option to import commonly used packages and policies when you import the base Repository. For more information, see Importing the Infrastructure Management repository.
Predefined packages and policies help you get started quickly and monitor your environment, without the need to create packages and define monitoring policies.
The following predefined packages are created at Administration > Repository > Deployable Packages tab. You can delete predefined packages but cannot edit them.
|Predefined package name||Description|
|Predefined_Package_For_AIX_PowerPC_<version number>||Predefined package with PATROL Agent and AIX KM|
|Predefined_Package_For_Linux_x64_<version number>||Predefined package with PATROL Agent and Linux KM|
|Predefined_Package_For_Windows_x64_<version number>||Predefined package with PATROL Agent and Windows KM|
Since predefined packages include the BMC PATROL Agent, you have to manually deploy the packages and not through the TrueSight console.
The following predefined policies are created at Configuration > Infrastructure Policies.
|Policy name||PATROL Agent selection criteria|
|Predefined Policy for AIX||Agent Operating System contains AIX|
|Predefined Policy for Linux||Agent Operating System contains Linux|
|Predefined Policy for Windows||Agent Operating System contains Windows|