Build and Manage Agents Using APM Command Center
CA APM Command Center enables you to manage agent packages and customize them for your environment.
apmdevops102
CA APM Command Center enables you to manage agent packages and customize them for your environment.
Agent packages are composed of bundles, each representing a piece of functionality offered by the agent. For each bundle, dependencies, inter-relationships, and compatibility requirements are defined, determining the possible combinations of bundles.
CA APM Command Center provides a graphical user interface (Agent Package Builder) where you can view available bundles and combine them into a package. This package can be downloaded, either manually or using the API.
Once deployed, the package registers back to Command Center for accurate reporting of package usage.
Agent Packages
An agent package is a deployable set of agent binaries and configuration files in ZIP or TAR format.
You can create a package using the Agent Package Builder wizard. During the process, you define the environment and you can customize the default installation instructions.
When finished, you can download and deploy this package or you can further customize the package by adding or removing bundles and modifying configuration properties.
After you deploy the package, and configure the agent to start with your Application Server, you will be able to see which Agents are using which package directly in the user interface.
More Information:
The following video explains how to create agent packages in CA APM Command Center:
Bundles
The completed agent package is composed of several bundles. Each bundle represents a compact piece of agent functionality. For example, there is a bundle for SQL, SOAP web services, HTTP backends, servlet, JSP, and so on. When you customize your package, you can add or remove bundles, make changes to their configuration, and edit the default installation instructions.
When you start customizing a package, the wizard enables you to add and remove bundles to and from the package. Two columns list available and selected bundles:
- Available Bundles- Optional bundles for special monitoring that are compatible with the chosen environment. An example of this type of bundle is the 'Leak Hunter' bundle.
- Selected Bundles- Default, preselected bundles that are required or recommended for monitoring the chosen environment. For example, the 'Struts' bundle is required for monitoring Tomcat, while the 'SOA' bundle is recommended for Tomcat.
Further, the bundles listed in both columns are grouped according to their type:
- CoreCore monitoring components such as Java agent binaries or CA APM Command Center extension.
- EnvironmentDepending on the platform, environment group contains bundles that monitor the application server.
- FeaturesVarious CA APM monitoring features to enhance metrics visibility.
When you select a bundle, information about its functionality is displayed. If the selected bundle depends on other bundles, these bundles will be highlighted.
Bundle Configuration
On the Bundle Configuration page of the wizard, you can see the section of the IntroscopeAgent.profile related to each of the included bundles. You can edit the current properties or add new ones. Add a comment to describe the reason for your change.
Note:
You can only delete properties that you have previously added.Bundle Installation Instructions
Where appropriate, each bundle comes with installation instructions specific to that bundle. The installation instructions for a package are a combination of all installation instructions for the individual bundles included in the package.
You can edit the instructions if you want to customize them for your environment. For text formatting, use the Markdown language syntax. The changes are specific to the package you are editing and are not propagated to other packages.
More information:
In this video, you learn how to customize the content and properties of agent packages:
Package Versions
Each package has a version number so that deployed packages can be tracked.
The versioning works the following way: When a package is created, its initial version number is 1. Upon subsequent edits, the version number will remain at 1 until a user downloads the package. The next edit will increase the version number to 2.
The version number, visible in the user interface, allows you to:
- View a specific version of the package
- Download the package for a specific version
- Copy a specific package version to a new package
In addition, you can archive a package version. Archived versions cannot be downloaded and are not available for any other operations - preventing them from being accidentally used.
When creating a new package version, it will be based on the current (latest non-archived) version.