DX Application Performance Management

Hi,

I have to create a Java Agent package manually without using ACC.

1. What things I have to keep in mind before creating a Java Agent package?

2. What configuration has to be done in the packages?

3. All the agents are of different versions we have to upgrade all the agents to the latest 10.7 version.  

The Packages should contain Profile file for JBoss, Websphere, Tomcat, Java Standalone, WebLogic.

Regards

Imran

Dear Imran:

This is a duplicate of [DUPLICATE]:Create a Agent package manually??   I made this into a Discussion since more of a best practice question.

Dear Community:

Can you help Imran with this? This also sounds like a good blog/knowledge doc topic.

Thanks

Hal German

I would say to begin with downloading the the 10.7 agent from support.ca.com and verify differences in the settings used in your IntroscopeAgent.profile in your current agents.  App teams may have customized settings such as for agent & process naming, URL groupings, clamping, trace settings, SQL, JMX & PMI, .pbd's and smart instrumentation.  This will also give you insight into any custom/extensions that may be required or no longer supported/required like an old powerpack. 

I personally prefer to try the default agent for a new version first before modifying settings (other than agent & process naming) since the agent is continuously refined and tuned.  For instance, URL groupings used to have only "default" enabled, but now they are enabled for several segment URL in the 10.7 default agent and are supported in Team Center as Experiences. Therefore, carrying over old settings may not always be best.

HTH get your started.

Hi 

how can we create an Agent package manually without using ACC??

Thanks 

Hi Imran,

Without ACC you just have to download the required agent files package from support.ca.com.

Then customise agent profile, pbds etc to your requirements per Janelle's advice above.

NOTE: In 10.7 there is no Java agent installer so only "NO INSTALLER" file deployments exist

e.g. From DOWNLOAD MANAGEMENT product field enter:  "CA Application Performance Management Agent (APM/Wily/Introscope)"

Click on the link for "Product Downloads Available"

Then click on "CA Application Performance Management Java and .NET Agent MULTI-PLATFORM"

e.g. for latest 10.7 Service Pack 2 (SP2)

You either download the DEFAULT AGENT agent package, a specific AppServer AGENT package, or "INTROSCOPE JAVA AGENT FILES FOR ALL APPLICATION SERVERS-NO INSTALLER" which will have all files for all AppServers and you just use the AppServer specific profile file that is provided for each.

Only if you need to add extension bundles do you then have to add them manually to what you have from above instead of using ACC:

Agent Extensions - CA Application Performance Management - 10.7 - CA Technologies Documentation 

Hope that helps

Regards,

Lynn

Hi

What if I have 1000 agents in my environment it will be a lengthy process if it has to be done manually...is there another way to we create an agent package??

Thanks

You are really only creating the agent package "once" meaning you can reuse that agent across environments and apps (typically) though this can vary depending on your application landscape.  I would start with the all app server agents (download) for each of the platforms you mentioned.  You will see differences between each. For instance, Tomcat will have JMX metrics captured enabled by default whereas Websphere you would use PMI.  And both are optional, tho enabled by default.

As for deployment, it really depends on your target environment as to whether something like ansible scripts or what type of automation would be most appropriate. 

The benefit of using ACC is that it will allow you define the agent packages, verify where they are deployed (if you choose to use that controller option) and facilitate version control for you.  If you use the controller, some remote changes can be handled from ACC, which is a bonus.

Starting with the application agent for all application servers, you can go into that agent and remove any specific application server files or for that matter, add more as noted below.

There are a few base settings that you will need to deal with:

1. Multiple APM environments

     We use a JVM parameter "-DagentManager=<mom>:5001" so we don't need multiple IntroscopeAgent.profile, one for each APM cluster.

2.  Setting the agent profile

      Each application server would have a different set of PDB/PBL files to include and those are set within the IntroscopeAgent.profile.  You can set a different file using a JVM parameter "-DagentProfile=${AGENT_HOME}/core/config/IntroscopeAgent_websphere.profile"

       Then copy the out of the box IntroscopeAgent, rename it for each application server, then within the profile configure the PBD/PBL that the specific agent host requires.  If you have any custom PBD/PBL files, come up with a naming convention for the specific target environment. 

         So case, in the IntroscopeAgent.profile for websphere it would have the following:

        introscope.autoprobe.directivesFile=websphere-typical.pbl,hotdeploy,webspheremq.pbl

but for WebLogic would be like

      introscope.autoprobe.directivesFile=weblogic-typical.pbl,hotdeploy

So if you have two websphere environments that one has a skip.pbd while the other does not, you basically do the same  thing and have a IntroscopeAgent_websphere.profile and a IntroscopeAgent_websphere_skip.profile.  Then you set the one or the other in the JVM arguments to pick up the skip.pbd or not.

So, when you upgrade the application agent, I would highly suggest, starting your customization and settings from scratch.  Don't just drop the pbd/pbl into a different version of the agent since there could be changes to the .profile or the pbd/pbl that will cause issues if you drop a different version.  You should use your current pbd/pbl as reference and with that, always keep detailed notes on what you did and why you did it.

3.  Placing the Agent files

      Different application servers want/need the agent in a specific location, determine what works, document it, make sure that the configuration files and JVM arguments reflect that, and document it.

We have been using a variant of the above for quite a bit now and it has severed us rather well but cutting down on the number of agent install images we had to manage.

Hope this helps,

Billy